שאלה מעצבנת: מי מצליח להתרכז בישיבות דיילי?

[user32]

אז רובינו פותחים את הבוקר בעמידה, או ישיבה או בזום כשכל אחד נותן את ה2 דקות שלו. תוהה אם רק אני מרגיש שהישיבה ה"קדושה" הזאת צריכה חשיבה מחדש?

אישית, התחלתי עם אג'ייל בערך בשנת 2008 נדמה לי ומאז מבין עשרות המקומות והפורמטים שהייתי בהם, זה נע בין:
מתכנתים עייפים שממלמלים "אני עובד היום על באגים".
מתכנתים נלהבים (מדי) שפותחים דיון טכני מפורט על הסיבה שהחליפו את הkey של הקש במנגנון אחר ("זה לא לא דיילי. ניקח את זה אוף ליין").
דיונים פרטיים בין המתכנת למוביל כשכל השאר לא בקיאים מספיק כדי להבין במה מדובר.
ועוד אחד נפוץ: אני שוקע בדיילי בהרהורים ברומו של עולם לגבי איזה צבע קפסולה אני הולך לשתות כשפתאום מישהו שואל "מה דעתך יוזר?" ואני עונה: "אפשר לחזור על זה רגע? בדיוק פספסתי".
זה רק קיבל משמעות מחוזקת בקורונה כשחלק ממשתתפי הדיילי יכולים גם להיות באמצע סרט בנטפליקס, משחק פורטנייט או קוראים פוסטים בתפוז.

אשמח לשמוע על תובנות, חלופות, בעד, נגד או חשיבה מחדש.

 

[vinney]

איכשהו הצלחתי להמנע מהדבר הזה לאורך כל הקריירה שלי (חוץ מתקופה של שנה בערך בצוות אחד שבמהרה עזבתי).

אבל בגדול זה קורה לי בהרבה ישיבות, לא ספיציפית אג׳יל.

 

[user32]

יש טרנד בשנים האחרונות שאימצתי בשמחה של צמצום ישיבות. כל פעם שמנסים לגרור אותי או מישהו מהמפתחים שלי לישיבות מיותרות אני מצטט סיסמאות של אלון מאסק וזה מספיק כדי שהמנהל התורן יתחרט כי אף מנהל בינוני לא רוצה להתפס כזה שהולך נגד רבינו מאסק.
אז ישיבות הבוקר הן הפורמט הקבוע האחרון שנשאר מעיק וזה יומיומי. מזכיר במשהו את מסדרי הבוקר בצבא.

דעתי האישית על ישיבות בכלל:
הישיבות הקטנות והיעילות הכרחיות. 2 מתכנתים שיושבים 20 דקות עם הפרודקט כדי להבין דרישות לפיצ'ר מסויים, או ארכיטקט שיושב עם המפתחים כדי לחשוב על הדרך הנכונה לממש פתרון כלשהו.
הישיבות הגדולות ממש, פעם בחודש כל הקבוצה, כל החברה וכו' גם טובות כי בדרך כלל מתכננים היטב מי יציג מה ויש מחשבה מראש. זה יותר סוג של הופעה.
כרגיל הבינוניות הן הבעיה. יושבים שעתיים, קצת פרודקט, קצת סמול טוק, קצת ארכיטקטורה, קצת ביזנס, מפלט וגן עדן לבינוניים.

 

[jsphs]

אז רובינו פותחים את הבוקר בעמידה, או ישיבה או בזום כשכל אחד נותן את ה2 דקות שלו. תוהה אם רק אני מרגיש שהישיבה ה"קדושה" הזאת צריכה חשיבה מחדש?

