אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק ראשון

אחד הגורמים שמשפיעים על הצלחתם של פרויקטים בכלל, ופרויקט תוכנה בפרט הוא ההחזר על ההשקעה (ROI – Return on investment), סקראם (Scrum) מתייחס בכובד ראש לעניין זה ולכן טוען שעל רשימת הדרישות להיות מסודרת בצורה כזו, שבראש הרשימה נמצאים האלמנטים בעלי הערך הגדול ביותר. כמובן שיש יוצאי דופן כגון פריטים שמהווים בסיס לפיתוחם של אחרים, אבל באופן כללי אנו שואפים למזער תלויות. בהינתן שהפריטים ברשימה מסודרים “נכון”, ואנו מפתחים את התוכנה לפי הסדר של הפריטים ב-backlog, אנו למעשה מגדילים משמעותית את הסיכוי להצלחתו של הפרויקט מבחינת ה-ROI.

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

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

אציג כעת מספר טכניקות מקובלות למיון פריטים ברשימת הדרישות, אציג אותן ברמה הבסיסית בלבד וכל מי שיבחר להשתמש באחת מהן יאלץ ללמוד אותה יותר לעומק, בכל מקרה אני רוצה לציין שהטכניקות אינן “תורה מסיני”, המודלים שאציג אמורים לשמש ככלי מסייע שמספק יותר מידע לגבי הפריטים ברשימה, בכל אחד מהם יש מקום רב להפעלת שיקול דעת, והוא אינו מודל אוטומטי שמנטרל מחשבה והגיון בריא (אם הוא היה כזה הוא לא היה מתאים ל-Agile):

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

clip_image004מרגש –Exciter – אלה הם מאפיינים של מוצר שהלקוח אפילו לא ידע שהוא רוצה עד שהוא ראה אותם, דוגמא למאפיין כזה הוא למשל שלט שפותח את דלתות המכונית, וכן, בד”כ מאפיינים מסוג זה לא נשארים כאלה לאורך זמן.
חובה–
Mandatory– מאפיינים שבלעדיהם אין זכות קיום למוצר, דוגמא למאפיין כזה היא למשל האפשרות לשמור קבצים במעבד תמלילים.
לינארי – Linear – ניתן לאפיין את הסוג הזה בעזרת המשפט “כל המרבה, הרי זה משובח”, ככל שיש יותר כאלה, כך שביעות הרצון של הלקוח עולה. דוגמא למאפיין כזה היא למשל כמות הזיכרונות במכשיר סלולארי.
מפוקפק – Questionable – כזה שלא מספיק ברור לגביו מה הסיווג.
הפוך – Reverse – כזה שברור שהלקוח לא רוצה.
משהו – Indifferent – משהו שלא משנה ולא במעט את שביעות הרצון של הלקוח.

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

לתשובות לשאלות, קאנו מציע פורמט טקסטואלי לתשובות, וטבלה שעבור כל זוג תשובות, מספקת סיווג (האות בטבלה מסומנת באדום בהגדרת הסיווג שמעל):
– מאוד מוצא חן בעיני.
Kano table– אני מצפה לכך.
– אני ניטרלי.
– לא מאוד מפריע לי.
– מפריע לי.
אז מה עושים אחרי שסיווגנו ? אין המלצה חד משמעית, ברור שכל מה שסווג כ-M חייב להיות במוצר, גם ברור שיש צורך בלפחות חלק מה-L, וכדאי מאוד שגם תשאירו מקום ל-E. בשלב הזה לצערי תאלצו להפעיל את הראש קצת מעבר למודל, כאן נכנסים שיקולים נוספים כגון יעדי הפרויקט, מצב השוק וכדומה.
המודל של קאנו מספק לכם יותר מידע לגבי הפריטים, ואולי גם חלוקה גסה, אבל הוא לא מספק פתרון מלא ומשאיר מקום לשיקול דעת ומחשבה, וטוב שכך.

עוד מודלים בפוסט הבא.

Comments are closed.