תרגול שימוש ב-Cumulative Flow בהקשר של Scrum ו-SAFe

במאמר זה אני מתכנן לספר כיצד בפועל אנו מיישמים Cumulative Flow Chart ב-Scrum בתהליך העבודה לפי מסגרת SAFe

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

בעבר, ב מאמר על Burn Down Charts כבר אמרתי ששם אנו רואים הופעת עבודה חדשה ושריפת הישנה. הבעיה של Burn Down Chart היא שבניגוד ל-Cumulative Flow Chart, בו אנו לא רואים את תנועת סיפורי המשתמש לפי סטטוסים. כאשר אנו מתחילים להתבונן בתנועות לפי סטטוסים ב-Cumulative Flow Chart, אנו מתחילים לראות שינויים יומיים (Burn Down Chart עשוי שלא להשתנות מספר ימים ובהקשרים מסוימים זה יכול להיות לגמרי נורמלי) ויכולים להבחין בבעיות עדינות יותר.

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

בדוגמה זו אנו רואים את הדברים הבאים

• ב-7 הימים הראשונים של הספרינט בבדיקות נמצא היקף עבודה קטן מאוד והוא אינו משתנה
• מ-DOR (כאן זה טיוטה) לעבודה סיפורי המשתמש עוברים בצורה מספיק אחידה - זה טוב.
• כמו גם ב-Burn Down, אנו רואים שלפי המגמה סיפורי המשתמש לא יושלמו עד סוף הספרינט

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

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

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