התשובה הקצרה
חוב טכני אינו נמדד באיכות הקוד אלא בעלות שהוא גובה מכל שינוי עתידי. לכן התעדוף אינו "מה הכי מכוער" אלא מה הכי מייקר את העבודה הבאה.
הכלל שממיין מהר: פריט שגורם לכך שכל שינוי באזור שלו דורש בדיקת רגרסיה רחבה - עולה ראשון. הוא מכפיל את עלות כל פעילות אחרת בתוכנית.
ניקוד בארבעה ממדים
| ממד | שאלה | משקל |
|---|---|---|
| חשיפה עסקית | מה קורה אם זה נכשל בשיא העומס? | גבוה |
| שכיחות | כמה פעמים ביום נוגעים בזה? | גבוה |
| תלות | כמה תחומים אחרים חסומים בגללו? | בינוני |
| מאמץ | כמה עולה לתקן בסביבה מבוקרת? | הפוך |
הניקוד אינו מדע. ערכו האמיתי הוא בכך שהוא מכריח שיחה מפורשת בין מי שמכיר את הסיכון הטכני למי שמכיר את הכאב העסקי - ומייצר סדר שאפשר להגן עליו מול מנהלים.
שלושה סוגי חוב שעוקפים את התור
בלי קשר לניקוד, שלושה סוגים עולים ראשונים:
- חוב שחוסם בדיקה - היעדר סביבת Sandbox תקינה או נתוני בדיקה. כל תיקון אחר שנעשה בלעדיו נעשה באפלה.
- חוב בהרשאות - מודל נראות שאיבד היגיון הוא חשיפה רגולטורית פעילה, לא אי־נוחות.
- חוב שמרוכז באדם אחד - כשרק אדם אחד מבין רכיב, הסיכון אינו טכני אלא ארגוני.
איך מציגים חוב כדי לקבל תקציב
הנהלה אינה מממנת "ניקוי אוטומציות". היא מממנת הפחתת זמן ועלות. התרגום נעשה בשלוש שורות לכל פריט: כמה שעות תמיכה הוא צורך ברבעון, כמה ימים הוא מוסיף לכל שינוי באזור שלו, ומה החשיפה אם הוא נכשל.
מי שמציג "שלוש בקשות שינוי ברבעון, כל אחת מתארכת בשבועיים בגלל אותו רכיב" מקבל אישור. מי שמציג דיאגרמת תלויות - לא.
מכסה קבועה, לא מבצע חד־פעמי
הדפוס שנכשל: פרויקט ניקוי גדול אחת לשנתיים. הדפוס שעובד: מכסה קבועה של 15%-20% מכל גל שמוקדשת לחוב, שנקבעת מראש ואינה נפתחת למשא ומתן בכל ספרינט.
לצד המכסה נדרש כלל מניעה אחד לפחות - למשל איסור על הוספת אוטומציה חדשה לאובייקט שכבר יש בו כמה, לפני איחודן. בלי מניעה, הקצב שבו נוצר חוב עולה על קצב הניקוי. הקשר לתשתית הפיתוח מפורט באסטרטגיית Sandboxes ו-DevOps.
סיכום
תעדוף חוב טכני הוא תרגיל בכלכלה ולא באסתטיקה: מתקנים את מה שמייקר את השינוי הבא, מקדימים את מה שחוסם בדיקה ואת מה שיוצר חשיפה, ומקבעים מכסה שמונעת חזרה. רשימה של עשרה פריטים מדורגים שווה יותר ממאה פריטים ממופים.