בואו נדבר על הבעיה של פיצ'רים מעלי עובש (או feature decay בלעז). איך הבעיה הזו באה לידי ביטוי? בכך שיש פיצ'רים שנתקעים מתישהו בתהליך הפיתוח או היציאה לשוק, מתחילים להעלות עובש, ולגרום לבעיות. זה מפתה לחשוב שהבעיה הזו מתרחשת רק בפיצ'רים שאנו משאירים בתחתית ה-backlog. ואכן זה אחד מהמקומות שבהם הבעיה הזו הכי נפוצה. אבל האמת היא שהעובש גדל בכל מקום: בפינות טחובות של הספרינטים שלנו, במרתף של סביבת הייצור מתחת ל-feature flags ובסביבת הייצור עצמה אם אנחנו לא מנטרים אותה. בואו נסתכל איך הבעיה הזו נראית בתחנות המרכזיות של מחזור חיי הפיתוח. ומה הסכנות שמהן אנחנו צריכים להישמר.
עובש ב-backlog שלנו
הבדיחה הידועה אומרת שמנהלי מוצר לא מסרבים לפיצ'רים שהם לא רוצים ליישם, הם פשוט קוברים אותם ב-Backlog. מעבר לבדיחה חשוב לזכור שגם הפיצ'רים שאנחנו כן רוצים ליישם לא נשארים רלוונטיים לנצח. פיצ'ר שמבלה חודשים ב-Backlog יכול בקלות לאבד את הרלוונטיות שלו. לי זה קרה עם אינטגרציות למערכות שהיו נפוצות יותר כשהפיצ'ר תועדף אבל כבר לא היו מאוד רלוונטיים אצל חלק מהלקוחות כשהאינטגרציה יצאה לשוק. ביצוע Backlog Grooming באופן מסודר יכול לעזור לנו להימנע מלהשקיע זמן ומאמץ בפ'יצרים שכבר העלו עובש.
זבל על רצפת המפעל
בעבודה על פי מניפסט ה-agile אנחנו רוצים לשחרר תוכנה עובדת כמה שיותר מהר. ברוב המתודולוגיות זה אומר שספרינט מסתיים עם גרסה עובדת. אבל המציאות עובדת אחרת. לפעמים נופל עלינו בלת"מ או שאחד מהפיצרים סתם לא נגמר בזמן הספרינט. מה עושים? לרוב אנחנו דוחים את הפיצ'ר לספרינט הבא. אבל ככל שאנחנו נדחה את ההכנסה של פיצ'ר לתוך המערכת הסיכוי לקונפליקטים מול הקוד המתקדם הולך וגדל. זה אומר במקרה הטוב קצת יותר עבודה לצוות הפיתוח ובמקרה הרע כתיבה מחדש של הפיצ'ר או המערכת בכדי לאפשר לנו בסופו של דבר לקדם את הפיצ'ר. לא בטוחים למה אני מתכוון? תשאלו את צוות הפיתוח שלכם "מה סיפור ה-merge conflict הכי גרוע שלכם?". לא בטוח שתצליחו לישון אחר כך.
פיצ'רים לא פעילים בסביבת הייצור
לא אשקר, העובדה ש-feature flags הם סטנדרט בימינו עושה אותי מאושר מדי יום ביומו. אני נרדם יותר בקלות כשאני יודע שאם יש בעיה עם איזה פיצ'ר אז אני יכול לכבות אותו ולא חייב לעשות rollback לגרסה קודמת כמו לפני עשר שנים. לפעמים אנחנו משתמשים בדגלים הללו באופן אחר, למשל משחררים פיצ'ר כבוי מתוך כוונה להפעיל אותו בזמן מאוחר יותר. למשל אחרי שיש מספיק הורדות של הגרסה החדשה או בתאריך ספציפי כחלק מקמפיין פרסומי. הבעיה היא שהפונקציונליות של פיצ'רים שמבלים את ימיהם במגירת הדגלים המכובים לא באה לידי ביטוי. כלומר, זה כל הרעיון של לשים דגל מכובה, אבל בזמן הזה שאר המוצר כן ממשיך להשתנות ופיצ'רים אחרים ממשיכים לצאת. בזמן הזה בעיות והתנגשויות פוטנציאליות לא מתגלות. עד מתי? עד הרגע שאנחנו מפעילים את הפיצ'ר. וככל שיותר זמן עובר אז הפוטנציאל לבעיות עולה גם.
בסביבת הייצור עצמה
פיצ'רים לא נשארים מועילים לנצח. כולנו נתקלנו בתפריטים עם פריטים מיותרים שמקשים עלינו למצוא את מה שאנחנו מחפשים או מסכים עם שדות מיותרים שמעכבים אותנו להגיע למטרה שלנו. זו הסיבה שחשוב להמשיך לעקוב אחרי המדדים שלנו ולראות אם ישנם כפתורים שאף פעם לא לוחצים עליהם, אפשרויות שלא נבחרות, או תתי מערכות שלעולם לא פועלות.
לסיכום, מה אנחנו יכולים לעשות?
כנראה שהסוד הוא לעבוד בצורה מסודרת. להשגיח שהגיל של פריטים ב-Backlog לא עולה על סף מסוים, לשים לב שאין לנו פיתוחים ששוברים גבולות ספרינטים באופן עקבי, לנהל רישום של כל הפיצ'רים הכבויים שלנו. וכמובן לבצע את המטלה הקדושה שלנו: לוודא באמצעות המדדים שלנו שאין לנו כל מיני שאריות היסטוריות מעלות עובש שמכבידות עלינו.
