המטרה: לוודא שהחלטות בטווח הקצר (מהלך ה-sprint) טובות גם לטווח הבינוני (release) והארוך (road map).

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

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

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

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

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

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

בסוף טיפ 101 היה לנו את התכנון הבא לשני ה-sprint-ים הקרובים, שלפיו נצליח להשלים את Release 1 בסוף ה-sprint השני:

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

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

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

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

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

השימוש בפונקציה זאת ייתן לנו בלחיצת כפתור את התמונה:

אדום - משימות שצפויות להסתיים אחרי סוף ה-sprint.
כתום - משימות שהשתנו.

מאחר ו-Tester עמוס ביום חמישי, נעביר את משימה Test CCC אל Dev 1, כך שהתכולה המתוכננת ל-Sprint 1 תושלם במועד:


אם אין לנו תכנון מעבר ל-Sprint 1 לא נראה שהחלטה זאת גורמת לכך שלא ניתן יהיה לסיים את Release 1 במסגרת Sprint 2 !

אם נבין את הבעיה רק בתחילת Sprint 2 , יתכן שכבר לא נוכל לפתור אותה, אך אם נדע זאת קודם לכן, נוכל לתכנן מראש לשנות את תכולת העבודה בשבוע הראשון, כך שבסוף השבוע השני נספיק להגיע ל-Release 1:


מכיוון שמשימת Test CCC תתבצע רק במהלך Sprint 2, נעביר אותה אליו:


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


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

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