תוכן עניינים:
הערכת פרויקט תוכנה
פיקסביה
מבוא
ההערכה פשוט קשה. למרבה הצער, זה גם מאוד הכרחי. חברות משתמשות באומדנים כדי להקרין לוחות זמנים לשחרור, להתחייב ללקוחותיהן, להחליט אם שווה ליישם תכונה מוצעת, לעקוב אחר מהירות הצוותים ולתעדף את העבודה בצורה יעילה. מנהלים רוצים לרוב לדעת מתי תכונה או אספקה תהיה מוכנה להפקה. אחרי הכל, פיתוח תוכנה אינו השקעה של מה בכך. ללא הערכות, כיצד ינהל מנהל הפרויקט הערכה? אם בני אדם היו יכולים לחזות את העתיד בצורה מדויקת, אנשים לא היו מנצחים במרוצי סוסים 2% מהמקרים. הערכה היא החידה הגדולה. זה הכרחי וחיוני שחברות יבקשו מאנשיהם לעשות את הבלתי אפשרי: לחזות את העתיד.
ראשית, בואו נסקור כמה שיטות הערכה פופולריות (למקרה שהתגעגעתם לריגוש). אז נוכל לבדוק מה זה אומר לנו ולפרויקטים שלנו.
מודל מגדת העתידות
מודל זה כמעט ואינו דורש מאמץ להפקת אומדן. אומדנים חושבים מעט מה צריך לעשות כדי ליישם ולבדוק תכונה, ואז הם זורקים מספר. זה נשמע הרבה כמו "… (הפסקה ארוכה)… אממממ… 6 שבועות." ואז כולם מהנהנים ואנחנו ממשיכים הלאה. הם יכלו לבלות זמן מה בחזית לדבר על מה שהם יודעים על הדרישות (שכנראה לא התמונה המלאה). ניתוח זהיר זה גורם להערכתם להרגיש אמינה יותר. בסוף הפרויקט תמיד יש רציונל מקובל מדוע ההערכה הייתה כה רחוקה מהמציאות. תמיד יש נסיבות בלתי צפויות שיכולות לשמש שעיר לעזאזל. לרוב לא עולה בדעתו של מישהו שהמודל לוקה בחסר קשה.
אז איך נוכל לשפר את התהליך הזה? אני יודע! אנו יכולים להשתמש בטכניקת הפירוק (כלומר לחלק ולכבוש). גישה זו מניחה שאתה יודע את ההיקף המלא של התכונה או הפרויקט בממשק הקצה. כל תכונה מחולקת לנתחים בגודל ביס. כל נתח מוערך (סגנון מגדת עתידות), ואז אנו מוסיפים אותם כדי לקבל אומדן תכונה / פרויקט כולל. זו בהחלט גישה מסובכת יותר, אך היא נראית טובה יותר משתי סיבות:
- נתחי עבודה קטנים יותר נוטים להיות קלים יותר לאומדן.
- אמנם יש עדיין אפשרות לטעות (+/- סכום כלשהו), אך ההנחה היא כי השגיאות יבטלו זה את זה כאשר תוסיפו הכל ותקבלו הערכה כוללת אמינה יותר.
הפגם הבסיסי בגישה זו הוא שתורמים בודדים (האנשים שעושים את העבודה) מעריכים באופן אוניברסלי. הם עדיין טובים משמעותית מאלו שמעליהם ומסביבם, אבל זה לא רף גבוה. זה לא נראה כמו המקרה מכיוון שכולנו ראינו מקרים שבהם מפתחים הפתיעו את עצמם בכך שהם השיגו משהו לפני המועד. אבל זו נקודת נתונים אחת, לא מגמה. אנשים באמת מנצחים מדי פעם בקזינו; להוציא כסף בקזינו כל יום במשך שנה ויהיה לך פחות כסף ממה שהתחלת איתו. אם אתה עוקב אחר הערכות לעומת מציאות לשנה-שנתיים, תגלה שההערכות אינן נופלות מהמציאות. בעוד אנשי עסקים רבים בטוחים לחלוטין שמפתחים מרפדים בעצלתיים את הערכותיהם ומשתמשים בתוספת הזמן ל"צלחת זהב "או לבדוק את מניותיהם,הנתונים מראים אחרת. אסטרטגיית "ביטול" לא עובדת.
אז מה עכשיו? בואו נעלה את מודל מגדת העתידות ונעבור לגישה המבוססת על גודל. מתברר שבעוד שבני אדם די נוראיים בהערכת זמן ההשלמה, אנחנו דווקא די טובים בלומר כמה גדול משהו. אנו טובים במיוחד בגודל השוואתי ("זה גדול מזה, אבל קטן מזה שם"). אם אנו חושבים במונחים של גודל או מורכבות ולא זמן, מוחנו מעבד זאת בצורה אמינה יותר. אז נוכל לקחת את ערכי הגודל ולחשב את מספר השעות האמיתי של הפרויקט על בסיס נוסחת קסם ערמומית! ואז נכנס למקום מודל נקודות הפונקציה הפופולרי (שלב משמאל).
ניתוח נקודות פונקציה (FPA)
לצורך ניתוח נקודות פונקציה, עלינו לזהות חמישה סוגים של דברים ביישום שלנו: תשומות חיצוניות, יציאות חיצוניות, שאילתות חיצוניות, קבצי ממשק חיצוניים וקבצים לוגיים פנימיים (אל תדאג יותר מדי מהגדרות; תוכל לחקור אותן בהמשך). לכל דוגמה לאלה (פונקציה) יש מורכבות המשויכת אליה (נמוכה, ממוצעת או גבוהה). אנו משתמשים בטבלה שלהלן כדי להבין כמה נקודות מקצות כל פונקציה.
כעת אם נסביר את הנקודות עבור כל הפונקציות שלנו אנו עשויים לקבל מספר כמו 457 נקודות פונקציה עבור הפרויקט שלנו. אז אנחנו רק צריכים נוסחה כדי להבין את מספר השעות… בהתבסס על הפרויקט האחרון שלנו, "קצב המסירה" שלנו היה 15 נקודות תפקוד לאדם לחודש. זה עבודה של בערך 30 חודשים, וזה אמור לקחת קצת יותר מחודשיים וחצי עבור הצוות שלי בן 12. טא-דה!
זה בהחלט מורכב יותר מהמודל הקודם שלנו. למעשה, יש לזהות ארבעה תחומי מפתח מורכבים.
- חמשת סוגי הרכיבים אינם בהכרח אינטואיטיביים, וקל לשכוח להכניס משהו לרשימה או להקצות אותו לדלי הלא נכון.
- הטבלה המשמשת להפקת נקודות הפונקציה מכילה מספרים קסומים שידרשו מאמצים רבים לאימות. האם המספרים הללו מכוילים כראוי כדי ליצור הערכות אמינות עבור הצוותים שלי?
- קצב המסירה (פיסת חידה קריטית) מחושב על פי התפוקה של הצוות שלך. באיזו תדירות עלינו לחשב מספר חדש? למעשה יש מעט מאוד הנחיות בנושא.
- מהו מורכבות נמוכה, ממוצעת או גבוהה? איך נגדיר זאת כך שכולם יבינו זאת? האם זה לא נכון לקריטי לדיוק החישובים שלנו?
יש כמה חלקים נעים בדוגמה פשוטה מאוד זו, ואפילו לא דנו במודלים מורכבים מורכבים יותר ובנתונים האחרים שיכולים להיכנס לתמונה (למשל שיעור עלות, קצב תמיכה, צפיפות פגמים וכו '). חלקים נעים יותר פירושם הזדמנויות רבות יותר להתרחשות טעויות. האם אנו עושים הערכה מסובכת מדי כעת? אנחנו לא משלמים למפתחים להקדיש זמן רב להערכה. אני לא יכול למכור הערכה ללקוחות שלי. אני צריך תוכנת עבודה. האם יש עוד משהו שם בחוץ?
הולך זריז
עכשיו בואו נסתכל בקצרה על סקרום זריז (בדיוק מספיק כדי לעשות השוואה). כפי שצוין קודם לכן, בני אדם הם נוראיים בהערכת זמן, והם די טובים במידות השוואה. להלן כמה מונחים שיש להבין:
- ספרינט - פרק זמן מוגדר בזמן (בדרך כלל שבועיים).
- סיפור משתמש - חתיכת עבודה נפרדת, רצוי שהיא קטנה מספיק בכדי לבצע אותה אדם אחד בספרינט. זה הדבר שאנחנו מעריכים.
האסטרטגיה הפופולרית ביותר היא שימוש ברצף פיבונאצי (0, 1, 2, 3, 5, 8, 13) לצורך הערכות. זה לא לינארי - ככל שעולים בסולם גודל הפערים גדל. המפתח הוא שהפערים יהיו רחבים מספיק, כך שאין שום סיבה להתווכח על הבדלים לא משמעותיים. ברגע שמגיעים מעל 3, ההבדל בין 4 ל- 5 או 7 ו- 8 הוא כל כך זניח, עד שאין טעם להקדיש זמן לביצוע איזו מהן. רצף בסיס -2 יעבוד גם הוא (0, 1, 2, 4, 8, 16 וכו ').
"אבל רגע, זה רק מספר. מה זה אומר? כמה שעות זו נקודה? " נקודות לא נועדו להתאים ישירות לשעות, כי אם היו עושים קבוצות יתפתו לחזור להעריך בשעות ואז להמיר את זה לנקודות איכשהו. כפי שנדון קודם, דיוק ההערכות שלנו נובע מגודל השוואתי ולא מאומדן מספר השעות שייקח משהו. אם אתה נותן לצוות את היכולת לחשוב במונחים של שעות, אתה מתפשר על היכולת שלך לאמוד במדויק.
נניח שהתחלת בתרגיל כיול. משוך את הצוות שלך לחדר ועבר עליהם ברשימה של 10-12 סיפורי משתמשים. בחר אחד קטן אך לא קטן ועשה זאת קודם. סקור אותו והודיע שהסיפור הזה הוא "3". אתה לא שואל. אתה אומר. ואז עברו לסיפור הבא. "אם זה היה 3, מה זה?" כעת הצוות מגדיר גודל סיפורים יחסית לסיפורים אחרים. בסופו של דבר יהיה להם מושג די טוב מה מהווה "1", "2" וכו '. הם לא מעריכים. הזמן לא משנה. הם מגדלים סיפורים, יחסית לסיפורים אחרים שכבר יש להם מספר. לאחר מכן תוכל להכניס סיפורי דוגמה לכל מספר ברצף במסמך שנקרא סרגל. הם יכולים להשתמש בזה כהפניה אם הם לא בטוחים מה זה "5".
עכשיו הנה המפתח. רוטב הקסמים שגורם לעבודה זו הוא "מהירות" (מספר הנקודות שקבוצה יכולה להשלים בספרינט בממוצע על פני 3-4 ספרינטים). בואו נגיד שהספרינט שלכם הוא שבועיים והקבוצה שלכם המונה 8 אנשים יש מהירות ממוצעת של 35 נקודות. אתה מקבל 35 נקודות ב 640 שעות עבודה (8 x 80 שעות). אם אנו מגלים שתכונה תעבור לסיום של 100 נקודות בערך, אני יודע שזה בערך 6 שבועות של עבודה ו ~ 1900 שעות. הצוות משתפר מאוד בגודל הסיפורים באופן עקבי, ואתה ממנף זאת לתכנון הפרויקט שלך. חישוב זה פועל מכיוון שהמשך הוא ספרינט לספרינט.
כדי לבצע תכנון ארוך טווח ברמה גבוהה, אתה יכול לבקש מההובלות שלך לפרק תכונות ברמה גבוהה לסיפורי ביניים חד-שנתיים ולשים עליהם ערכי נקודה. תהיה מידה של דיוק אבוד, אבל אתה ממנף את המודל שהם כבר מבינים. נתיב מדויק יותר יהיה גודל יחסית ברמת התכונות. "תכונה זו גדולה מאותה תכונה של 40 נקודות, קטנה יותר מאותה תכונה של 120 נקודות שם, ומעט גדולה יותר מהתכונה של 65 נקודות שעשינו זה עתה." סיפורים מקובצים ל"אפוסים ". אם כל תכונה היא אפוס, בסוף תדע כמה נקודות נדרשו כדי להשלים את התכונה הזו. שמור היסטוריה של זה ותוכל להשתמש בה לצורך תכנון השחרור שלך.
סיכום
יש הרבה מתודולוגיות בשימוש כיום. לכל אחד יש יתרונות וחסרונות. איכשהו עלינו להבין כיצד למקסם את דיוק ההערכות שלנו כדי שנוכל לקבל החלטות טובות. זה לא אומר שההערכות שלנו צריכות להיות מדויקות. הם רק צריכים להיות מדויקים מספיק כדי שהם יהיו שימושיים. אם אינך מבין הערכה, אתה יכול להניח שההערכות לא היו מדויקות מכיוון שהצוות לא עשה עבודה טובה. הם לא העריכו נכון, או שלא ביצעו נכון את הפרויקט. מכות יימשכו עד שההערכות ישתפרו. אולם אין להשתמש בהערכות כהתחייבות. זה ניחוש טוב ביותר על סמך המידע המוגבל שיש לנו כיום. כאשר מידע חדש צץ, עלינו לאפשר לחזור לאומדנים. כל דבר אחר מצפה לבלתי אפשרי, וזו בעיה במנהיגות (לא בקבוצה).
הגישה של Scrum פשוטה בהרבה ממה שאנחנו רואים בניתוח נקודות פונקציה. ואני אומר שזה הרבה יותר אמין משולחנות קסם עם מספרים קסומים. זה מקבל את המפץ הגדול ביותר עבור הכסף (מאמץ מינימלי עם דיוק גבוה יחסית). מנקודת מבט של מאמץ, זה לא יוצר תהליך משקל כבד עבור הצוותים להבין ולהשתמש בהם. פיסת ההערכה של זריז יכולה לקרות מהר מאוד ברגע שכולם מבינים את פרטי העבודה המוערכת. זה בהחלט טוב יותר מאשר לשלוף מספרים מהאוויר. מינוף מהירות עושה משהו חשוב מאוד: הוא מכניס נתונים היסטוריים לחישוב. בכל ספרינט אתה מחשב מחדש את המהירות שלך. זה קריטי, כי עם הזמן התפוקה משתנה. צוותים המשתמשים ב- FPA עשויים להפיק את שיעור המסירה שלהם מהפרויקט הקודם שלהם,שבמקרים מסוימים היה לפני מספר חודשים. הרבה מאוד כנראה השתנה מאז. ההצעה שלי היא שתחקור את Agile ובאמת יתאמץ בהבנת נקודות סיפור ומהירות. אל תחזור על הערכת שעות רק בגלל שזה מה שאתה מבין. אני מאמין שתודה לעצמך אחר כך.