Posts tagged ‘תכנון’

כמה זה מספיק ?

אחד הדברים שהתפיסה האג’ילית מדברת עליהם הוא פשטות ולעשות "מספיק" (Just enough).
כמה זה "מספיק"?
מספיק זה לא פחות ממה שצריך אבל גם לא יותר, בעיקר לא יותר.

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

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

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

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

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

דוגמא לבקלוג עם רמת תכנון לא עקבית – לחצו על התמונה להגדלה:
clip_image004

דוגמא לבקלוג עם רמת תכנון עקבית – לחצו על התמונה להגדלה:
clip_image006

כלים אג’ילים – יש דבר כזה?

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

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

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

נסקור את הסיבות לשימוש ב”כלים אג’ילים” שאני נתקל בהן:

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

בקרה: כלי אג’ילי מאפשר לי לדעת בכל רגע נתון, מה המצב של הספרינט הנכחי ושל הפרויקט כולו: למה כל  כך חשוב לך לדעת בכל רגע נתון וברמת הספרינט מה המצב? האם את לא סומכת על הצוות שכאשר תהיה בעיה הם יצרו איתך קשר ויתריעו על כך? האם לא סביר בעינייך פעם במספר ימים לקפוץ לישיבת הדיילי ולשמוע במו אזנייך מה קורה? רצוי אפילו שתפגיני מעורבות אמיתית, ע”י “ירידה לעם” מידי פעם.
ברמת המוצר, גרף ה-Burndown של הפרויקט אמור לתת לך תמונה מאוד ברורה על מצב הפרויקט הנכחי. מעבר לכך כל נתון אחר אמור להיות שקוף וחשוף ע”פ הצורך ואם הוא לא – ישנה בעיית שקיפות.ושום כלי לא יעזור, הוא רק יחמיר את המצב. לצורך בקרה אין צורך בכלי!

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

ניתוח נתונים: כלי אג’ילי מאפשר לי לנתח את הנתונים בפרויקט שלי: איזה נתונים בדיוק צריך לנתח שלא ניתן לעשות בכלים פשוטים? עלות פרויקט ליום? אני מוכן לתת לכם את הנוסחה הפשוטה (מספר אנשים שעובדים ליום * עלות של אדם ליום + תקורה יומית). הנתון הכי חשוב בפרויקט הוא Velocity והוא מחושב מעצמו ע”י ניהול נכון של פרויקט. ממנו קל לגזור נתונים חשובים כגון עלויות, זמנים ועוד.לצורך ניתוח נתונים אין צורך בכלי!

עקרון חשוב ומנחה במניפסט האג’ילי (עקרון 5) הוא:

Build projects around motivated individuals, give the environment and the tools they need, and trust them to get the job done.

עקרון נוסף חשוב (עקרון 11) הוא:

The best architectures, requirements and design emerge from self-organizing teams

בכלים האג’ילים הללו  הדגש הוא על דיווח ומעקב, דבר שסותר כמעט באופן מלא את העקרונות האג’ילים שציינתי מעל. מנסיוני התוצאות של שימוש בכלים כאלה, כמעט תמיד גורר עיוות של המציאות ע”י סילוף של הנתונים.
למשל: מי רוצה כל יום מחדש לתת הסברים על למה הגרף לא מתקדם כצפוי, עדיף פשוט לגרום לו להתקדם ככה ולעבוד בשקט…

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

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

לסיום אני רוצה לצטט משפט מתוך ספר של בס וודה וקרייג לרמן:
If you automate a mess, you will get an automated mess.

ספרינט בקלוג – Smells

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

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

בפוסט הזה אני הולך לדבר על ריחות של ספרינט בקלוג – Sprint backlog smells .

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

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

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

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

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

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

צבעוני מידי – בהפוך לקודם גם לא כדאי שהוא יהיה צבעוני מידי, למה אני מתכוון? ראיתי כבר בקלוגים שלכל סוג משימה (בדיקות, תיעוד, קידוד, DB וכדו’) יש צבע פתק מיוחד, זה יכול להצביע על בעיה פוטנציאלית בצורת העבודה של הצוות, ואף עלול להצביע על ריכוזיות בתוך הצוות, כאשר כל חבר צוות “יודע” איזה צבע מעניין אותו.
בנוסף, זה עלול להעיד על Mini-Waterfall בתוך הספרינט.

פתקים “ברוורס” – אם רואים לעיתים קרובות מידי פתקים עושים “פניית פרסה” וחוזרים מעמודת “Done” לעמודת “In work”, זה עלול להעיד אולי על בעיתיות בהשלמת המשימות, ואולי על בעיה בהגדרת המשימות עצמן.

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

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

