Posts tagged ‘backlog grooming’

זה גדול מידי.

imageאתם עובדים בסקראם. ספרינטים של שבועיים. הצוותים בנויים נכון (Feature teams). יש לכם בקלוג. בבקלוג של דרישה של לקוח, ואפילו בפורמט של סיפור לקוח (User story). כבוד!

אבל מה? אין ממש אפשרות לפתח את כל הדרישה בשבועיים. איזה אפשרויות כן עומדות לפניכם?
1. להאריך את הספרינט – נו, לא רעיון משהו, כבר נכתב ונאמר מספיק על החסרונות שבשינוי אורך הספרינט, וחוץ מזה מה אם הוא אמור לקחת 3 חודשים?
2. לחלק את סיפור הלקוח בשיטת הסלאמי (ראו פוסט קודם)
3. לחלק את סיפור הלקוח ל….
סיפורי לקוח קטנים יותר. הופה, הנה רעיון :)


תזכורת: סיפור לקוח הוא מהזוית של הלקוח ומשמעותו – משהו שאפשר ממש להדגים ללקוח)


לפני שאני אתן קצת דוגמאות, אני רוצה להסביר את היתרונות של חלוקה כזו:
– אפשר לקבל פידבק מוקדם הרבה יותר: למשל לא צריך לחכות עד שייסתיים הפיתוח בכדי להבין שהעיצוב לא מתאים.
– אפשר להבין טוב יותר את מידת הנכונות של הערכת המאמצים:. למשל אם חלק שחשבנו שדורש בערך רבע מהמאמץ להשלמת הדרישה לוקח ספרינט שלם, אפשר לנחש שכל הפיצ’ר ייקח 4 ספרינטים.
– אפשר לעצור באמצע:. קורה לא פעם שהלקוח לא באמת צריך את כל הפונקציונאליות עד הפרט האחרון, כשמפתחים את הפיצ’ר בשיטת הסלאמי למעשה עובדים בשיטת “הכל או כלום”, לעומת זאת כששוברים את סיפור הלקוח לחלקים קטנים יותר מבחינה פונקציונאלית אז ניתן בכל רגע להגיד “אוקיי, זה מספיק לנו, בואו נעבור לפי’צר הבא”.

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


דוגמא 1 – תוכנה לניהול רשת: בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של המשתמשים במערכת לפי חתכים שונים כדי להודיע הודעות דחופות שקשורות לרשת
ניתן לשבור אותו כך: (אני מוותר על ה”כדי”)

1. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של כל המשתמשים במערכת
2. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת אשר שייכים למחלקה מסוימת.
3. בתור אדמיניסטרטור אני רוצה אפשרות לשלוח הודעה למסך של משתמשים במערכת בעלי תפקיד מסוים
…..

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


דוגמא 2 – עיבוד תמלילים: בתור משתמש אני רוצה להיות מסוגל לשמור את הקובץ שלי במיקום ובשם ע”פ בחירתי.

1. בתור משתמש אני רוצה לקבל הודעה כששם הקובץ שבחרתי לא חוקי
2. בתור משתמש אני רוצה לקבל הודעה כשאין מספיק מקום אחסון בדיסק.
3. בתור משתמש אני רוצה לקבל הודעה כשאין לי הרשאות שמירה.
4. בתור משתמש אני רוצה לשמור את הקובץ למקום מוגדר מראש
5. בתור משתמש אני רוצה לבחור את המיקום של הקובץ
6. בתור משתמש אני רוצה לבחור את שמו של הקובץ

שברנו את הסיפור שוב ע”י שימוש בשתי טכניקות: הראשונה היא למצבי שגיאה (1-3) זה בעיקר שימוישי לסיפורים מורכבים מאוד. הטכניקה השניה היא ע”י התחלה מפיצ’ר עם מגבלות קשות (מה שנקרא Hard coded) והסרתן של המגבלות אחת אחרי השניה.

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

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

כמה זה מספיק ?

אחד הדברים שהתפיסה האג’ילית מדברת עליהם הוא פשטות ולעשות "מספיק" (Just enough).
כמה זה "מספיק"?
מספיק זה לא פחות ממה שצריך אבל גם לא יותר, בעיקר לא יותר.

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

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

בין השאר גם מדובר ביותר מידי תכנון.
בניגוד לפרויקטים המנוהלים בשיטת המפל, בפרויקטים אג’ילים אין שלב תכנון אחד ארוך ויסודי, אנחנו מנסים לתכנן במיה מספקת, והמידה הזו למשל שונה לגמרי בין פרויקט לפרויקט, אבל הנטייה שלי היא להאמין שבפרויקט מסוים מידת התכנון קדימה הדרושה נשארת פחות או יותר קבועה לאורך ציר הזמן של הפרויקט.
ברגע שהחלטנו מה מידת התכנון שאנו רוצים רצוי לעקוב ולראות שאנחנו מבצעים אותה.
בסקראם מקובל שבכל ספרינט מתכננים "מספיק" קדימה כדי לשמור על אופק ברור, עושים את זה ע"י פעולה שנקראת Backlog grooming או Backlog refinement. זו פעולה שבה הצוות מטפח את הבקלוג ע"י טיפול בפריטים עתידיים – הערכת מאמצים, שבירה של הפריטים, שיפור של התיאור והבהרות שונות. אבל הנה שאלה? כמה זה מספיק תכנון, ואיך עוקבים אחרי העובדה שעשינו מספיק ?

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

זהו כלי פשוט למימוש שנותן תשובה ויזואלית מאוד לשאלה "האם אנחנו מתכננים מספיק?". ראו שתי דוגמאות:

דוגמא לבקלוג עם רמת תכנון לא עקבית – לחצו על התמונה להגדלה:
clip_image004

דוגמא לבקלוג עם רמת תכנון עקבית – לחצו על התמונה להגדלה:
clip_image006