דפים

יום רביעי, 21 באוגוסט 2013

Agile Metrics - who needs them ?

במאמר הקודם כתבתי על הצורך בשבירת השגרה בצוותי אג'ייל (ראו ערך – Motivate your Agile team) . במאמר הפעם אגע בנקודה אחרת הקשורה לשגרת הצוותים – מדדים.
נושא המדדים יוצר לרוב תגובה ראשונית שלילית, שהרי אף אחד לא אוהב שמודדים אותו, ובכלל מדוע לשנות אם הסתדרנו עד עכשיו בלי?


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

מספר דוגמאות למדדי אג'ייל אפקטיביים –
1. Team velocity – הקצב הקבוע (או במילים אחרות ההספק) של צוות האג'ייל ביחידה אחת של ספרינט, ניתן כמובן לזיהוי ע"י מעקב אחר כמות ה story points שהצוות טיפל בממוצע במספר ספרינטים. אז כיצד הופכים זאת למדד? מה שאני מייעץ לחברות הוא עבודה בשלבים.
בשלב הראשון – במידה והקצב אינו קבוע, לזהות את ה velocity הגבוה ביותר שהיה עד כה, ולהגדיר אותו כיעד לספרינט הבא. 
בשלב שני (או במידה והקצב קבוע) – קביעת רף גבוה יותר של ה velocity ולהגדיר אותו כיעד לספרינט הבא. מה שחשוב לזכור הוא שהאמצעי אינו הוספת שעות עבודה של הצוות  או לחלופין הורדה באיכות התוצר בכדי לעמוד ביעד החדש, אלא חשיבה ממוקדת בהבנה מה מונע מאיתנו לייצר יותר בזמן הספרינט.
2. Planning coverage - לפני כל ספרינט מתבצע תכנון פרטני של המשימות ע"ב ה SBI (Sprint Backlog Items) אלו הן המשימות שעל הצוות לסיים במהלך הספרינט. מתודולוגיית האג'ייל אינה דורשת תכנון פרטני מעבר לתכולה הנוכחית, ומעדיפה את יתרון הגמישות (Agility) בשינוי הדרישות העתידיות, על פני התכנון המוקדם. יחד עם זאת כאשר ישנה יכולת לזהות את התכולות ההכרחיות (אלו אשר מחויבות להיכלל בגרסה) ישנו יתרון רב לצוות בתכנון פרטני קדימה גם מעבר לספרינט הנוכחי.
היתרון מתבטא במשמעות של הבנת התמונה בצורה רחבה ככל שניתן אשר על בסיסה יפותח הפתרון.
אז כיצד הופכים זאת למדד? אני מציע להגדיר שני מדדים שונים:
האחד - היכולת לכסות מספר ספרינטים קדימה בניתוח גס של התכולה.
השני – היכולת לכסות מספר ספרינטים קדימה בניתוח פרטני של התכולה.
3. Blockers – "בלוקרים" הן תכולות אשר החלו בביצוע בתוך הספרינט אך נעצרו לפני הגעתם לתחנה האחרונה. הסיבות יכולות להיות מגוונות – החל מחוסר במידע אשר התגלה בזמן הפיתוח, וכלה בתלות בפיתוח צד שלישי אשר אינו מוכן בזמן. מאחר והשפעת הצוות במקרים אלו על התכולות אינה קיימת, מומלץ לסמן משימות אלו כ"בלוקר", ולהמשיך במשימות הבאות תוך עדיפות לסיים את הטיפול בהן לכשימצא הפתרון.
המדד המתבקש הוא כמות ה"בלוקרים" הקיימת בספרינט אחד של תכולה.

שורת סיכום
כפי שציינתי במאמר, מדדים הם כלי חשוב מאד בעמידה ביעדי הגרסה, והיכולת לנטר ולבקר את התקדמות הגרסה. מתודולוגיית האג'ייל השכילה להטמיע את נושא הפקת הלקחים כחלק מהתהליך ובכך לאפשר להתייעל בצורה אפקטיבית יותר, ברמת ספרינט (ולא רק בסיום גרסה).
יחד עם זאת אני רוצה לציין גם את הצד השלילי של מדדים. מדדים אשר אינם מוגדרים בצורה נכונה כמוהם כיעד שגוי אשר אליו אנחנו מנווטים את האונייה. הם אלה שבדר"כ קופצים לנו ראשונים לאחר שבחנו את תוצאות הגרסה האחרונה, והם אלה המסוכנים ביותר.
מספר דוגמאות פופולריות –
- כמות ה Story points שהפיתוח הצליח לפתח בספרינט.
מדד זה אינו רלוונטי, שכן אינו מספק כל "ערך" ללקוח. (המדד הנכון יהיה כמות ה features אשר הגיעו לרמת Done בסיום הספרינט)
- כמות ה defects אשר הפיתוח מצליח לסגור בספרינט
מדד זה אינו רלוונטי שכן אינו מספק כל מידע באשר לאיכות התוצר. (המדד הנכון יהיה כמות ה defects שנשארו פתוחים בסיום הספרינט)

בהצלחה !

*אם יש לכם תהיות והתלבטויות הקשורות לייעוץ והכוונה בנושא –
צרו קשר – yogev05.t@gmail.com

יוגב טל, PMP



בחזרה לעמוד הבית - מרעננים את הפיתוח

אין תגובות:

הוסף רשומת תגובה