המטרה: לקדם תאריכי releases בשלב התכנון, ולוודא עמידה ב-roadmap.

(על בחינת השפעות השינויים החלים במהלך ה-sprint על הטווח הבינוני והארוך נדבר בטיפ 102)

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

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

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

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

כאמור, בטיפ 99 ראינו כיצד ניתן בשלב תכנון ה-sprint לבצע אופטימיזציה של לוח הזמנים שלו בעזרת הגנט. אך מה לגבי התכנון לטווח הבינוני (release) והארוך (roadmap)?

חלק מן הכלים המשמשים לניהול ה-backlog יודעים לחלק את ה-user stories ל-sprint-ים עתידיים. בטיפ 99 ראינו כבר ששיפור התכנון בעזרת הגנט יכול לסייע בהכנסת תכולה נוספת. אם התכנון בגנט מכסה את כל תכולת ה-backlog, נוכל להשיג גם כאן תוצאות טובות יותר, כלומר להספיק יותר במבט של sprint-ים מרובים, על מנת שנוכל להקדים את ה-release-ים שלנו או לחלופין להגדיל את התכולה של כל אחד מהם. הסתכלות כזאת תשפר במידה רבה גם את היכולת שלנו לעמוד ביעדי ה-road map שלנו ולהתריע מראש כאשר זה לא עומד לקרות.

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

נחזור לדוגמא בה השתמשנו בטיפ 99.

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

בסוף טיפ 99 היתה לנו תוכנית שמאפשרת להספיק יותר stories ולהשלים יותר features בתוך ה-sprint הראשון:


האם תוכנית זאת מיטיבה גם עם הטווח הבינוני והארוך?
נבדוק זאת באמצעות הגנט.

נחזור ל-backlog, כדי להוסיף לתכנון גם את המשימות הבאות. הפעם נסתכל גם על העמודה המגדירה אילו משימות יכללו בכל release:

מספר	תוכן	הערכה (ימים)	עדיפות	release
1	AAA	2 פיתוח + 1 בדיקות	גבוהה	1
2	BBB	2 פיתוח + 1 בדיקות	גבוהה	1
3	CCC	2 פיתוח + 1 בדיקות	גבוהה	1
4	DDD	2 פיתוח + 1 בדיקות	גבוהה	1
5	EEE	2 פיתוח + 1 בדיקות	גבוהה	1
6	FFF	2 פיתוח + 1 בדיקות	גבוהה	1
7	GGG	2 פיתוח + 1 בדיקות	גבוהה	1
8	HHH	2 פיתוח + 1 בדיקות	גבוהה	1
9	JJJ	2 פיתוח + 1 בדיקות	גבוהה	1
10	KKK	2 פיתוח + 1 בדיקות	בינונית	2
11	LLL	2 פיתוח + 1 בדיקות	בינונית	2
12	MMM	2 פיתוח + 1 בדיקות	בינונית	2
13	NNN	2 פיתוח + 1 בדיקות	בינונית	2
14	OOO	2 פיתוח + 1 בדיקות	בינונית	2
15	PPP	2 פיתוח + 1 בדיקות	נמוכה	3

נכניס ל-Sprint 2 את 5 המשימות שנותרו להשלמת Release 1.

תאוריית ה-Scrum הבסיסית מניחה שכל משאב יכול לבצע כל משימה, אך הנחה זאת אינה עומדת במבחן המציאות לעיתים קרובות. נניח שכשנבדוק את משמעות ה-stories נראה שמשימות DDD, FFF ו-GGG חייבות להתבצע ע"י Dev2, בגלל יכולת מקצועית כלשהי שיש לו.

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

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

כאשר נוסיף את המשימות של Sprint 2 לגנט ונפעיל את ה-resource leveling בלחיצת כפתור, נראה מיד שהמשמעות היא שלפי התוכנית הנוכחית לא נצליח לסיים את Release 1 במשך ה-sprint השני:

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

אם נזהה את הבעיה רק בתחילת Sprint 2, כבר יהיה מאוחר מדי לתקן!
אם היינו מתכננים מראש לטווח הארוך, היינו מוכנים כנראה להספיק פחות features ב-Sprint 1, כדי להוציא את ה-release בזמן. לכן חשוב מאד לתכנן גם לטווח הבינוני והארוך.

המיומנות בשימוש בפונקציית ה-resource leveling תאפשר לנו להגיע די מהר לתוצאה:


מכיוון שאת החישובים האלה עשינו מראש, נוכל להחליף, עוד בזמן התכנון של sprint 1, תכולות בין ה-sprint-ים, על מנת שה-release יצא בזמן:


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

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

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

נכתב ע"י רונית סנה
IntelliManage

שאלות ותגובות לטיפ זה ניתן להעלות כאן