Posts tagged ‘product backlog’

כמה זה מספיק ?

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

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

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

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

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

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

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

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

כל אחד הוא מיוחד

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

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

imageולשמחתי חלק גדול מה-Product owners כבר הפנימו את הנקודה הזו והם מבינים, ועזבו רגע אסורמותר, שלא כדאי לשנות תכולה במהלך הספרינט. יופי !
עקב כך, אותם POs דואגים בין השאר לסדר את הבקלוג לפי עדיפות פיתוח אמיתית… כמעט.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק שני

לפני שאני ממשיך אני רוצה להזכיר שהפוסט הוא חלק שני וההתחלה שלו נמצאת כאן.

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

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

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

עבור כל פריט מהרשימה, נסמן לכל קריטריון בתא המתאים בטבלה האם הוא טוב יותר (+), טוב פחות (-) או טוב באותה המידה (0). אחרי שסימנו את כל הטבלה נותר רק לסכום עבור כל פריט: כל ‘+’ מעלה בנקודה, כל ‘-‘ מוריד נקודה ו-‘0’ לא משנה ניקוד. למעשה, דירגנו את הפריטים באופן יחסי זה לזה (על סמך פריט הבסיס כמובן).
את השיטה הזאת ניתן לשכלל במספר דרכים שכמובן דורשות מאמץ נוסף כגון:
– להחליט על פריט להשוואה שונה עבור כל אחד מהקריטריונים וכך לקבל תמונה טובה יותר.
– במקום להשתמש ב ‘+’ ו ‘-‘ ניתן להשתמש במספרים 1-5, שלא רק אומרים אם פריט מסוים עונה טוב יותר או פחות על קריטריון אלא גם לציין עד כמה באופן יחסי.
– ניתן להוסיף פקטור לכל אחד מהקריטריונים בכדי לבטא את החשיבות שלו למשל לקריטריון 1 ניתן פקטור של 0.5 ולקריטריון 2 ניתן פקטור של 0.1 ורצוי שסה”כ הפקטורים יהיה 1 (על בסיס של 100%).
– וניתן כמובן לשכלל את המודל בכל צורה שעולה על דעתכם.

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

ניקוד יחסי.
הרעיון הכללי בניקוד יחסי הוא הכללה מספר פרמטרים שעד כה לא לקחנו בחשבון במודלים הקודמים, הפרמטרים הללו הם: עלות ותועלת. אם עד כה הצגתי שיטות שמנסות לדרג את הפריטים ע”פ האיכות הפונקציונאלית שלהם, אציג כעת שיטה שנותנת משקל לעלות והתועלת שכל אחד מהפריטים מביא איתו. לדעתי לא ניתן לומר בצורה חד משמעית אם השילוב של הפרמטרים האלה הוא טוב או רע, וכנראה שזה תלוי בסוג הפרויקט, ובהעדפה אישית, יש שיגידו שהאיכות הפונקציונאלית כבר כוללת בתוכה את התועלת, והתחשבות בעלות היא חשובה, אבל פחות. כפי שציינתי זה גם מאוד תלוי על איך מגדירים את המושג ROIומהן מטרות הפרויקט.
במודל הזה, עבור כל פריט אנחנו ננסה לענות על מספר שאלות, תוך שימוש במספרים 1-9 כתשובות אפשריות. השאלות עליהן אנו מתבקשים לענות הן, אני גם אתן דוגמאות בכדי להמחיש:
– מה היא תועלת יחסית שנקבל אם הפריט ייכלל בתכולה ?
– מה הוא נזק יחסי שיגרם אם הפריט לא ייכלל ?
– מה היא העלות ?- הערכת מאמץ (לא משנה באיזה יחידות)
דוגמאות להמחשה :
– תמיכה ל-iPhone – מצד אחד יש תועלת משמעותית כי זה יכול לחשוף את האפליקציה שלנו לשוק חדש, מצד שני, אם לא נכלול את זה, יגרם נזק אבל הוא לא משמעותי. הערכתנו לפיתוח היק 20 נקודות (Story points).
– תמיכה בחוק הספאם לרשימות תפוצה – אם לא נוסיף תמיכה אז הנזק יהיה משמעותי ונאבד חלק ניכר מהלקוחות, למרות שהוספה שלו לא נותנת לנו שום תועלת ממשית. הערכתנו לפיתוח היא 8 נקודות (Story points).