אישית, התחלתי עם אג'ייל בערך בשנת 2008 נדמה לי ומאז מבין עשרות המקומות והפורמטים שהייתי בהם, זה נע בין:
מתכנתים עייפים שממלמלים "אני עובד היום על באגים".
מתכנתים נלהבים (מדי) שפותחים דיון טכני מפורט על הסיבה שהחליפו את הkey של הקש במנגנון אחר ("זה לא לא דיילי. ניקח את זה אוף ליין").
דיונים פרטיים בין המתכנת למוביל כשכל השאר לא בקיאים מספיק כדי להבין במה מדובר.
ועוד אחד נפוץ: אני שוקע בדיילי בהרהורים ברומו של עולם לגבי איזה צבע קפסולה אני הולך לשתות כשפתאום מישהו שואל "מה דעתך יוזר?" ואני עונה: "אפשר לחזור על זה רגע? בדיוק פספסתי".
זה רק קיבל משמעות מחוזקת בקורונה כשחלק ממשתתפי הדיילי יכולים גם להיות באמצע סרט בנטפליקס, משחק פורטנייט או קוראים פוסטים בתפוז.

אשמח לשמוע על תובנות, חלופות, בעד, נגד או חשיבה מחדש.

לדעתי,

יש מקומות ותפקידים בהם השיחה הזאת הכרחית - דוגמא: מפעל יצור שמקושר חזק ל- הנדסה ולטכנאים שמתחזקים את המכונות שחלקן עולות עשרות מיליוני ש"ח.

המטרה היחידה של שיחת הבוקר שצריכה לקחת רק כחצי שעה - היא לסנכרן את מנהל ההנדסה\יצור\טכנאות במה הדברים האחרונים שקרו ואיפה הבעיות ברמת הצוות שלו\ה.

דוגמאות: נניח שיש מכונה אחת מתוך 3 שירדה ל- Down והטכנאים טרם הצליחו להרים אותה ולהעביר QUAL. המפעל יכול להמשיך לייצר באופן סביר עם 2 מכונות אבל במכונה הבאה מאותו הסוג שתרד ל- Down תפוקת המפעל תרד ל- 60% והמסלול הזה יהפוך לצוואר בקבוק.

אם זה קרה לנו בתחילת השבוע לכולם ברור שישיבת ההנהלה שמתרחשת לאחר השיחה עם העובדים כשראשי הצוותים צריכים עם ה- input ולדווח בישיבת הנהלה - ביום הרביעי מנהל המפעל\מהנדס ראשי הולכים להעביר משאבים על מנת שהמכונה הזאת תעלה - גם אם על חשבון לא לטפל בדברים אחרים בינתיים. גם אם צריך לאשר overtime לטכנאים. גם אם המהנדס ראשי שלא יודע לתחזק את המכונה הזאת ילבש סרבל כחול\לבן\אדום וירד עם הטכנאים לראות את הלבן בעיניים של הטכנאי ולהבין איפה הבעיה - מה לא מצליח. האם צריך להרים טלפון לנציג ה- vendor בארץ שישלח משהו היום מקסימום מחר לפתור את זה. ואם זה לא קרה ביום חמישי בבוקר זה יקבל את הפוקוס בישיבת הנהלה ביום העבודה אחרון של השבוע.

לכאורה הכל במייל - אבל בסוג כזה של מקומות עבודה שהמון משימות קורות בו זמנית ותלויות אחת בשניה - מטרת הישיבה היא לסנכרן את ההנהלה בדרג הצוותים ובדרג מעליהם למה קורה ומה חשוב ברמה היומית. בשביל התועלת הזאת - המפעל גורר לבערך חצי שעה של ישיבת בוקר צוותית + חצי שעה-שעה ישיבת המשך ברמת הנהלה.

להבנתי, במפעל יצור מולטי דיסיפלינארי שכולל הרבה כימיה, הרבה פיזיקה, הרבה אלקטרוניקה, חשמל של זרם חזק, מזוג אוויר קפדני ועתיר תשומות אנרגיה, תפעול צנרת, ניקוז וכל זה יקרה במקומות בהם להכניס יד לחלק מהכימיקליים יגמר בלהוציא את היד אפילו בלי עצם בשניות ספורות. כל זה כמובן קורה לצד דרישות של לקוחות. ניהול שרשרת האספקה הגלובאלית. דרישות reliability של לקוחות ובצד השני של כדור הארץ יושבים אנשים עם השכלה של PHD ו- 25 שנות ניסיון ואם הדרישה לקבל גרף מסויים של דגרדציה הם בפירוש יודעים מה הם מבקשים, למה הם מבקשים ואיך זה אמור להראות.

