כאשר
מפתחים מוצר, תקלות (bugs or defects) הן
בלתי נמנעות. הנטייה הטבעית גם בצוותי אג'יל היא לשייך אותם לרשימה (bug
list) אשר תטופל בהמשך בזמן מתאים יותר. האם זוהי ההתנהגות הנכונה? מהי השפעתה על גוף הפיתוח?
קצת רקע
בשלהי
שנות ה 70 אומצה מתודולוגיית "פס הייצור" של המכוניות לתעשיית התכנה (וקיבלה
את השם Waterfall). מתודולוגיה
זו התבססה על העיקרון כי בתהליך ייצור יעיל לכל איש מקצוע (או קבוצה) יש את השלב
הנכון שבו עליו לעבוד על המוצר. אם יעבוד בשלב מוקדם או מאוחר יותר הרי שבכך יפריע
לתהליך או ייוצר מוצר פגום. בתהליך "האימוץ" לתעשיית התכנה הופרדה
העבודה בין בעלי המקצוע השונים – מנהלי מוצר, ארכיטקטורה, מפתחים ובודקים.
כל
קבוצה קיבלה את רצועת "הזמן שלה" בתהליך הייצור והיה עליה לעמוד ביעדיה.
שלב
הפיתוח היווה את "רצועת הזמן" המרכזית בה נמדדו אנשי הצוות על הספק
הפיתוח.
תקלות שזוהו במהלך הדרך התווספו לרשימה (bug
list) ויועדו לטיפול בהמשך בזמן "מתאים
יותר" אשר במרבית המקרים היה רצועת הזמן הבאה – שלב הבדיקות.
מתודולוגיית
האג'יל (agile) פותחה בשנת 2001 ע"י מומחים בתחום
תעשיית התכנה. מתודולוגיה זו שינתה את האקסיומה של קודמתה (waterfall) בכך שטענה שתכולת המוצר אינה דבר קבוע אלא משתנה, ועל כן שיטת
"פס הייצור" אינה מתאים לתעשיית התכנה.
מאז
ועד היום התרחב השימוש במתודולוגיה זו בעיקר בתעשיית התכנה.
טיפול
בתקלות
על אף ההבדל
התפיסתי והמהותי בין שיטת האג'יל לקודמתה (ראה הרחבה כאן), הטיפול
בתקלות במרבית המקרים נשאר זהה – ייצור רשימות של תקלות אשר יטופלו במועד
"מאוחר יותר".
מספר
סיבות אופייניות לכך:
- לחץ
מצד ההנהלה להתמקד בתכולה (בה רואים התקדמות) על פני תיקון תקלות.
- העדפה
מצד אנשי הפיתוח ליצור תכולות חדשות מאשר לתקן קיימות.
-
נוחות במסווה של שליטה – כל עוד התקלות נמצאות ברשימה מסודרת, לא יהיה קשה לטפל
בהם בעתיד.
-
הגדרה "רכה" ל Definition Of Done של יחידות התכולה (PBI).
ככל שמספר
הספרינטים (איטרציות) בגרסה יהיה גדול יותר, כך תתארך רשימת התקלות שיש לטפל בהן.
כיצד
מסתיים תהליך זה?
אציין
כאן מספר תשובות אופייניות, ומדוע הן אינן יעילות.
-
דחיית הטיפול בתקלות ל "תקופת ייצוב" בסוף תהליך הפיתוח
"תקופת
ייצוב" הינה תקופה אשר במרבית המקרים מוגדת כאשר תכולת המוצר גדולה, וחסרים
תהליכים אוטומטיים אשר יכולים להבטיח לנו את תקינות הקוד אשר נכתב עד כה.
בתקופה
זו מבצעים בדיקות מקיפות על המוצר לפני שחרורו. הבעיה העיקרית בפתרון זה הינה
הערכת גודל תקופה זו. במידה והערכה בחסר – יצא המוצר ברמת תקינות נמוכה (או ידחה
שחרורו). במידה והערכה ביתר – יתקיים זמן פיתוח לא מנוצל. בנוסף, במרבית המקרים תתקשה
ההנהלה להימנע מהוספת תכולה בזמן זה, דבר שיגרור קונפליקטים חוזרים פנים ארגוניים.
-
שחרור במודע של המוצר עם רמה גבוהה של תקלות לשוק
בגישה
זו תיקון התקלות יתבצע רק לאחר שזוהה והתבקש ע"י הלקוח.
מאחורי
פתרון זה קיימת תפיסה אשר טוענת שאחוז גבוה מהתקלות כלל לא יובחנו ע"י הלקוח, ועל כן ניתן לדחות את הטיפול בהן לכשיגיע הצורך. הבעיות עם פתרון זה הן רבות – החל
מרמת אמינות המוצר מול לקוחותיו, דרך הטיפול המתמיד "בשאריות" מתכולות
קודמות (ראה מאמר קודם בשם Technical Debt בנושא), וכלה בחוסר יכולת הארגון
לעמוד ביעדיו העתידיים בשל חובות "לא ידועים".
- לקיחת
פסק זמן באמצע שלב הפיתוח לטובת "טיפול בתקלות" (כדוגמת 1-2 ספרינטים)
לכאורה
נראה כפתרון המתאים ביותר, בהגיע סף מסוים של תקלות עוצר כל גוף הפיתוח, ומתחיל
להסתכל פנימה לתיקון התקלות שיצר עד כה. אך כאן מתעוררות השאלות הבאות – כיצד
קובעים סף זה? מה קורה כאשר גוף הפיתוח נמצא באמצע פעילות על תכולה בנקודת הסף? מה
קורה כאשר מסתיים הזמן שהוקצב ומספר התקלות עדיין רב?
לכל
פתרונות אלו קיימת סיבה נוספת, המהותית ביותר מדוע הן אינן יעילות – אפקטיביות הפיתוח.
1. בתיקון של תקלה קיימים שני שלבים עיקריים – שחזור התקלה, והתיקון עצמו. מחקרים מראים כי
מרבית הזמן בתיקון תקלה יושקע דווקא בשחזור התקלה, ולא בתיקון עצמו. בכל הפתרונות שהצגתי לעיל קיים יחס ישיר בין זמן שיחזור התקלה לבין המועד בו זוהתה. אפקטיביות הטיפול בתקלות תהיה נמוכה ככל שהזמן בין פיתוח הקוד לבין הטיפול
בתקלה יתארך.
2.
ניהול רשימת התקלות – רשימת התקלות דורשת תשומת לב ניהולית, תעדוף, "ישיבת
ניהול באגים" וכיו"ב.
3. בין
רשימת התקלות יכולה "להסתתר" תקלה מהותית, אשר תדרוש אפיון מחדש של הפתרון.
ההשפעה של תקלות מסוג זה על המוצר תגדל ככל שיעבור זמן מרגע זיהויה לבין פתרונה.
אז מהי
"הדרך הנכונה" ?
טיפול
בתקלות צריך להתבצע בזמן הקרוב ביותר לרגע זיהוי התקלה.
בזמן
זה זמן השחזור הינו הקצר ביותר, ואפקטיביות הפיתוח (גם בטווח הקצר, וגם בטווח
הארוך של הגרסה) הינה מרבית.
האיטריציות הקצרות, המובנות בבסיס מתודולוגיית אג'יל, למעשה כבר נותנות לנו את הכלים למימוש דרך זו.
כיצד
עושים זאת? ע"י שני מנגנונים –
1.
הקשחה של Definition Of Done עבור
כל יחידת תכולה (PBI)
2.
הגדרת מדדי
ביצוע קשיחים ברמת הגרסה
שורת
סיכום
חשוב
לציין כי כמו בכל דבר בעולם התוכנה אין פתרון הרמטי לכל בעיה קיימת. גם כאן סביר
להניח שיהיו מקרי קצה שבהם יקבל הארגון החלטה שונה באילוצים כאלה ואחרים. יחד עם
זאת אם יגדיר הארגון את קווי הבסיס לטיפול בתקלות בצורה הנכונה הרי שבכך תגדל
אפקטיביות גוף הפיתוח שלו.
יוגב טל
Senior Project
Manager, PMP,
Agile Transformation
Lead,
PMI Israel E-Magazine
Editor
Picture source -
בחזרה לעמוד הבית - מרעננים את הפיתוח
אין תגובות:
הוסף רשומת תגובה