אחרי שסיימנו למלא את הנתונים, מבצעים את החישובים הבאים :
– ערך = (ייכלל) + (לא ייכלל)
– ערך יחסי = 100 * (ערך סכום (ערך))
– עלות יחסית = עלות סכום (עלות)
– דירוג = 100 * (ערך יחסי עלות יחסית).

התבוננות על שדה הדירוג מדרגת את הפריטים לפי עדיפות מהגבוה לנמוך.

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

כמו שאומרים… עד כאן דברינו להיום בנושא של מיון וסינון תכולה, ניפגש בפוסט הבא. :)

אלמנטים של סקראם… מיון רשימת הדרישות (Product backlog) – חלק ראשון

אחד הגורמים שמשפיעים על הצלחתם של פרויקטים בכלל, ופרויקט תוכנה בפרט הוא ההחזר על ההשקעה (ROI – Return on investment), סקראם (Scrum) מתייחס בכובד ראש לעניין זה ולכן טוען שעל רשימת הדרישות להיות מסודרת בצורה כזו, שבראש הרשימה נמצאים האלמנטים בעלי הערך הגדול ביותר. כמובן שיש יוצאי דופן כגון פריטים שמהווים בסיס לפיתוחם של אחרים, אבל באופן כללי אנו שואפים למזער תלויות. בהינתן שהפריטים ברשימה מסודרים “נכון”, ואנו מפתחים את התוכנה לפי הסדר של הפריטים ב-backlog, אנו למעשה מגדילים משמעותית את הסיכוי להצלחתו של הפרויקט מבחינת ה-ROI.

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

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

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

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

clip_image004מרגש –Exciter – אלה הם מאפיינים של מוצר שהלקוח אפילו לא ידע שהוא רוצה עד שהוא ראה אותם, דוגמא למאפיין כזה הוא למשל שלט שפותח את דלתות המכונית, וכן, בד”כ מאפיינים מסוג זה לא נשארים כאלה לאורך זמן.
חובה–
Mandatory– מאפיינים שבלעדיהם אין זכות קיום למוצר, דוגמא למאפיין כזה היא למשל האפשרות לשמור קבצים במעבד תמלילים.
לינארי – Linear – ניתן לאפיין את הסוג הזה בעזרת המשפט “כל המרבה, הרי זה משובח”, ככל שיש יותר כאלה, כך שביעות הרצון של הלקוח עולה. דוגמא למאפיין כזה היא למשל כמות הזיכרונות במכשיר סלולארי.
מפוקפק – Questionable – כזה שלא מספיק ברור לגביו מה הסיווג.
הפוך – Reverse – כזה שברור שהלקוח לא רוצה.
משהו – Indifferent – משהו שלא משנה ולא במעט את שביעות הרצון של הלקוח.

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

לתשובות לשאלות, קאנו מציע פורמט טקסטואלי לתשובות, וטבלה שעבור כל זוג תשובות, מספקת סיווג (האות בטבלה מסומנת באדום בהגדרת הסיווג שמעל):
– מאוד מוצא חן בעיני.
Kano table– אני מצפה לכך.
– אני ניטרלי.
– לא מאוד מפריע לי.
– מפריע לי.
אז מה עושים אחרי שסיווגנו ? אין המלצה חד משמעית, ברור שכל מה שסווג כ-M חייב להיות במוצר, גם ברור שיש צורך בלפחות חלק מה-L, וכדאי מאוד שגם תשאירו מקום ל-E. בשלב הזה לצערי תאלצו להפעיל את הראש קצת מעבר למודל, כאן נכנסים שיקולים נוספים כגון יעדי הפרויקט, מצב השוק וכדומה.
המודל של קאנו מספק לכם יותר מידע לגבי הפריטים, ואולי גם חלוקה גסה, אבל הוא לא מספק פתרון מלא ומשאיר מקום לשיקול דעת ומחשבה, וטוב שכך.

עוד מודלים בפוסט הבא.

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

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

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

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

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

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

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

אלמנטים של סקראם והפעם… Product owner.

בפוסט הקודם כתבתי על ה-product backlog, וציינתי שהאחראי למיון שלו הוא ה-product owner.
לתפקיד ממונה באופן אידיאלי מישהו ממחלקת השיווק או מישהו בעל תפקיד מפתח בפיתוח, בכל מקרה, מישהו שקרוב ללקוח ככל שרק ניתן. מייד תבינו למה.

