Posts tagged ‘חוב טכני’

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

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

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

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

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

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

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

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

 

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