------------------------

אגב, סוג כזה של שיחת בוקר יכולה להיות הכרחית בסדנת חימוש חטיבתית - איזה טנק או נגמ"ש תקול, איפה יש PM (מקביל לטפול 10,000 לרכב) שלא קרה בזמן. איפה אחד הגדודים שיושב על גבעה 15 ק"מ מזרחית לירושלים יש טנק שתקוע כבר יומיים ואנשי חמוש דרג א טרם הצליחו להשמיש - האם על חשבון משימות שוטפות צריך לשלוח אזרח עובד צה"ל מהסדנה לטפל בבעיה הזאת (יש לו 15 שנות ניסיון). מה מצב מלאי החלפים. אני מצפה שכמפקד הסדנה ב- 10 בבוקר יודע מה הסטטוס הוא מגיע לדווח למפקד החטיבה ולקבל תעדוף משימות - לדוגמא: עזוב את הטנק התקול הזה ותוודא שמוציאים 250 טנקים מאחסנה יבשה כי מחר בבוקר הם עולים לרמה"ג ונפרסים בשטח לאור עלייה בכוננות. בכזה תרחיש כל החיילים הסדירים, אזרחים עובדי צה"ל, נגדים וקצינים מטפלים קודם כל במה שקל ומה שיוציא מקסימום כלים מטופלים, מתודלקים ומחומשים מחר בבוקר - נניח לעלות 220 כלים שמישים ועוד 30 כלים שיטופלו בהמשך כל כלי ובעיותיו הספציפיות.

-----------------------

איפה הסוג הזה של שיחת בוקר מיותר?

לדעתי אם יש צוות של 20 מהנדסים ומתכנתים שיש להם משימות R&D עם DD של 6 חודשים. ראש הצוות צריך להקדיש 20דק לכל עובד שהכל רץ שם כמו שצריך. אם יש 2-3 מתכנתים אז במקום 1-1 זה פגישת עבודה קצרה. אין שום משמעות לזמן עוד 15 מהנדסים\מתכנתם לשיחה שהם מבינים בה מעט מדי.
זה לא אומר שפעם ב- 3 חודשים יש חצי יום של הצגת סטטוס וחתוך מצב מול הנהלה בכירה כשיום-יומיים לפני זה מה שכל הצוות עושה.
בלילה שלפני ההצגה, ראש הצוות קורא\ת קרוב ל- 20 מצגות של 50 שקפים כל אחת. אם יש שיפורים שהוא רוצה הוא שולח הנחיות לתיקונים. אם הרו"צ קצת מנוסה הוא לא קורא\ת 1,000 שקפים בלילה לפני אלא דורש לקבל את המצגות הללו שבוע מראש ומתקן במהלך השבוע ואם צריך 1-1 מול מהנדסים\מתכנתים בודדים או מול קבוצות קטנות.

 

[user32]

רואים שאתה לא עובד בהייטק.

 

[jsphs]

רואים שאתה לא עובד בהייטק.

חמוד,

ואולי המסקנה שלך שנשענת על כלום עם שום היא פשוט לא נכונה?

ואולי ראיית העולם שלי הרבה יותר רחבה כי עברתי עשרות שנים של תפקידים שונים בהיטק ולא בהיטק.

יש משפט בעברית שלדעתי מתאים לך כמו כפפה ליד: "הפוסל במומו פוסל".

שבת שלום.

 

[BravoMan]

אני מודה ומתוודה שמעולם לא יצא לי לעבוד במקום שבאמת הקפיד על אחת ההמצאות האלה של SCRAM, AGILE, ועוד כל מיני אותיות.
פשוט עבדנו - הנה משימה, זה מה שרוצים ממך, לך תפתח.