רוצים לסיים מוקדם – תתחילו באיחור!

האם אי פעם נתקלתם בסיטואציה כזו:

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

clip_image002

המצב המתואר מוביל לכך שלאט לאט, ומבלי לשים לב, כמות העבודה הלא גמורה (WIP – Work in progress) גדלה, הבאגים נצברים, מנהלי המוצר דואגים בשלב זה בעיקר לכך שיתחילו המשימות החדשות מבלי לתת תשומת לב להשפעה על סיום המשימות הקודמות.

למה זה כל כך רע?

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

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

למה אנחנו נופלים כל פעם למלכודת הזאת? לדעתי זה קשור לאינסטינקטים המטעים שלנו (דוגמא לאינסטינקט מטעה – כשבמאבדים שליטה על הרכב הדבר הנכון לעשות הוא לסובב את ההגה לכיוון ההחלקה ולא נגד – שזה מה שעושים אינסטינקטיבית).
האינסטינקטים שלנו אומרים שאם סיימנו משימה באיחור, אז בשביל לפתור את הבעיה פעם הבאה פשוט צריך להתחיל מוקדם יותר. כשהרעיון הוא שמה שבעיקר משפיע על זמן הסיום הוא זמן ההתחלה, וזה לא תמיד נכון, גם אם נקצה למשימה 20% יותר זמן, זה לא יעזור אם העבודה הלא גמורה שלנו מאטה אותנו פי 2!
דבר נוסף שבד”כ מעודד עבודה לא גמורה היא התרבות ארגונית, תרבות כזו שמוקירה ומעודדת “מעשי גבורה של הרגע האחרון”, תרבות שמעריכה את האנשים שיש להם “הרבה פריטים במזוודה”, מכירים את המצב שבו מי שמוערך יותר הוא מי שמדווח יותר סטאטוסים ?

בואו נחזור לדוגמא מההתחלה אחרי חודש עבודה:

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

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

תכנון פרויקטים בסקראם.

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

נתחיל במספר נקודות:

  • אם נחזור רגע להערכת משימות בשיטה אג’ילית, יש שבוחרים (ואני גם ממליץ) להשתמש ביחידות מידה יחסיות שנקראות Story points (ראו הרחבה בפוסט בנושא).
  • אחד המאפיינים הבולטים של שיטות ה-agile השונות וביניהן Scrum הוא איטרציות קבועות בזמן שבסופן הצוות מספק תוכנה עובדת (Done), היתרון העיקרי של איטרציות שכאלה, הוא קיומו של “דופק” קבוע לפרויקט, שמאפשר לנו לקבל תמונה לא רעה בכלל על מצב הפרויקט והתקדמותו, אחד המדדים החשובים שניתן לקבל כאשר עובדים באיטרציות הוא כמה תפוקה הצוות (או הצוותים) מסוגל לספק באיטרציה אחת (במקרה של סקראם ספרינט), נהוג לכנות את המדד הזה בשם Velocity.
  • רשימת הדרישות נמצאת בתוך מסמך שאנו מכנים Product backlog, המסמך מאופיין בכך שבכל רגע נתון, הפריטים בו מסודרים לפי הסדר שבו אנו מבקשים לפתח אותם.

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

אז מה אנחנו רוצים לתכנן ? התכנון מתבצע ברמות שונות:

  • יומית – בכל יום אנו מבצעים ישיבה ובודקים האם אנו עומדים בהתחייבויות שלנו לספרינט הקרוב.
  • · ספרינט – בתחילתו של כל ספרינט אנו מבצעים ישיבה שבה הצוות מתחייב לסיים מספר פריטים מרשימת הדרישות – Product backlog.
  • · גרסה (Release) – תכנון גרסה תלוי בעיקר בסוג הגרסה, אני אחלק את הנושא לשני סוגים: גרסה עם קבוע זמן, וגרסה עם קבוע תכולה.
    • כאשר הקבוע הוא הזמן, אז פעולת התכנון מנסה להעריך כמה מתוך התכולה ניתן להכניס עד התאריך הנקוב, עושים זאת ע”י בדיקה של כמה איטרציות נכנסות עד תאריך שחרור הגירסא ומתוך מספר האיטרציות ניתן להעריך תוך שימוש בנתון ה-‘velocity כמה מתוך הפריטים ברשימה נספיק לפתח.
    • כאשר הקבוע הוא התכולה, אז פעולת התכנון מנסה להעריך לכמה איטרציות נזדקק ע”מ לסיים את הפריטים שהוקצו לגרסה, זאת ע”י סכימה של הערכות המאמצים של הפריטים שאמורים להיכלל בגרסה, וחלוקת המספר שהתקבל ב-velocity. התוצאה מספקת לנו את מספר האיטרציות שאנו זקוקים להם על מנת לסיים את התכולה.
      בשני המקרים, ככל שהמידע שבידינו מהימן יותר, כך פעולת התכנון תספק הערכות טובות יותר.
  • ניתן ואף נהוג לתכנן ברמות נוספות כגון: רמת המוצר (סה”כ הדרישות לכלל הגרסאות).

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

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

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

