Posts tagged ‘Definiton of Done’

ספרינט ייצוב.

בואו ננסה להגדיר מהו ספרינט ייצוב – ספרינט(ים) שמתבצע(ים) לאחר שהסתיים המימוש של התכולה לגירסא הנכחית. בספרינט כזה לא מתווספת פונקציונאליות חדשה למוצר, אלא מתעסקים ב”ייצוב” הפונקציונאליות הקיימת, הכוונה בייצוב היא פעילויות כגון תיקון באגים, ביצוע בדיקות נוספות, שיפורים לקוד שנכתב כגון Refactoring או תוספת של כיסוי אוטומטי ע”י בדיקות אוטומטיות , שיפורים אחרונים של ה-Installer ועוד מיני סתימת חורים.

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

בקורסים שאני עורך, אני בד”כ מעלה את השאלה הבאה לדיון קבוצתי:

מה יותר חשוב – יותר פיצ’רים או הגדרת DONE רחבה יותר ?
כמובן שאין תשובה חד משמעית לשאלה הזאת אבל הדיון בד”כ מעלה את העובדה ש”קיצוץ” בהגדרת ה-Done שלכם מוביל באופן מיידי ל:
– צורך בסגירת הפערים הללו = צורך בספרינטים של ייצוב.
– הורדת רמת השקיפות עקב חוסר ידיעה ומדידה של כמה זמן לוקח ייצוב.
– פגיעה ברמת האמון בין ה-PO לבין הצוות עקב אי יכולת לכמת את המאמץ שחסר.

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

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

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

 

* מקור התמונה : http://www.flickr.com/photos/jonasb/364606089/

אלמנטים של סקראם…מה זה DONE ?

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

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

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

בואו נתבונן רגע בהגדרת DONE:

  • הקוד גמור
  • בדיקות גמורות
  • הפיצ’ר אושר ע”י מנהל המוצר.

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

  • הקוד גמור
  • נכתבו Unit tests והם רצים בהצלחה.
  • נכתבו Integration tests והם רצים בהצלחה.
  • הבדיקות התווספו לתשתית האוטומציה.
  • הפיצ’ר תועד (לפי הצורך).

מה אתם אומרים עכשיו? בודאי שההגדרה הזאת טובה יותר ומחדדת את ההגדרה אבל עדיין… זה לא זה. ניקח למשל את הסעיף של הבדיקות Unit tests. האם מובטח שהבדיקות מקיפות ומספיקות. אז שוב, גם ההגדרה הזאת איננה מבטיחה מוצר פוטנציאלית מוכן.
אין לי כוונה לסקור כעת טכניקות להגדרת ה-DONE (פוסט אחר), אבל הנקודה שרציתי להעביר היא שהאיכות של הגדרת ה-DONE הינה גורם קריטי להצלחת הפרויקט.

את הגדרת ה-DONE קובעים ביחד ובהסכמה מנהל המוצר והצוות, ובד”כ ההגדרה משתנה עם הזמן ובהתאם למה שהצוות מסוגל לספק, אבל אמרנו שמוצר פוטנציאלית מוכן הוא מוצר ש-100% מהפיצ’רים שלו הם DONE, אז מה קורה כשההגדרה משתנה, ובפרט מתרחבת? אז נוצר מצב שבו כל הפיצ’רים שפותחו עד כה הם לא DONE. נכון. במצב כזה על הצוות להביא את הפיצ’רים הללו למצב DONE.

האדם שאחראי להחליט האם המוצר או הפיצ’ר הוא DONE הוא מנהל המוצר, הוא אחראי לוודא שהצוות אכן עומד בקריטריונים המתבקשים, זה קורה בישיבת סוף הספרינט – Sprint review.

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

נ.ב. – התוספת של התמונות לפוסטים מפריעה? מוסיפה? לא משנה? – אנא תגובתכם.

זהו – אני סיימתי – …I am DONE

 

*מקור התמונה : http://www.flickr.com/photos/hawaii-mcgraths/2701705139/lightbox/