במקום הנוכחי, כשהתחילה המגפה, מנהל המחלקה שלי התחיל לעשות שיחות בטימס ארגוני עם כל הצוות שכולל בעיקר מפתחים אבל גם את מנהלי הפרויקטים הרלוונטיים.
בשלב מסוים הוא הפיל את האחריות לשיחות עלי.

לפעמים קשה לי להתרכז, אבל בהס"כ השיחות האלה שימושיות.
אבל, בניגוד למה שאתם מתארים, אנחנו לא באמת עוברים על הדברים הנקודתיים שכל אחד מפתח.

במקום זה, השיחות משמשות לבדוק אם עלו בעיות ו-"להזיז" פתרון לבעיות ידועות.
למשל, לתזכר את הגורמים הרלוונטיים שהועברו אליהם שאלות במייל או מערכת ניהול שאלות, או להעלות שקרה משהו שתוקע את הפיתוח וכו'.
ואז מבררים אם יש פתרון במיידי שאפשר גם להעלות בשיחה, או לפחות לקבל מה הצפי לפתרון.

לפעמים גם מחליטים מקומית על שינוי תעדוף במשימות מפתחים.

השיחות בוקר האלה, שלפעמים מסתיימות תוך רבע שעה, ולרוב לא עוברות חצי שעה מהוות מאין "שימון" לתהליכים הרגילים שקורים דרך מערכת ניהול משימות שלנו או במיילים, והם נותנים לראשי צוות ומנהלי פרויקט תמונת מצב, מבלי שיצטרכו לשבת על הראש של כל מתכנת ולראות כמה שעות עוד נשאר לו על ה-task הספציפי.

כמובן, זה אוזר מאוד שמדובר בצוות שעובד על מספר קטן של פרויקטים נושקים, ולרוב הידע שאחד מדבר עליו רלוונטי גם לאחר, כמו למשל הצורה שבה מתפקדת פונקציית backend אית שנמצאת בשימוש במספר אפליקציות לקוח שונות.

אז בתחלס, גם אם זה מעיק לפעמים, לא הייתי מוותר על השיחות האלה.
גם מפתחים שידועים מה הם עושים, יכולים ללכת לאיבוד לפעמים, ובעיות שדווחו במערכות כתובות עדיין יכולות ליפול בין הסדקים, אז שיחת סנכרון קצרה בכל בוקרה יכולה בהחלט להועיל, גם אם שנים הסתדרנו בלעדיהן (לפעמים אתה לא מבין שאתה צריך משהו עד שאתה מנסה).

בקצרה - כל הבירוקרטיות שהמציאו סביב תהליכי פיתוח הן חרב פיפיות - הן יכולות לעזור לפיתוח לזרום ולעשות סדר בבלגן, אבל הן גם יכולות לייצר הרבה overhead מעיק, ולדעתי הדרך הנכונה לנצל "תהליכים" שכאלה, היא למצוא דרך ביניים שמאזנת בין הצמדות רובוטית לתהליך, לבין "סמוך על כל אחד שיעשה מה שצריך לבד".

 

[user32]

להגנתו של אג'ייל ושאר הטקסים אומר שהם עדיפים על החלופה הקודמת והישנה יותר.
לפני שהמציאו את המתודולוגיות הנ"ל, כל מקום וכל מנהל זימן ישיבות לפי מה שנראה לו. היתה תרבות שלמה של ישיבות, זימנו אנשים לא לצורך, אנשים התלוננו שאין מספיק ישיבות, אחרים התלוננו שיש יותר מדי ישיבות, אנשים נעלבו שלא זימנו אותם, או התלוננו שאין להם זמן כי הם בישיבות כל היום. אנשים הופיעו לישיבות רק כדי שהפרצוף שלהם יהיה תמיד בכל מקום "חשוב" ואחרים חיפשו כל דרך לחמוק מהישיבות.
היום ברגע שצריך "לדבר על משהו" מחליטים לאיזה ישיבה זה מתאים: תחילת ספרינט (תכנון), סוף ספרינט (תלונות, שיפורים, לקחים), דיילי (עדכונים, בעיות) וכו'. נדיר שאיש פיתוח יקבל זימון לישיבת רבת משתתפים. אז מהבחינה הזאת, השיטות האג'יליות בהחלט שיפרו את החיים.

 

