בלוג > טיפים למשתמשי MS-Project

טיפ 99: תכנון Scrum sprint

המטרה: להכניס יותר תכולה ל-sprint בשלב התכנון.

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

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

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

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

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

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

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

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

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

1. לקבל יכולת טובה יותר של חיזוי זמנים.
2. לבצע אופטימיזציה שוטפת, כדי להקדים את התאריכים המתקבלים.
3. להבין את השפעתו של כל שינוי (בהנחה שהם רבים ותכופים) על לוח הזמנים, על מנת לקבל החלטות מתאימות בהקדם האפשרי.

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

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

נשתמש בדוגמא הפשוטה הבאה:
נניח שיש לנו צוות של 3 אנשים, ששניים מהם מפתחים ואחד מבצע בדיקות ידניות + אוטומטיות.
הם מפתחים תוכנה בסבבים (sprints) של שבוע.
ה-backlog שלהם נראה כך:

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

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

לפי התאוריה ה-Scrum-ית כל אחת ממשימות הפיתוח ניתנת לביצוע על ידי כל מפתח ואין תלויות בין המשימות ובין הצוותים. אם זה אכן היה המצב, מאחר ויש לנו 2 אנשי פיתוח (= 10 ימי עבודה) ואיש בדיקות אחד (=5 ימי עבודה), היינו יכולים להכניס ל-sprint הקרוב את משימות 1-5.

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

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


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

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

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

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

בנוסף, אם נניח שמשימות AAA ו-EEE משלימות feature בשם Feature X, ומשימות BBB ו-CCC משלימות feature אחר בשם Feature Y, הגנט יראה לנו שלפי תוכנית זאת נצליח לסיים רק אחד מן ה-features הנ"ל במסגרת ה-sprint הנוכחי:


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

למרות שבמקור העדיפות של כל המשימות היתה שווה, ננסה להעלות טכנית את העדיפות של משימה EEE, כדי שהגירסה שתתקבל בסוף ה-sprint תכלול גם את feature X:


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

לכן נפרק את משימה EEE לשתי משימות (stories) בנות יום אחד כל אחת, ונקצה אותן לשני מפתחים במקביל. על ידי מתן העדיפות הגבוהה למשימה EEE, נגרום לכך שהיא תתבצע ראשונה. בעקבות זאת יוכל ה-Tester להתחיל את הבדיקות מוקדם יותר, כך שנוכל לנצל יותר ימי עבודה שלו במהלך ה-Sprint:


לפי התוכנית שקיבלנו עכשיו, יושלם Feature X בזמן (שורה 13 בגנט), אבל Feature Y (שורה 14 בגנט) יסתיים מאוחר מדי, ולכן נחזור על אותו "תרגיל" עם משימה BBB.

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

נקבל:

המאמץ השתלם! הצלחנו להגיע למצב בו יש לנו תוכנית שבעזרתה מספיקים להשלים יותר stories ויותר features במהלך ה-sprint.

חשוב לשים לב שאם חלק מן השיפורים לא היה מתוכננים מראש, הוספתם בהמשך כבר לא היתה מביאה שיפור!

תצוגת ה-Resource Usage מראה לנו גם היכן נשארו לנו ימי spare ואצל אילו משאבים:

מידע זה עשוי לשמש אותנו בהמשך, בשלב המעקב, ועל כך בטיפ 100.

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


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