הגדרת המוכנות (Definition Of Done) היא אבן בסיס חשובה מאד בתהליך ה Scrum.חשיבות הגדרה זו מתעצמת פי כמה בתהליך של Scaling Agile.
מהם הכללים הנכונים להגדרת DOD?
מהן ההשפעות של הגדרה שגויה על ה Release cycle?
במרבית המקרים, ארגון אשר מתעניין בהטמעת הגישה האג'ילית, יבחר תחילה להתנסות בה בהקמת צוות אחד - מספר אנשים מצומצם אשר יקבלו משימה, וינסו לבצע אותה במודל ה Scrum. בהנחה שהמודל צלח, יחל עתה הארגון 'מסע' (Journey) לא קטן בניסיון להרחיב את ההטמעה לצוותים נוספים בארגון. מסע זה נקרא - Scaling Agile.
השימוש במילה 'מסע' הוא לא בכדי.
זהו תהליך ארוך (ואינסופי) של התנסות, בדיקה ותיקון, אשר יאתגר את הארגון לא מעט.
Potentially Shippable Product (PSP)
כחלק
מעקרונות ה-Scrum
נדרשים צוותי הפיתוח לייצר בסוף הספרינט תוצר אשר מוגדר כ – Potentially Shippable Product.
עבור ארגונים
רבים ההגדרה הזו היא עמומה מאד, שכן המילה Potentially יכולה להתאים למגוון רב של תרחישים. נוסיף על כך שתהליך ה- scrum הוא
גם כך מסובך דיו, הרי שקיבלנו שהנטייה הטבעית הינה למשוך לכיוון "מוחלש"
של ההגדרה.
בארגונים
כאלו בסיום ספרינט נקבל הכרזות כגון -
-
"הצלחנו
לייצר PSP בסוף הספרינט, אך עדיין נותרו לנו מספר bugs שלא
הספקנו לתקן"
או למשל
-
"הצלחנו
לייצר PSP
בסוף הספרינט, אך עדיין לא הספקנו לעשות merge to main branch"
למעשה
המצבים שתיארתי מעלה, אינם בעייתיים לכשעצמם כאשר הארגון נמצא בתחילת דרכו באימוץ
המתודולוגיה. הבעיה מתחילה לצוץ כאשר הארגון "משרש" צורת התנהגות זו
כנורמה, ולמעשה מקבל את ההנחה ש"אין מה לעשות" וזהו ה"תשלום" אשר
נדרש עבור עבודה ב scrum.
חשוב
לדעת כי כוונת המשורר (או המשוררים במקרה זה) הייתה שונה, וכוונה לקחת את
"מוכנות המוצר" לרמה הגבוהה ביותר האפשרית. רמה אופטימלית, המוגדרת כשלב
שבו סיימנו את כל העבודה הטכנית על סט הדרישות עליו עבדנו במהלך הספרינט, ולמעשה מרגע
זה ההחלטה אם לשחרר או לא את המוצר בשלב זה ללקוח, הינה החלטה עסקית בלבד.
כיצד
ניתן להגיע לרמה זו?
בשלב ה
planning מציג ה PO לאנשי הצוות מספר חבילות תכולה (PBI) אשר
עליהם הם מתבקשים לעבוד במהלך הספרינט. היכולת של הצוות להגיע לרמה גבוהה הנדרשת בסיום
הספרינט, תלויה ברמה שבה הגדרנו מהו סיום העבודה על חבילת תכולה בודדת.
במילים
אחרות, רמת ה – Definition
of Done על PBI בודד תקבע לנו את רמת "המוכנות הטכנית" של התוצר בסיום הספרינט.
ככל שההגדרה
תהיה חדה, מקיפה יותר, וקרובה יותר לסיום מוחלט של עבודה,
כך
ה"חוב" או כמות ה- Undone אשר תיוותר בסיום הספרינט תהיה נמוכה.
בשורה
תחתונה - אם נתקדם בצורה זו, בה כמות ה Undone בכל ספרינט תהיה נמוכה, הריי שבכך קיצרנו את
ה Cycle time עבור הגרסה כולה.
Scaling up
במונח Scaling up
אתייחס בשני אופנים-
1. הגדלת
מספר צוותי ה scrum אשר עובדים במקביל על אותו
המוצר.
באופן
כללי, ככל שמספר הצוותים עולה, כך עולה רמת "הסיבוך" (complexity)
ביצירת המוצר.
על מנת
לטפל נכון במצב זה, ישנם שני עקרונות חשובים אשר נצטרך לשמור עליהם -
a. הגדרת
ה DOD הינה ברורה ואינה משתמעת לשתי פנים.
b. הגדרת
ה DOD
הינה אחידה לכל חבילת עבודה (PBI), ולכל הצוותים אשר עובדים על אותו המוצר.
קיום
חלקי של אחד או שני עקרונות אלו, יגרור "רמת חוב" גבוהה בסיום כל ספרינט,
אשר עליה נאלץ לשלם בשלב סגירת הגרסה.
2.
הרחבת הגדרת ה DOD.
אם הצלחנו
לעמוד בכל היעדים הטכניים בסיום כל חבילת עבודה, אזי נשאלת השאלה מדוע להיעצר כאן?
האם
ישנן חבילות עבודה נוספות אשר אנו נדרשים "לשלם" עליהם לפני שנוכל לשחרר
את המוצר?
במרבית
הארגונים יוגדר זמן בסיום עבודת הפיתוח אשר מיועד ל"הכנת הגרסה לשחרור"
(נקרא בשמות שונים כגון – hardening, Stabilization, etc..)
בשלב
זה מבצעים פעולות שונות כגון – Regression, Automation, Performance, Documentation, etc ..
ניתן להתייחס גם לפעולות אלו כאל חוב
(Undone work)
אשר אותו לא הצלחנו לסיים במהלך הספרינטים. גם כאן, בדיוק באותו האופן, אם נצליח
להרחיב את הגדרת ה DOD, כך שתכיל תכולות מעבר לרמה הטכנית (כגון Documentation, Performance,
etc..) אזי נוכל לקצר משמעותית את הזמן הנדרש לנו
לשחרר את המוצר בסיום תקופת הפיתוח.
שתי
הערות סיכום חשובות
1. מהסיבות
שהוזכרו לעיל, על מנת למנוע את ההגדרה "העמומה", מומלץ לכנות את התוצר
אשר מתקבל בסיום הספרינט כ – Shippable product Increment
ובכך
לחזק את התפיסה שרמת התוצר בסיום כל ספרינט צריכה להיות גבוהה. (ברמה הטכנית לפחות)
2. יש
לשים לב למעברים בהגדרת DOD בארגון. בעוד שהמעבר להגדרה חדה וברורה צריך
להיות מידי, הרי שהמעבר להרחבת ההגדרה צריך להיות הדרגתי, על מנת לאפשר לצוותי זמן
ללמוד ולעכל את השינוי.
אין תגובות:
הוסף רשומת תגובה