דפים

יום ראשון, 22 בפברואר 2015

על מה כל המהומה – Technical Debt

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

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

המונח "חוב טכנולוגי" הוטבע בשנות ה-90 ע"י מתכנת אמריקאי בשם Ward Cunningham - חלוץ בתחומי חשיבה מובילים של המאה ה-20 בהם: “extreme programming” , "design patterns" ועוד..
"חוב טכנולוגי" (Technical debt) – "מטאפורה המתייחסת להשלכות עתידיות של תכנון מערכת / ארכיטקטורה / או פיתוח לקויים" (Wikipedia)

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

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

נשאלת השאלה האם כל חוב טכנולוגי הוא שלילי?
לא בהכרח.
נחזור למטאפורה – אדם (או גוף כלכלי) יכול לעיתים לקבל החלטה במודע בדבר לקיחת הלוואה או חוב עבור פרויקט מסוים (כגון  -קניית דירה). במקרה זה, החוב לא נוצר כתוצאה מתפקוד לקוי, או חוסר הבנה, אלא מאילוץ מרכזי אחר – אילוץ הזמן. ההנחה היא שבנקודת זמן מסוימת למרות חוסר משאבים, ישנה אפשרות שביצוע העסקה (כגון רכישת דירה) ישתלם לנו בעתיד.
בעולם הטכנולוגי – זה יכול להיות מענה מהיר למכרז אשר יכול להוביל לפרויקטים עתידיים, או לדוגמא POC (Proof of Concept), אשר צריך לצאת מהר להדגמה מול לקוחות.
במקרים אלו בשל אילוץ הזמן, ייתכן ובמודע הארכיטקטורה או הקוד של המוצר יצטרכו לעשות כתיבה מחדש (refactoring) בעתיד, אך בשורה התחתונה זכייה במכרז (או ב POC) שווה תשלום חוב זה.

מהם הדרכים למנוע חוב טכנולוגי?
אציין מספר גורמים מרכזיים -
"סגירות" של עבודה - ביצוע משימה בצורה חלקית הינו אחד גורמים המרכזיים ביצירת חוב טכנולוגי.
משימה אשר לא הושלמה כראוי תגרור חובות אשר נאלץ להתמודד עימם בנקודה מסוימת בעתיד. בהתמודדות עם משימות יש לשאוף ל"סגירות" של המשימה בכל הרמות: רמת הדרישות, רמת הקוד  ורמת כיסוי הבדיקות. הגדרת Definition Of Done (DOD) בכל רמות אלו, לפני תחילת המשימה תעזור בווידוא "סגירות" זו.
איכות הקוד – איכות הקוד הינה עולם מהותי ומרכזי בפני עצמו. מספר התקלות ורמת החומרה שלהן (severity) יכול בהחלט להעיד על תוצר לקוי, אך חושפת אך במעט את רמת איכות הקוד במוצר. השקעה במבנה נכון של הקוד (code structure), Naming Convention, duplicate logic reduction, וכיו"ב, יגרמו לכך שהחוב הטכנולוגי שלנו יהיה נמוך (אם בכלל)
Ad-hoc Respond – הגדרת אזורים אשר בהם יש צורך לבצע טיפול בצורה מידית וללא דיחוי מרגע שזוהתה בעיה. כגון -   Build failure, Automatic testing failure, high severity defects, etc ... כל דחייה בטיפול באזורים אלו ירחיב את "החוב הטכנולוגי".
Development method – אין ספק שלמתודולוגיית הפיתוח יש חשיבות רבה בכל הנוגע ל"חוב הטכנולוגי". בבסיס מתודולוגיית האג'ייל עומד נושא "סגירות" המשימה על שלל רבדיו - החל מהגדרת Definition of Done, דרך צוותים הטרוגניים, התקדמות ע"ב ערך, קבלת פידבק מהיר מהלקוח, טיפול בשגיאות, ועוד.. (הרחבה בנושא אג'ייל ניתן למצוא כאן)

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

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


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

יוגב טל, PMP
Project Manager, Agile Mentor
PMI Israel E-Magazine Editor

Picture source - http://www-tc.pbs.org/wnet/need-to-know/files/2011/10/StudentDebt-Post.jpg

אין תגובות:

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