תרגול שימוש ב-Burn Down Charts בהקשר של SAFe ו-Scrum

במאמר זה אני מתכנן לספר כיצד בפועל אנו מיישמים את תרשים הצריבה (Burn Down Chart) בתהליך העבודה לפי מתודולוגיית SAFe

אתחיל, אם כך, בדבר המעניין ביותר. דהיינו בכך שלשימוש בתרשים זה ב-SAFe לא אמורה להיות שום ספציפיות לעומת השימוש בתרשים זה ב-SCRUM. או שאולי כן?

SAFe אצלנו נבדל בקיומו של תפקיד כמו RTE, בניגוד ל-SCRUM, שבו הוא אינו קיים. Burn Down Chart - זהו כלי למעקב אחר היקף העבודה בספרינט והוא נחוץ прежде всего ל- צוות SCRUM, ולא למישהו מבחוץ, הלא כן?

לפיכך, אעבור בכל זאת לאופן שבו אנו משתמשים ב-Burn Down Chart, חרף הכול, ובעודנו נמצאים בתוך מסגרת SAFe.

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

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

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

להלן אשתדל לחשוף כל אחד מהאירועים הללו ולהביא דוגמאות מהניסיון שלי.

הופעת עבודה לא מתוכננת

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

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

המפתח מעולה, הוא יודע הכול על agile ועל חשיבות אספקת הערך העסקי, הולך ומשליך על הלוח סיפור מהבקלוג, הצוות העריך אותו ב-6 sp.

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

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

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

תקיעה ארוכה של משימות בסטטוס לא הושלם

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

• פירוק משימות לקוי

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

• DOD שנוסח בצורה לא אופטימלית

  DOD (Definition of Done) - תיאור קריטריוני המוכנות של User Story בספרינט. לפעמים הם בכלל לא קיימים או שהם מתוארים בצורה מופשטת מאוד. זה בהחלט יכול להיות בעיה, שאותה, כמובן, סקראם מאסטר צריך לעזור לפתור

הקצאת יתר של סיכונים

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

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

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

הבנה - האם העבודה מתנהלת בקצב הנכון

כאן אני רוצה להסב את תשומת הלב לדרכים גרפיות לא מוצלחות להצגת Burn Down Chart

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

• לא ניתן להבחין בהכנסת SP חדשים לספרינט

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

• היתרה היחסית של העבודה מוצגת בצורה לא נכונה

  לפי התרשים העליון נותרו עוד 3 ימי עבודה. בפועל יש 2, ביום החופש, ייתכן שמישהו מתכנן לנוח.

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