לשיטה הזאת קוראים “פוקר תכנון” או בלעז “planning poker”.

אתחיל בתיאור השיטה ואח”כ אסביר את היתרונות שלה.

  • בתחילה מחולקת לכל אחד מהמשתתפים חבילת קלפים שכוללת את כל הערכים האפשריים, אישית אני אוהב להשתמש בסדרת פיבונאצ’י – 0,1,2,3,5,8,13,21 ובנוסף קלף שמייצג משימה גדולה מידיי להערכה שבד”כ כתוב עליו Big.
  • בשלב הבא מישהו (בסקראם זה ה-product owner) מסביר את המשימה לנוכחים ונותן אפשרות לשאול שאלות הבהרה, או להעלות נקודות בעייתיות, לעיתים אף מגיעים למסקנה שלא ניתן כרגע להעריך את המשימה, אולי המשימה גדולה מידיי להערכה או שהמשימה כלל לא רלוונטית. יש להבהיר שבשלב זה לא קוראים מסמכים טכניים או נכנסים לעומקם של דברים, אנו שואפים להבנה של המשימה ברמה רחבה ולא לרדת לפרטים.
  • אחרי שהמשימה ברורה לכולם, כל משתתף בוחר קלף שמייצג את גודלה היחסי של המשימה מתוך החבילה שבידו, לא מראה לאחרים, ומניח את הקלף על השולחן כשפניו כלפי מטה.
  • אחרי שכולם בחרו את קלף, כולם ביחד הופכים את הקלפים.
  • אם ישנה הסכמה על הערכת המשימה, נהדר, המשימה הוערכה. אם לא, שהוא המקרה היותר שכיח, מתחילים דיון קצר סביב העניין, בד”כ הדיון מתחיל בצורה כזו שמי שהעריך הכי גבוה ומי שהעריך הכי נמוך מנמקים את הבחירה שלהם, ואחרים מגיבים. אחרי שהסתיים הדיון מבצעים שוב את שלב הבחירה של הקלף.
  • בד”כ זה לא לוקח יותר משנייםשלושה סיבובים להגיע להסכמה, יש לציין שהסכמה אינה אומרת שכולם בחרו את אותו הקלף, משמעותה של ההסכמה היא שההערכות מתכנסות ויש קונצנזוס לגבי גודל המשימה, לדוגמא: אם כולם פרט לאחד בחרו את אותו הקלף ואין לאותו אדם משהו חדש לתרום לדיון, זוהי הסכמה.
  • בצורה הזאת מקובל להעריך מספר פריטים ברצף עד שסיימנו את כל המשימות או שתם הזמן שנקבע מראש.
  • Planning poker
    זוהי השיטה, או, זהו המשחק.