[מחפשת עבודה17]

אז רובינו פותחים את הבוקר בעמידה, או ישיבה או בזום כשכל אחד נותן את ה2 דקות שלו. תוהה אם רק אני מרגיש שהישיבה ה"קדושה" הזאת צריכה חשיבה מחדש?

אישית, התחלתי עם אג'ייל בערך בשנת 2008 נדמה לי ומאז מבין עשרות המקומות והפורמטים שהייתי בהם, זה נע בין:
מתכנתים עייפים שממלמלים "אני עובד היום על באגים".
מתכנתים נלהבים (מדי) שפותחים דיון טכני מפורט על הסיבה שהחליפו את הkey של הקש במנגנון אחר ("זה לא לא דיילי. ניקח את זה אוף ליין").
דיונים פרטיים בין המתכנת למוביל כשכל השאר לא בקיאים מספיק כדי להבין במה מדובר.
ועוד אחד נפוץ: אני שוקע בדיילי בהרהורים ברומו של עולם לגבי איזה צבע קפסולה אני הולך לשתות כשפתאום מישהו שואל "מה דעתך יוזר?" ואני עונה: "אפשר לחזור על זה רגע? בדיוק פספסתי".
זה רק קיבל משמעות מחוזקת בקורונה כשחלק ממשתתפי הדיילי יכולים גם להיות באמצע סרט בנטפליקס, משחק פורטנייט או קוראים פוסטים בתפוז.

אשמח לשמוע על תובנות, חלופות, בעד, נגד או חשיבה מחדש.

אני זוכרת שב 2008 התחלתי לעבוד בחברה שעדיין דישדשה לה עמוק בשיטת העבודה הידועה של ה"מפל". בערך חודשיים או שלושה אחרי שהתחלתי לעבוד הייתי צריכה להשתלב בפרוייקט שדרש שינויים בכל היבט של המודולה שעליה עבדנו - כשהסניורית וראש הצוות היו עסוקות מאוד בפרוייקטים אחרים.

בסופו של דבר אני וראש הצוות היינו יושבות כל בוקר לישיבה של בערך 10 - 15 דקות שבעצם היתה ישיבת דיילי במובן הכי מדויק שלה: עברנו על מה שעשיתי ביום העבודה הקודם, מה אני מתכננת לעשות באותו היום - ומה הבעיות שעומדות בפני. מבחינתנו הישיבה הזו איפשרה לראש הצוות להיות בשליטה על הפרוייקט וקצב ההתקדמות שלו (אפילו ברמה של לעבור באופן כללי על הקוד שכתבתי יום קודם), ולי לקבל הדרכה יעילה וממוקדת לגבי המשימה הקרובה שלי, כל זה בפרק זמן קצר וסביר שאיפשרה לשתינו לחזור לעבודה בזמן די קצר.

כיום אני עובדת באג'ייל - והישיבות הצוותיות נראות כמו שאתה מתאר. אני מניחה שההבדל נובע מכך שהישיבות הפכו להיות ישיבות שבהן כל עובד "מעדכן את המנהל" בסטטוס של המשימות שלו, וגם אם כולנו עובדים על אותו "דבר" (פרוייקט / אפליקציה / מודולה) לרוב המשימות של כל אחד מנותקות מאלו של הקולגות שלו. אני חושבת גם במצב שבו מתאמים בדיילי עזרה הדדית במקרה הצורך, לא פעם העובד שמבקשים ממנו עזרה שומע רק בחצי אוזן שמבקשים ממנו עזרה ולא בהכרח מבין את הרקע של הבקשה.

אני מניחה שאם אפשר היה לקבוע שיחת תיאום אישית פעם ביום מול המנהל זה היה יכול להיות ממוקד הרבה יותר.

 