לתפיסתי והבנתי ל-product owner יש חמישה תפקידים עיקריים:

  • מיון ועדכון ה-product backlog – , כפי שכבר ציינתי ה-product backlog מעודכן באופן תדיר ורצוף ע”י גורמים שונים כגון, הלקוח, ה-product owner, הצוות וכו’.
    בסקראם אין שום מגבלה על הוספת פריטים לרשימה, אך היחיד שמותר לו למיין את הרשימה ולהחליט מה בעדיפות גבוהה הוא ה-product owner. מכך ניתן להסיק למעשה שעל כתפיו של ה-product owner מונחת אחריות כבדה, עליו “לנווט את הפרויקט במים סוערים” ולדאוג שהכיוון שאליו אנו מפליגים הוא אכן בעל הערך הרב ביותר עבור הלקוח, מכך נובע שהתפקיד דורש הבנה אמיתית של צרכי הלקוח ואף רצוי מאוד קשר רציף ואיכותי עם הלקוח עצמו ע”מ לוודא באופן קבוע שמה שאנחנו עושים מספק ערך ללקוח.
    יש להדגיש, ה-product owner איננו נחשב חלק מהפיתוח, ואין לו שום סמכות מקצועית לגבי ה”איך” וה”כמה” אלא רק לגבי ה”מה”, שם יש לו מנדט מלא לקבלת החלטות, גם בניגוד לדעתם של צוותי הפיתוח.
  • שומר השער של המוצר – כפי שכבר הזכרתי בעבר, כאשר מסתיים ספרינט והצוות מציג את הפריטים שהם סיימו מתוך הרשימה, על ה-product owner (והלקוח אם הוא שם) להחליט אם הפריט בוצע לשביעות רצונם של המעורבים – בסקראם למצב של שביעות רצון קוראים DONE, כאשר מסכמים על פיתוח פריט נקבעים בין הצוות ל-product owner גם הקריטריונים לשביעות רצונם של המעורבים. כאשר הצוות מציג את הפריט בסוף איטרציה (ספרינט), על ה-product owner להחליט האם הפיתוח עומד בקריטריונים הללו או לא.
  • להיות הקול של הלקוח עבוד צוות הפיתוח – כדי להגדיל את הסיכויים להצלחת הפרויקט (סיפוק רצונו של הלקוח) חשוב לקיים קשר רציף בין הפיתוח ללקוח. כאשר צוות הפיתוח זקוק להבהרות לגבי דרישות אלא ואחרות, הוא פונה ל-product owner, הוא אמור לספק את התשובות הרלוונטיות תוך ייצוג תפיסת עולמו של הלקוח. על ה-product owner מוטלת החובה והאחריות לוודא שהצוות עומד בסטנדרטים גבוהים של איכות, למשל עליו להתעקש על כיסוי בדיקות גבוה (לפחות 70%), על שקיפות של הפיתוח ועוד, אך עליו לשים לב לא להציב מטרות בלתי אפשריות ובכך להביא למצב שתפוקת הצוות תרד משמעותית.
  • השתתפות בתכנון ספרינט – בתחילתו של כל ספרינט יושב ה-product owner ביחד עם הצוות ומסביר לפי הצורך על הפריטים שנמצאים בראש ה-product backlog, הצוות אז בוחר על כמה מתוך הפריטים בראש הרשימה הוא יכול להתחייב ויוצא לדרך.
    למה אני מציין את זה כתפקיד? זו סה”כ ישיבה, לא? לא!
    ישיבת תכנון הספרינט היא ישיבה חשובה ארוכה וקשה, ויש נטייה למשל להגיע לא מוכן לישיבה, ה-product backlog לא מעודכן, או שה-product owner לא מבין את הפריטים ברמה מספיקה כדי לספק תשובות לצוות. תפקידו של ה-product owner להשתתף בישיבה ולמלא את חלקו, לא מספיק להיות שם, הצלחת הישיבה היא רכיב קריטי להצלחת הספרינט.
  • לא להפריע – תפקיד חשוב שיש ל-product owner הוא לא להפריע לצוות, אני יודע שזה אולי נשמע טריוויאלי אבל זה לא, ממרום מושבו ה-product owner עלול לחוש סמכות על הצוות ואף עלול להרשות לעצמו להציק להם מהלך הספרינט, להציע הצעות טכניות, לבדוק, לשאול, ולעיתים רחוקות אף נתקלתי בכאלה שמבקשים לשנות את התכולה של הספרינט. ובכן, לא מקובל! ה-product owner מקבל התחייבות מהצוות בתחילת כל ספרינט לתכולה מסוימת, בתמורה הוא מתחייב לא להפריע להם במהלך הספרינט. אני לא אומר הפרדת רשויות, אך עליו לכבד את הפיתוח ואת הזמן שלהם – נושא בעייתי בפיתוח גם ככה.

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