אז למה לנו לבצע את הערכת המשימות בצורה כזו ? ישנם מספר יתרונות

  • מעריכים בנקודות ולא בזמן – כתבתי על כך בפוסט הקודם
  • מי שמבצע את המשימה הוא גם זה שמעריך אותה – זה כמעט ברור מאליו שאם מי שמבצע את המשימה הוא גם מי שמעריך אותה, יש סיכוי טוב יותר שהערכה תהיה יותר קרובה למציאות. ישנם גם מחקרים שתומכים באמרה זו.
  • נותן דגש על הערכה יחסית – אמנם לא הסברתי נקודה זו בעבר, אך בהיעדר כלי מדידה, בני אדם באופן אינהרנטי, טובים יותר בהערכת יחס בין דברים מאשר הערכה אבסולוטית, בטח ובטח בדברים מורכבים. אם תרצו דוגמא פשטנית תנסו להעריך בסנטימטרים (ללא סרגל) את המרחק בניכם לבין חפץ או אדם בחדר, ואח”כ תנסו להעריך איפה האמצע, בד”כ את האמצע ניתן להעריך יותר בקלות ובדיוק רב יותר.
  • הערכות הן בסדר גודל אחד – שוב נובע מיכולות אנושיות, קשה לנו מאוד להעריך יחס (ובטח גודל) של דברים מסדרי גודל שונים, תנסו פעם להעריך מהו היחס בין הגודל של נמלה לכלב. קשה. לעומת זאת היחס בין תפוח לאשכולית הוא משהו שיותר קל לנו להעריך, ולכן אנו מעריכים משימות בסדר גודל אחד, ואם המשימה היא גדולה אז מחלקים אותה.
  • מפחית משמעותית את תופעת העיגון – עיגון היא תופעה בפסיכולוגיה שלה הרבה אספקטים (תחפשו בויקי – anchoring), ויש לה הרבה אספקטים, הוספתי לינק לסקר בנושא עיגון ספציפי להערכות משימות פיתוח. בגדול, העובדה שאף אחד לא אומר דעתו מראש וכל אחד צריך לחשוב בעצמו על גודל המשימה (קלפים הפוכים) מפחית משמעותית את התופעה.
  • מידול של חשיבה – התהליך (המשחק) כפי שהוא בנוי, למעשה מאלץ את המשתתפים לחשוב, כאשר כל אחד בוחר קלף, הוא לוקח בחשבון שיכול להיות שהוא יהיה אחד מאלה שיתבקשו להסביר הבחירה, ולכן הוא צריך “לעמוד מאחורי” הבחירה שלו ולהיות מסוגל לנמק אותה, דבר זה מאלץ אותו לחשוב לפני שהוא בוחר קלף ולא לבחור באופן שרירותי.
  • יתרון אחרון להיום (יש עוד לא מעט) הוא שזה מהיר וכיף! לטעמי יתרון משמעותי מאוד.
  • זהו משחק ה”פוקר תכנון” שמשמש צוותים רבים בפרויקטים אג’ילים להעריך את המשימות שלהם. אני ממליץ לכם בחום לנסות להשתמש בכלי זה, גם אם אתם לא אג’ילים.
    בהצלחה.

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

קודם כל וידוי – הפוסט הזה נכתב בהשראת המצגת שהכנתי לפורום SD, שבו אני מרצה השבוע (26/11/2008).

אם אתם זוכרים אז בתחילת הדרך כתבתי פוסט בשני חלקים (חלק 1, חלק 2) שדן בשאלה “למה אנחנו לא עומדים בזמנים ?”, אחת מהסיבות שציינתי בפוסטים אלה היא העובדה שיחידת המידה שבה אנו משתמשים איננה נכונה, יחידת המידה הזו היא זמן.

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

השם המקובל לנקודות אלה נקרא story point והוא נגזר מהמונח user stories שהיא שיטה לתאר דרישות שבאופן פורמאלי משתמשים בה במתודולוגיה Extreme programming.

הנקודות הן נטולות יחידות מידה והערך שלהן מתאר את הגודל היחסי של המשימה, גודל המשימה הוא מדד שמתאר את הדברים הבאים:

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

אבל מה ? מישהו יכול להסביר לי מה ההבדל בין משימה שגודלה 18 למשימה שגודלה 19 ? לי ברור (וניתן כמובן לחלוק על כך) שאין לנו יכולת, לכן אנו מניחים שככל שמשימה היא גדולה יותר, כך אי הוודאות בה גדול יותר. הגיוני. הפתרון המקובל הוא לא להשתמש בכל המספרים האפשריים, ולכן נהוג להשתמש בסדרות כגון חזקות של 2 או סדרת פיבונאצ’י (0,1,2,3,5,8,13,21).
דבר נוסף שיש לשים לב אליו, שקשה לנו מאוד להעריך דברים בסדרי גודל שונים, מה הגודל היחסי של זבוב לפיל ? או מה הגודל היחסי בין שינוי טקסט בכפתור לבין הוספת תמיכה באורקל ? קשה.
מה עושים ? מעריכים משימות בסדר גודל אחר, כלומר, אם אנו רואים שמשימה היא בסדר גודל גדול מידי מפרקים אותה לחלקים. איך? בפוסט אחר.
מקובל באג’יל שמשימה היא למעשה אוסף הפעולות שדרושות בכדי לפתח את הפיצ’ר, שזה כולל תיעוד, בדיקות,פיתוח וכו’, מכאן יוצא שבשביל להעריך את המשימה יש צורך בכל האנשים הקשורים לעמידה במשימה. אני קורא לאוסף האנשים הזה צוות.

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

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

ע”מ להעריך את המשימה בפועל אנחנו משתמשים בטכניקה שנקראת planning poker שעליה ארחיב בפוסט אחר, אולי אפילו הבא.

* המידע הזה ועוד הרבה מידע נוסף בנושא תכנון והערכות אג’ילים נמצא בספר הזה, והוא מומלץ בחום.