[BismarkReborn]

לטעמי כל הטקסים האלה נועדו בעיקר בשביל לתת אשליית שליטה למי שלמעשה אין לו שליטה אבל יש לו אחריות - כל מני מנהלי פרוייקטים למיניהם (ובמקרים גרועים, גם ראשי צוותים). הבעיה העקרית היא שבפורום קטן מספיק זה מיותר כי אם אני וזאת שיושבת לידי עובדים על אותו פיצ'ר אז כנראה שאנחנו מסונכרנים (ואם לא, דיילי זה לא מה שיפתור את זה) ובפורום גדול מדי זה גם מיותר - וואלק, אני עכשיו כותב אלגוריתם בבקאנד, מה אכפת לי שההוא מתקן באג עכשיו בפרונטאנד קליינט של האייפון. אגב, בחברות "מולטידיסיפלינריות" זה יותר גרוע, יצא לי פעם לעמוד חצי שעה ולהקשיב לאנשי מכניקה מתקשקשים על ברגים של איזו שילדה שלא הגיעו. אין לתאר.

השיטה שאני הכי מתחבר אליה - כל אחד מתאר מתישהו לממונה עליו מה הוא הולך לעשות ב-X זמן הקרוב (נגיד שבוע) תחת ההבנה שיהיו עדכונים לפי צורך. אם יש מישהו שדורש מיקרומנג'מנט, יטרח הממונה וידגום אותו פעם ביום או פעם בשעה בלי להטריח עוד עשרה אנשים. דיילי כשיטה זה טוב רק כשיש תקופה קצרה שמצריכה מאמץ מרוכז והרבה סנכרון (דמו חשוב, הוצאת גרסה וכו')

 

[user32]

מסכים מאוד.
המקומות היחידים שהרגשתי שיש לזה ערך זה מקרים של עובדים בעייתיים ש"הולכים לאיבוד". מישהו ש3 שבועות אומר "אני עובד על הimport" כשכבר מזמן הוא מאחר במשימות. אותו דבר כאלה שאין להם מושג מה הם עושים. היה אחד פעם שאמר "היום אני מוסיף לוגים" וזה התווסף למסמך טיעונים בשימוע שלו.

 

[choo]

כדי שישיבת דיילי תהיה אפקטיבית - צריך מישהו ש"יחנך" את האנשים איך להפוך אותה לאפקטיבית. ישיבת דיילי כזו צריכה לקחת *עד* רבע שעה, והיא לא נועדה כדי לעדכן "את המנהל" - אלא כדי לעדכן את אנשי הצוות בינם לבין עצמם (לא סתם בסקראם העיפו את תפקיד ראש הצוות מהחלון). זה לא אפקטיבי אם זה מגיע לבד - כלומר אם כל אחד עובד על פרוייקט אחר לגמרי, אין בזה טעם. זה נועד למצב שבו הצוות אכן עובד כצוות על פרוייקט משותף. אם יש שני חלקים בצוות שעובדים על שני פרוייקטים מנותקים - צריך שכל תת-צוות ינהל דיילי משלו. זה מגיע גם עם ישיבות תיכנון ספרינט צוותיות, כדי שכולם יהיו בתמונה. הנחת היסוד היא שעבודה של צוות יעיל בצורה משותפת, תהיה יעילה יותר מעבודה של מפתחים בלתי תלויים. באופן מעט מפתיע, זה נכון גם כשיש לך הרבה אנשים חזקים בצוות.

