עמוד בלוחות הזמנים שלך: שיטות שמפתחים משתמשים בהן כדי להעריך את המאמץ

שלום לכולם! יש כמות עצומה של תיאוריות שאתה צריך לדעת כדי להתחיל בפיתוח תוכנה. מומחים מסוימים (לדוגמה, מפתחי backend שמשתמשים ב-Java ושפות אחרות) יודעים יותר מזה, בעוד שאחרים (לדוגמה, מפתחי חזית שמשתמשים ב-JavaScript וב-React Native) עשויים לדעת קצת פחות. עם זאת, שתי הקבוצות חייבות להחזיק בגוף גדול של ידע לא רק טכני, אלא גם "ארגוני". הידע ה"ארגוני" הזה הוא תחום חפיפה אחד עבור מפתחי Frontend ו-backend. היום אני רוצה לדבר על היבט של הידע הלא טכני, הארגוני הזה. היום נדבר על הערכת מאמץ . מכיוון שיש לי ניסיון רק בשימוש במתודולוגיה Agile (שנחשבת לפופולרית ביותר), ליתר דיוק במסגרת Scrum, אשקול הערכת מאמץ בהקשר של Scrum . כבר בהתחלה, אני חייב לומר שהערכת מאמץ היא קשה. עבורי, זה אחד ההיבטים המאתגרים/לא נעימים בעבודה שלי כמפתחת. ישנם גורמים רבים ושונים שיש לקחת בחשבון שיכולים להשפיע על ההערכה שלך לגבי המאמץ הנדרש למשימה. בנוסף, תוכניות פיתוח עתידיות יתבססו על ההערכות שלך.

מה אם תספק הערכה גרועה?

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

איך עושים הערכת זמן

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

מהן נקודות סיפור?

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

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

איך לא להשתמש בנקודות סיפור

למרבה הצער, לעתים קרובות נעשה שימוש לרעה בנקודות סיפור. נקודות סיפור עלולות להיות מטעות כאשר הן משמשות להערכת אנשים, להגדיר מועדים ומשאבים מפורטים, וכאשר הן נחשבות בטעות כמדד ביצועים. במקום זאת, הצוותים צריכים להשתמש בהם כדי להבין את ההיקף/מורכבות של כל משימה וכדי לקבוע סדרי עדיפויות. אולי צריך להתמודד תחילה עם החלקים הנחשבים לקשים יותר, כדי שיוכלו להיעשות לפני סוף הספרינט , ואולי להעביר משימות קלות יותר לאחר מכן. הרשו לי להזכיר לכם מהו ספרינט בהקשר של מתודולוגיית Scrum : משך פרק הזמן הזה נקבע עם תחילת הפיתוח ומוסכם בין הצוות ללקוח. זו יכולה להיות תקופה של שבועיים או חודש, או כל תקופה אחרת. ככלל, הערכות המאמץ נעשות בתחילת כל ספרינט על מנת לתכנן את העבודה שניתן לסיים עד סוף הספרינט, כאשר העבודה שהושלמה נמסרת ללקוח. ההדגמה עוזרת לכם לראות את ההתקדמות שלכם בפיתוח המוצר, לקבל משוב מהלקוח ולהתאים את מסלול הפרויקט בהתאם לחזון הלקוח. אבל אנחנו מתרחקים קצת. נחזור להערכות. זה יהיה סובייקטיבי מדי שרק מפתח אחד יספק הערכות עבור כל המשימות. אז התהליך הזה הוא בדרך כלל מאמץ צוות. ישנן לא מעט טכניקות שצוותים יכולים להשתמש בהן כדי להפיק הערכות. היום נסתכל על הטכניקה הפופולרית ביותר: scrum poker . טכניקה זו דורשת מנהל אשר ישמש כמנחה עבור הסקרום פוקר . זה יכול להיות מישהו שהוא אמן Scrum או אולי ראש ממשלה .

מהו Scrum פוקר?

Scrum poker , או פוקר תכנון, היא טכניקת הערכה שמבוססת על הגעה להסכמה. הוא משמש בעיקר כדי להעריך את מורכבות העבודה שלפנינו או את הגודל היחסי של משימות פיתוח תוכנה. אני אגיד מיד שפוקר scrum הוא שיטת פיתוח תוכנה נפוצה, ואתה צריך לדעת על מה מדובר. זה בדרך כלל כולל אפליקציה או אתר כדי להקל על יצירה משותפת של צוות של אומדן עבור משימה מסוימת. איך זה קורה? הצוות לוקח משהו מהצבר (משימה חדשה, קצת פונקציונליות) ודן בקצרה במלכודות אפשריות ובניואנסים אחרים הקשורים אליו. לאחר מכן כל משתתף בוחר קלף עם מספר שמשקף את הערכת המורכבות שלו. אה, דבר נוסף, כשעורכים אומדנים אלה, אנו משתמשים במספרים ברצף פיבונאצ'י ולא במספרים רגילים. מספרי פיבונאצ'י פופולריים בפוקר סקרום , מכיוון שיש פער גדול יותר ויותר ביניהם (הדומה לרמות של פירמידה). חלק מהמשימות יהיו מורכבות ביותר, ולא נוכל להתחמק עם מספר קטן של נקודות סיפור. ישנם כמה כרטיסים יוצאי דופן בעלי המשמעויות הבאות:

מספר לא ידוע של נקודות קצה

משימה ארוכה עד אין קץ

צריך הפסקה

שיטות הערכה פחות נפוצות משתמשות:

• מידות חולצת טריקו - S, M, L, XL
• גזעי כלבים - צ'יוואווה, פאג, תחש, בולדוג וכן הלאה (באופן אישי, אני חושב שזו יחידת המידה המוזרה ביותר להערכת מאמץ =D)

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

דוגמה להערכת מאמץ

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

• מעולם לא יישמת פונקציונליות דומה לפני כן: +3
• הפונקציונליות היא בגודל ממוצע: +2
• היישום יהיה מורכב ביותר: +3
• כתיבת מבחנים עבור הפונקציונליות תהיה מורכבת ביותר: +3

הוספת כל רכיב, תקבל סך של 11 נקודות סיפור, אבל אין קלף כזה, אז אתה מציע 13. עמית לעבודה מציג את ההערכה הבאה עבור המשימה:

• הוא עבד עם משימה דומה בעבר: +1
• הפונקציונליות היא בגודל ממוצע: +2
• היישום יהיה במורכבות ממוצעת: +2
• כתיבת מבחנים לפונקציונליות תהיה במורכבות ממוצעת: +2

תוצאת הביניים שלו היא 7 נקודות סיפור, אבל המספר הזה לא קיים בסדרת פיבונאצ'י, אז הוא מגיש את הכרטיס עם המספר המשוער ביותר - 8. גם חברי צוות אחרים עושים את ההערכות שלהם על סמך השקפותיהם הסובייקטיביות. ואז כולם מראים את הקלפים שלהם ואתה מגלה שכמעט כל עמיתיך לעבודה נתנו הערכה של 13, פרט למפתח אחד שהציע 8. במקרה זה, מותר לו לדבר ולספק סיבות לאומדן הנמוך שלו. נניח שהוא מציע את ההצדקה הזו: הוא עבד בעבר על אותה משימה, וזה לא כל כך קשה כמו שזה אולי נראה. בסופו של דבר, הוא משכנע את שאר הצוות לשנות את דעתם מ-13 ל-8 נקודות סיפור, ואומר שהוא יעזור למי שבסופו של דבר לוקח את המשימה הזו. ואולי הוא יעשה זאת בעצמו. בכל מקרה, זה לא משנה אם האחרים יקבלו את טיעוניו או לא, כי כך או אחרת תוקצה אומדן למשימה, והצוות יעבור לשקול את המשימה הבאה. בתחילה, ההערכות יהיו לא מדויקות, וכך גם ההערכות של כמות העבודה שאתה מתכנן לבצע בפרק הזמן הבא (ספרינט). הרי ההערכות הללו נעשו באמצעות אומדנים. לאחר זמן מה, אולי שלושה חודשים לאחר מכן, הצוות יתחיל להעריך את הזמן הנדרש למשימות בצורה מדויקת יותר, ותתברר כמות העבודה הממוצעת שהצוות מסוגל לבצע בספרינט. אבל זה תהליך ליצירת תכנית כללית להיקף העבודה. זה מתמקד בעיקר בזמן, אבל במקרה זה עשויים להיות הרבה גורמים רלוונטיים ושונים. לדוגמה, נניח שמפתח יצא לחופשה למשך שבועיים. תצטרך לחתוך כמות מסוימת של עבודה מתוכננת (פונקציונליות מתוכננת). או נניח שמפתחת חדשה הצטרפה לצוות, אבל עדיין לא מעודכנת במלואה, אז אתה צריך לתת לה זמן להכיר את הפרויקט באמצעות תהליך הצטרפות . זה יכול להיות שבועיים, לתת או לקחת שבוע, תלוי במורכבות הפרויקט. זה הכל להיום! אני מקווה ששיפרתי מעט את הידע שלך בהערכת מאמץ, היבט לא טכני הכרחי של פיתוח תוכנה. אם אתה רוצה להעמיק בנושא זה, ולפרטים של scrum, אני ממליץ לך בחום לקרוא את הספר "SCRUM" מאת ג'ף סאתרלנד. אני לא יכול להבטיח שום הבטחה לגבי ההשלכות, כי אחרי שתקרא את זה יהיה לך רצון מעצבן להיות אמן סקרום =D