באילו שיטות מפתחים משתמשים כדי להעריך משימות?

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

מה אם אתה לא מקבל את הדירוג נכון?

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

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

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

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

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

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

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

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

מה זה Scrum Poker

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

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

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

צריך הפסקה

שיטות הערכה נדירות יותר:

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

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

דוגמה להערכת משימה

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

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

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

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

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