בניהול אפקטיבי של פגישת דיילי, היא משמשת גם כאמצעי סינכרון לצוות, גם כאמצעי לעזרה הדדית (אדם א' מדבר על משהו שתוקע אותו, אדם ב' אומר "קרה לי לפני שבוע, אני אראה לך אחרי הישיבה מה עזר לי עם זה", או אדם ג' אומר "אני צריך לעשות כך וכך היום" ואדם ד' אומר "זה דומה למשהו שעשינו לפני שנתיים, אני אשלח לך לינק לאזור הרלוונטי בקוד, תוכל להשתמש בו בתור רפרנס או לשתף אותו", וכן הלאה.

 

[user32]

ישיבות דיילי אכן לוקחות עד רבע שעה. כלומר שעה ורבע בשבוע שהרבה פעמים נראה כמו בזבוז זמן.
המצב הנפוץ בפיתוח מוצרי SAAS למיניהם הוא שהצוות עובד על מוצר אחד, אבל כל חבר צוות עובד על פיצ'ר מאוד עצמאי ובלתי תלוי. זה המצב הרצוי, ע"ע ארכיטקטורת מיקרו סרביסים וכו'. אז מתכנת א' כותב תמיכה במולטי שליחות ומתכנת ב' כותב API להתממשקות למערכת אחרת ומתכנת ג' משכתב את המסך אדמין לפי העיצוב החדש. אין ממש קשר בין הדברים ורק לפעמים מישהו מעלה נושא שמישהו אחר תורם לקידום שלו.

 

[choo]

ישיבות דיילי אכן לוקחות עד רבע שעה. כלומר שעה ורבע בשבוע שהרבה פעמים נראה כמו בזבוז זמן.
המצב הנפוץ בפיתוח מוצרי SAAS למיניהם הוא שהצוות עובד על מוצר אחד, אבל כל חבר צוות עובד על פיצ'ר מאוד עצמאי ובלתי תלוי. זה המצב הרצוי, ע"ע ארכיטקטורת מיקרו סרביסים וכו'. אז מתכנת א' כותב תמיכה במולטי שליחות ומתכנת ב' כותב API להתממשקות למערכת אחרת ומתכנת ג' משכתב את המסך אדמין לפי העיצוב החדש. אין ממש קשר בין הדברים ורק לפעמים מישהו מעלה נושא שמישהו אחר תורם לקידום שלו.

בעייני זה המצב הלא רצוי. המצב הרצוי הוא לפתח פיצ'ר שלם עד הסוף שיהיה מוכן כמה שיותר מהר, כדי להתחיל לקבל ממנו ערך. הרבה יותר אפקטיבי מאשר לפתח במקביל 5 פי'צרים שלא יספקו ערך במשך פי 5 זמן.

 

[d70]

ישיבות דיילי אכן לוקחות עד רבע שעה. כלומר שעה ורבע בשבוע שהרבה פעמים נראה כמו בזבוז זמן.
המצב הנפוץ בפיתוח מוצרי SAAS למיניהם הוא שהצוות עובד על מוצר אחד, אבל כל חבר צוות עובד על פיצ'ר מאוד עצמאי ובלתי תלוי. זה המצב הרצוי, ע"ע ארכיטקטורת מיקרו סרביסים וכו'. אז מתכנת א' כותב תמיכה במולטי שליחות ומתכנת ב' כותב API להתממשקות למערכת אחרת ומתכנת ג' משכתב את המסך אדמין לפי העיצוב החדש. אין ממש קשר בין הדברים ורק לפעמים מישהו מעלה נושא שמישהו אחר תורם לקידום שלו.

זו בדיוק הסיבה שלא עושים סתם דיילי עם אוסף אנשים אלא צריך לחשוב מה התועלת.
ניתן לפצל את הדיילי לתתי קבוצות שיעשו את הדיילי בינם לבין עצמם. זאת כדי שכל החברים בקבוצה שאכן רלוונטים לפיתוח הפיטצ'ר יוכלו לשמוע ולהשמיע.
אם ידוע שהטאסק אמור לקחת שבוע אז אפשר לרווח את הדיילי.
אם כל חבר צוות עובד על משימה סגורה שלא קשורה או מעניינת חברים אחרים אז ניתן לעשות פגישה 1:1 מול ר"צ/מנהל פרוייקט.

בקיצור להתאים את צורת הדיווח לפי מבנה המשימה ולא סתם כדי להגיד שאנחנו עובדים באגייל..