טיפ 100: מעקב אחרי Scrum sprint

המטרה: לצמצם את הנזקים לטווח הקצר הנובעים משינויים במהלך ה-sprint.

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

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

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

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

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

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

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

בסוף הטיפ הקודם היה לנו תכנון כזה ל-sprint:

וידענו גם איפה יש בו spare-ים:

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

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

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

כתום - משימות שהשתנו.

אם, לעומת זאת, ההגדרה נדרשת עבור משימה CCC:

נראה מיד שנוצרה לנו בעיה בהשלמת Feature Y ב-sprint הנוכחי.

בתצוגת הגנט אנחנו רואים שהאיחור נובע מאי זמינות של Tester ביום האחרון של ה-sprint.
בתצוגת Resource Usage ניתן לראות ש-Dev1 יהיה פנוי באותו יום:

בהנחה שהמפתחים יכולים לבצע גם פעולות בדיקה (פרקטיקה מקובלת בחלק מן החברות), נעביר אליו את המשימה המאחרת ובעזרת פונקציית ה-Resource Leveling של הגנט נוודא שפתרנו את הבעיה:

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

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

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