המאפיינים הייחודיים של עבודת צוות Agile ב-SAFe לעומת Scrum בפועל

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

תחילה אפרט בנקודות את הדברים העיקריים ביותר שמבדילים את העבודה ב-SAFe מ-SCRUM, לדעתי.

• Increment ב-Scrum ו-Program Increment ב-SAFe
• ART - Agile Release Train
• מספר הצוותים המשתפים פעולה
• PIPE
• SOS
• PO - אינו בעל העסק
• RTE
• הספרינט החמישי ללמידה
• System Demo

Increment ב-Scrum ו-Program Increment ב-SAFe. למעשה מדובר במונחים שונים, אך קל להתבלבל ביניהם מכיוון שאיש אצלנו אינו משתמש במונח Program Increment, כולם אומרים פשוט Increment - וזהו כבר מונח אחר שמשמש ב-SCRUM. אך באופן כללי הם די דומים מבחינת המשמעות, לדעתי. Increment ב- SCRUM הוא למעשה המוצר הנוכחי + הסיפורים המתוכננים לספרינט במצב מוגמר (שעברו את ה-DOD של הצוות). Program Increment הוא פרק הזמן שבמהלכו הרכבת (Agile Release Train) מספקת ערך אינקרמנטלי לפרודקשן. במשך הזמן אצלנו מדובר ב-4 ספרינטים של שבועיים לפיתוח וספרינט אחד ללמידה.

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

מספר הצוותים המשתפים פעולה אצלנו ב-SAFe גדול משמעותית, בסך הכל מומלץ עד 125 איש ברכבת אחת. אצלנו יש 3 רכבות ולא בכל אחת מהן הכלל הזה נשמר, יש רכבות עם יותר מ-125 איש. SCRUM אינו מתאר כיצד לתקשר עם צוותים אחרים, ככל הידוע לי, בניגוד ל- SAFe, שבו יש המלצות ברורות מאוד בנושא. החפץ הבולט ביותר, לדעתי, לכך הוא Program Board.

עליו מוצגים הקשרים בין צוותי הרכבת, ובדיון עליו מתקיימים האירועים השבועיים Scrum Of Scrums (SOS) אצלנו.

בערך כל 2.5 חודשים (כל 5 ספרינטים) מתרחש אירוע PIPE - Programm Increment Planning Event. זה כאשר כל הצוותים המפוזרים מתאספים באולם אחד למשך יומיים ומתכננים את עבודתם ל-2.5 החודשים הבאים. בתהליך האירוע הזה נוצרים חפצים כמו Program board, למשל, שעליו מוצגות כל התלויות בין הצוותים עבור כל אחת מהרכבות, לעיל כבר הראיתי כיצד הוא נראה. תפקידו של ה-Scrum Master של כל צוות באירוע זה הוא הנחיית זיהוי מקסימלי של תלויות, ולאחר מכן, ככל האפשר, הסרתן (באמצעות העברת יכולות בעל פה, למשל, מצוות לצוות או באמצעות לקיחת תלות מצוות אחד לאחר, כדי שהצוות יוכל ליישם באופן אוטונומי את הפיצ'ר שלו מבלי להיות תלוי באיש). בפועל זה כך קורה אצלנו. תחילה מפרקים את הפיצ'רים ל-User Story, ה-User Story מפוזרים על פני 4 ספרינטים. הפיצ'רים ממוקמים על Program Board ומוצגות התלויות בצוותים אחרים כפי שהן. במהלך האירוע זה נדון ומתוקן.

SOS - Scrum Of Scrum. אירוע זה מתקיים פעם בשבוע עבור כל רכבת בנפרד. ה-Scrum Masters של כל צוותי הרכבת מתאספים באופן מקוון, מוצג ה-Program Board של הרכבת ונדונים הסטטוסים של כל התלויות והפיצ'רים של צוותי הרכבת הספציפית. למעשה אירוע זה נחוץ לסנכרון מרוכז של הצוותים בתוך הרכבת. משהו כמו סטנדאפ, אך פעם בשבוע ולא עבור הצוות, אלא עבור ה-Scrum Masters.

PO (בעל המוצר) - אינו בעל העסק. יש Product Manager - הוא עובד עם ה-Bussiness Owner'ים של כיווני העסק הרלוונטיים ולמעשה מחלק פיצ'רים לבעלי המוצר. בעל המוצר עובד כבר ישירות בצוות - מפרק פיצ'רים ל-User Stories (במקרה שלנו יחד עם הצוות) ולא תמיד מפרק, אך אנו מתקדמים כל הזמן בכיוון הזה.

RTE (Release Train Engineer - נהג רכבת. סקראם מאסטר של סקראם מאסטרים. מקיים אירועי SOS של הרכבת שלו. מקיים אינטראקציה עם Product Manager ברמת הפיצ'רים. מנחה PIPE.

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

System Demo. כתוצאה מ-PIPE לכל צוות יש רשימת מטרות לאינקרמנט וכל אחת מהמטרות הללו מוערכת על ידי ה-Buisseness Owner של הרכבת בסולם של 10 נקודות. זה נקרא Business Value. המטרות הללו מחולקות למטרות עיקריות ומורחבות. מטרות עיקריות - אלו מטרות שהצוות לא רואה בהן סיכונים בהשגה. מורחבות - אלו מטרות עם סיכוני השגה. כל המטרות חובה והיקף העבודה מתוכנן לכל המטרות. ב- System Demo ה-Business Owner מקבל את תוצאות העבודה עבור האינקרמנט. נניח שלצוות היו 3 מטרות עיקריות עם הערכות 10, 6, 8 ו-2 מורחבות עם הערכות 10, 3. נניח שה-Business Owner שם בהתאמה את ההערכות הבאות: 8, 6, 4, 2, 0. כעת אפשר לחשב את אחוז השגת המטרות: כ-100% נלקחת הסכום ההתחלתי של הנקודות עבור המטרות העיקריות, במקרה שלנו זה 10+6+8=24. הנקודות שהושגו נספרות בהתחשב במטרות המורחבות (כלומר 20 מתוך 24 הצוות השיג), כלומר כתוצאה מכך אחוז השגת המטרות של הצוות יהיה (20*100)/24 = 83.3%. תוצאה נורמלית נחשבת להשגה של בין 80% ל-100%.

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

הערות של עמיתים מפייסבוק

«ז'ניה, שלום! מגניב שאתה כותב, כל הכבוד! אתקן קצת לגבי הרכבות - הן מתאספות לא סביב המוצר, אלא סביב זרם יצירת הערך. ובקמעונאות אצלנו מנקודת מבט של SAFe זה לא רכבת, אלא Solution. פשוט לנוחות התקשורת ולפישוט ההבנה, אנחנו ממשיכים לקרוא לזה רכבת)»

– קונסטנטין וורונין (נציג משרד הפרויקטים של אינגוסטראך)

«ובכן ואולי מישהו ישים לב שמנקודת מבט של SAFe הערכת המטרות מתבצעת ב-I&A; (שם SD נכלל כחלק, אבל לא קשור ישירות להערכה) והן ה-SD עצמם צריכים להתקיים בכל ספרינט (אחרי דמו של הצוותים). אבל אנחנו עדיין רחוקים מזה, לכן במודע אנחנו קוראים לכל זה כפי שכתוב אצלך במאמר)»

– קונסטנטין וורונין (נציג משרד הפרויקטים של אינגוסטראך)

«ז'ניה, תמשיך בבקשה, מאוד שימושי!»

– אלכסיי יונוב (מאמן מוסמך ל-SAFe)