פיתוח מונחה בדיקות לעומת ערך עסקי

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

הגישה שלנו דומה לגישה שננקטת בפגישת תכנון ספרינט (Sprint Planning Meeting). בפגישה זו, בעל המוצר והצוות מנהלים משא ומתן על מבחר המשימות (סיפורי המשתמש) שכל צוות ייאלץ להתמודד מולן במהלך הספרינט. לא מספיק לאמוד את המאמץ, אלא יש להשתמש בערך העסקי כווקטור הראשי בהערכת היעדים של הספרינטים. בעלי המוצר והמפתחים יוצרים יחד תרשים לכל סיפור משתמש מוצע. בתרשים זה, בעל המוצר משתמש בציר ה-y כדי לציין את הערך העסקי והמפתחים משתמשים בציר ה-x כדי להעריך את מאמץ הביצוע. לאחר מכן, המשימות ממוינות לתוך אחת מארבע קטגוריות, כפי שמוצג בתרשים למטה:

אויסטר (Oyster) – מספקת ערך עסקי גבוה עבור השקעת פיתוח גבוהה – 80% ערך ב-80% השקעה. מיושמת ב-4% מהמשימות.

פנינה (Pearl) – מספקת ערך גבוה עבור השקעת פיתוח נמוכה – 64% ערך ב-4% השקעה. מיושמת ב-16% מהמשימות.

פיל לבן (White Elephant) – הערך בה נמוך, עבור השקעת פיתוח גבוהה – 4% ערך ב-64% השקעה.

ניצחונות מהירים (Quick Wins) – קטגוריה בה הערך נמוך, אבל גם השקעת הפיתוח נמוכה.

הרעיון הוא למצוא תערובת של סיפורים שמגדילים את הערך העסקי כאשר הם מיושמים יחד וכפופים לאילוצי זמן ומשאבים.

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

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

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

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