שלום,

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

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

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

אני מכירה חברה שמשתמשת בתמחור בשעות ולא בתמחור בנקודות.

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

 

יוכבד

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

 

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

יוכבד שלום,

 

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

כלומר, אם בממוצע אנו מספיקים בספרינט 10 נקודות, וכלל התכולה שאנו מעוניינים לספק שווה 100 נקודות אז ניתן להסיק שע"פ מה שאנו יודעים בנקודת הזמן הזו, שייקח לנו 10 ספרינטים לסיים את התכולה, וזה כמובן בהנחה שבסוף כל ספרינט יש לנו מוצר שניתן פוטנציאלית לשלוח ללקוח.

 

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

 

אם את רוצה את יכולה לקרוא עוד בנושא במאמרים בבלוג שלי:

נצחון בנקודות

פוקר תכנון - Planning poker

 

ויש כמובן גם את הספר של מייק קון - Agile Estimation and Planning - Mike Cohn.

 

אלעד.

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

בנוסף זמן יוצר רושם "מדעי" שגורם לתסכול אצל אנשים שאינם אנשי תוכנה כאשר הוא לא מדוייק (והוא לא)

 

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

 

ארנון

תודה לכל העונים. זה בהחלט עזר לי להבין קצת יותר לעומק את נושא הערכת המשימות.

יוכבד

אצלנו יש שילוב - אנחנו משתמשים בשעות, אבל יום עבודה מוגדר כ-8 שעות (מקל על משימות שהן חצי או רבע יום). כמו כן, ספרינט הוא לא בדיוק 8 X מס מפתחים X ימים, אלא מורידים אחוז מסויים עבור תמיכה בלקוחות, יעילות, הפרעות לא מתוכננות (שהניסיון מראה שתמיד קורות) וכן הלאה. לאחר כמעט 3 שנים של עבודה עם SCRUM אנחנו דיי מדייקים.