בקצרה:
חובות טכניים הם רע הכרחי אך יכול להיות במיעוטו. יש כל מיני דרכים להתמודד איתו שבראשונה היא שינוי התפיסה ולהפוך את החובות הטכניים לחלק מהחיים בתצורה של פיצ’רים ולקיחת האחריות של כל הצדדים במשחק על להקצות את הזמן הדרוש לעמוד באיכות הנדרשת. שנית יש כל מיני דרכים טכניות לחלק את הזמן כך ש-20-30 אחוז מהזמן יוקדש לכך בין אם על ידי הקצאת יום בשבוע, או מפתח בספרינט או משימה 1 מכל 4 או זמן מסוים מכל משימה. וסיכמנו עם כמה מדדים שיעזרו לנו לצמצם ולעמוד על האיכות הנדרשת של הקוד.
בהרחבה:
בפוסט הקודם, ניסינו להגדיר באיזה חוב טכני נטפל ובאיזה לא, וקצת על איך לקטלג את החוב הטכני. ועכשיו הגיע התור של להבין איך לטפל בו.
פתרונות רוחביים (שגם) משנים תפיסה
לפני שנגיע לפתרונות הטכניים, צריך לשנות מספר דברים ברמה הרוחבית של העבודה בפיתוח
- הכנסת תיקוני הקוד לבקלוג כפיצ’ר לכל דבר: תיקוני קוד הם פיצ’רים לכל דבר.לכן יש להכניס את תיקוני הקוד כפיצ’רים לכל דבר לבקלוג כך שיהיו שקופים וברורים לכל בעלי העניין.
- הצגת הערך העסקי של תיקון הקוד והאינטרס המשותף: אנשי המוצר לא “דוחפים” לנו פיצ’רים חדשים על פני תיקון קוד קיים. יש פה אינטרס משותף למוצר עובד ואיכותי ולכן כמו שכל פיצ’ר צריך להוכיח את הערך העסקי שלו, כך גם תיקוני קוד יש ערך עסקי שצריך להסביר, גם אם חלקו הוא עבור הלקוחות הפנימיים בארגון.
- האחריות האישית להקצאת זמן נכונה: זה האחריות של אנשי הפיתוח לתת הערכות שכוללות מספיק זמן כדי לכתוב זמן כמו שצריך, לכלול ב-Definition of done גם את האוטומציה לטסטים. וזו האחריות של אנשי המוצר לדאוג לפיצ’רים שמתפתחים באופן הדרגתי ומכילים את כל מה שצריכים כדי לעמוד באיכות נדרשת. פיתרון אפשרי הוא להכניס מתודולוגיות כמו TDD – Test driven dev. לא צריך בהכרח לאמץ את כל השיטה, אבל כן לייבא ממנה תובנות להתנהלות איכותית יותר.
- יצירה ושמירה על סטנדרט כתיבת קוד: רואים את זה בחברות גדולות, אבל נכון גם לחברות קטנות: שמירה מתמדת על סטנדרט מסוים של כתיבה, לוגיקות ברורות שמועברות בחפיפה מסודרת ושיכתוב מתמיד מינימלי איפה שצריך. קצת כמו לסדר כל יום את הבית מאשר פעם בשבועיים לעשות סידור מסיבי שמשתק את יושבי הבית מפעילות לכמה שעות.
רעיון שלא תמיד קל ליישום אבל עוזר להבהיר את האינטרס המשותף הוא להשתמש במטאפורה שעומדת מאחורי הביטוי “חוב טכני” ולהבהיר את המשמעות של הריבית המשולמת. אם יש לי פיצ’ר שגורם לבאגים אצל לקוחות ברמה של יומיים בחודש, אז הריבית הקבועה המשולמת היא יומיים שניתנים לחיסכון. אם יש לי פיצ’ר שהערכת הפיתוח שלו יכלה להיות 5 ימים אבל בגלל מורכבות הקוד לוקחת לי 7 ימים, אז הריבית היא יומיים. נכון, נכון, אם זה היה כזה פשוט כולנו היינו מסתובבים עם מחשבון, אבל החשיבה מוכוונת הכימות תאפשר הרבה פעמים הגעה לחישוב מקורב או שעוזר להבהיר משמעות. לדוגמא עבדתי במקום עם אזור קוד מאוד מורכב שממש ידענו שעולה בסדר גודל של שבוע תחזוקת באגים (ולקוחות עצבניים עם תקלה חמורה!) על כל חודש עבודה.
בסוף, שינוי שיטת החשיבה יכולה להביא לכך שהחוב הטכני נמנע ככל האפשר ואפשר למקד את הזמן בחובות הטכניים המצטברים שנובעים מהתפתחות המוצר. ברור לכולנו שהתנהלות כזו היא אידילית ולכן אנחנו כל הזמן צריכים לאזן בין עמידה באיכות/ מניעת חוב טכני לבין קצב הדילוור.
פתרונות ברמת הקצאת הזמן
ראשית כל, בואו נזכור כולנו שתמיד יש משהו דחוף יותר לעשות ולכן צריך להשקיע את הזמן בצורה ברורה.
שנית, מבחינת משך הזמן הדרוש, לפי מרטי קאגאן במאמר הזה וכך גם מקובל במקומות רבים נוספים היא שמדברים על פניות של 20% כמינימום. ושמקומות שכבר אגרו הרבה חוב טכני זה צריך לעמוד על 30 ו-40 אחוז.
1 מכל 4 יוזר סטורי/ דברים שמפתחים הוא חוב טכני: כלומר 1 לכל 4 “דברים” ברשימה יהיו חוב טכני. זה דורש שכל ה”דברים ” יהיו באותו סדר גודל של משך זמן, נניח כל “דבר” נמשך 3 ימים, כי אחרת זה לא מגיע לאזור ה-20-30 אחוז
יום בשבוע שמוקדש לחוב טכני: כל יום חמישי כל הצוות עובד רק על פתרון חובות טכניים. צריך לוודא שאין דברים שאוכלים את הזמן המוקדש לזה ומוציא את הפואנטה ליום. וגם לפעמים זה קשה לעשות סוויצ’ במעבר מפיצ’ר בעבודה לעבודה על חוב טכני ולפעמים גם מורכב מבחינת אינטגרציית קוד.
משרת מפתח אחת בספירנט: הרעיון הוא שיש מישהו שמקדיש את כל הספרינט שלו לחובות טכניים. בצוות של 5 אנשים זה מביא לאזור ה-20%, בצוותים גדולים יותר או קטנים יותר צריך לחשב בהתאמה. במקרה זה צריך לקחת בחשבון שזה יהיה כמובן כל פעם מישהו אחר ושלא תהיה היתדרדרות ברמת כתיבת הקוד “כי כבר יש מי שיבוא לנקות”. כמו כן, צריך לוודא שאותו סטנדרט עבודה נשמר בפי’צרים חדשים כמו בחובות טכניים לדוגמא כמה אנשים בודקים את הקוד לפני שנכנס לסביבה, איך מגדירים אותו וכו’.
20-30% מכל משימה היא חוב טכני: הרעיון הוא לקחת את קטע הקוד שבו ניגע בפיצ’ר הבא ולראות מהם השינויים הקטנים שאפשר לעשות שיהפכו אותו מצד אחד לפשוט יותר ומצד שני לא יעלו המון המון זמן. שיטה כזו מאפשרת להבטיח מצד אחד שיפור מתמיד באזורי קוד שעובדים עליהם הרבה ומצד שני לא זמן ארוך מדי. בעיני החיסרון של השיטה הזו היא שלפעמים זה מביא לחוסר תכנון מראש למצב הרצוי העתידי של קטע הקוד. אלא רק שינויים קטנים ספונטניים.
לא במקום השיטות הקודמות… גם קצת מי שבא לו: בעוד שהיחס הבסיסי שלנו לחובות טכניים הוא לא חיובי, הרי שבסוף יש פה הזדמנויות לתקן אזורים שההתמודדות איתם מרגיזה וממש דורשת כבר “לסדר שם קצת את הקוד”. ולכן הקצאה חצי ספונטנית שבה כל איש צוות לוקח כמה חובות טכניים שבוערים לו בלב יכול להוות פיתרון חלקי נהדר.
מדדים ככלי מלווה איכות
בתור מי שנושא המדדים חביב עליה (ראה פוסט: מדדים ויעדים והנה מדדים ויעדים בעולם הפיתוח), אני מאמינה שמדדים הם כלי מלווה מעולה שמאפשר לנו לבדוק באופן שוטף את איכות הקוד, למדוד את הפתרונות של החובות הטכניים ולעזור למנוע מהם להצטבר.
דבר חשוב הנוגע למדדים עולה ממה שאמר אחד האנשים החביבים עליי, אליהו גולדרט: “TELL ME HOW YOU MEASURE ME, AND I WILL TELL YOU HOW I WILL BEHAVE” כלומר כל מדד שתבחרו, צריך לשים לב להתנהגות הנוצרת על מנת למנוע התנהגות לא רצויה אחרת. דוגמא מעניינת שקרתה בארגון שעבדתי בו- שאפנו להוריד לאפס את הבאגים הקריטיים והחמורים, אז באורח פלא הכמות שלהם צנחה אבל כמות הבאגים המינוריים עלתה מאוד (ואז דייקנו את ההגדרות והתחלנו למדוד את כל הסוגים..).
זה נכון שכל אחד מהמדדים עושה עבודה חלקית, אבל אנחנו צריכים לזכור שצריך להתחיל מאיפשהו.
הנה מספר מדדים שרובם מבוססים על כלים שמודדים באופן אוטומטי:
- Cyclomatic complexity: מנתח את סיבוכיות הקוד על ידי חישוב מספר הדרכים האפשריות בקוד יחסית למספר שורות הקוד הכלליות.
- Code Coverage / אחוז כיסוי של Unit Test-ים: יש כלים שמנתחים איזה אחוז מהקוד הוא תחת יוניט טסטים.
- SQALE: מנתח את איכות הקוד על בסיס חוקים פנימיים, כשהסקלה של הציון הוא A ועד E
- מספר שבירות החוקים: מספר החוקים שנשברים בהינתן סטנדרט מסוים של כתיבת קוד. בדרך כלל מקוטלגים מקריטי ועד מינורי. יעני אתה מגדיר את הסטדנטרט ואז הוא מנתח לך עד כמה אתה עומד בו.
- מחיר העיכוב: מחושב ידנית. כמה זמן בוזבז בגלל שהקוד לא תוקן בגלל באגים, או כניסה נוספת להבנת הקוד או התמודדות עם הקוד כמו שהוא.
יש הרבה כלים בשוק, ספציפית קראתי אך לא התנסיתי על NDepend : פלאגין ל- VISUAL STUDIO, שעושה את המדידה של SQALE וגם כמה חוב טכני צברנו עד כה (הוא טוען גם שהוא יודע להעריך באופן גס את משך זמן התיקון..) וגם יודע לסמן מפת חום של אזורים שיותר כדאי לעשות להם ריפקטורינג.
לסיכום, אמנם חוב טכני הוא בלתי נמנע לחלוטין, אך ניתן לצמצום ושליטה. ואם נכניס אותו לאורח החיים שלנו כחלק שוטף לכל דבר מבחינת ההתייחסות, המדידה, וניהול הזמן שלו, נוכל לקדם אותו בצורה אפקטיבית יותר.
האם גם אתם אנשי אופרציה העוסקים בתהליכי עבודה, מתודולוגיות וכלים בעולמות הפיתוח? אם כן, נשמח שתצטרפו לקבוצת Engineering Operations בוואטסאפ ותעקבו אחרינו בעמוד ה- Linked In שלנו.