יש לכם רעיון איך אומרים product owner בעברית ? תגיבו.

אלמנטים של סקראם והפעם… Product backlog.

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

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

  • הרשימה בד”כ מיוצגת בתוך טבלה, כל שורה בטבלה מייצגת דרישה של הלקוח, עבור כל דרישה בד”כ מציינים את השדות הבאים (בד”כ מוסיפים שדות נוספים):
    • תיאור – תיאור מילולי של הדרישה
    • הגודל של הדרישה – לא להתבלבל עם הערכת זמן, גודל מציין גודל של הדרישה, כשנדבר על הערכות זמנים ותכנון אג’ילי נחזור לדון לעמוק בנושא זה.
    • רמת הסיכון (לא חובה)
    • העדיפות – דירוג העדיפות של הפריט (המקפידים יגידו – ערך ללקוח).
  • כל שורה בטבלה מייצגת דרישה – ולמרות שסקראם לא מדבר על איך הדרישה מתוארת, לפי ניסיוני רצוי שהדרישות יהיו בעלות ערך ללקוח, מה הכוונה – למשל פריט כגון “תשתית תקשורת לחיבור של השרת והלקוח”, זה משהו שאינו נותן שום ערך ללקוח בפני עצמו ולכן אין לו מקום ב-product backlog לדעתי, לעומת זאת, “מסך להוספת לקוח חדש למערכת” זה פריט שנותן ערך ללקוח. יש לציין כי לעיתים רחוקות אין מנוס מפריטים טכניים ב-product backlog.
  • ככל שמתקרבים לראש הרשימה יש יותר פרטים על כל פריט ואף מחלקים פריטים גדולים לחלקים .
  • ניתן להשתמש באותו product backlog למספר צוותים.
  • תמיד שואפים להוריד את התלויות בין הפריטים למינימום האפשרי.
  • ה-product backlog נגיש לכל מי שקשור לפרויקט וכל אחד יכול להוסיף פריטים, לעומת זאת רק לאדם אחד יש את הרשות למיין את הרשימה, מי שאחראי ל-product backlog הוא מנהל המוצר (Product owner), והוא אמור לדאוג שהרשימה תמיד מעודכנת וממוינת, איך ממיינים? בפשטות ובסדר הבא: תלויות (אם יש) -> עדיפות -> רמת סיכון, כלומר מי שמכתיב את הסדר של הפיתוח זה קודם כל הלקוח, לא אף אחד אחר, אם ישנם פריטים עם אותו ערך אז מפתחים קודם את המסוכן יותר, זאת כדי להסיר מכשולים מוקדם ככל האפשר.
  • אם ניקח את כל הנתונים שמופיעים ב-product backlog נהיה מסוגלים למעשה להעריך את מצב הפרויקט, קצב ההתקדמות של הגירסאהפרויקט ותאריכי סיום משוערים, או לחילופין מה תהיה התכולה לתאריך היעד.
  • זהו. אין הרבה מעבר לכך – אוסיף רק שתי הערות:

  • יש כל מיני תוכנות לניהול סקראם שמציעות כל מיני כלים לניהול ה-product backlog, אך אני מצאתי שהדרך שהכי נוחה לי היא פשוט להשתמש ב-Excel או גיליון נתונים דומה, ואף יש כאלה שמנהלים את הרשימה על הקיר באמצעות פתקים דביקים (אלמנט שחוזר על עצמו הרבה בסקראם).
  • ה-product backlog מחליף אלמנטים מהפרויקט המסורתי, אלמנטים שלוקח הרבה זמן להכין, ועוד יותר זמן לעדכן ולתחזק:
    • תרשימי ה-Gantt וה-Pert – מוחלף ע”י עיבוד פשוט של הנתונים מה-product backlog.
    • מסמך דרישות מפורט – כל הדרישות נמצאות ב-product backlog.
    • לפעמים אפילו מסמכי Acceptance test – עוד נרחיב כשנדבר על בקרת איכות ובדיקות.
  • אני יודע שהמאמר הזה הוא קצת לקוני אך לא מצאתי דרך יותר טובה לתאר את ה-product backlog מבלי להיכנס לעומקם של דברים אחרים. עימכם הסליחה.

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