Posts tagged ‘תהליך’

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

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

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

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

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

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

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

ההוכחה שאג’יל עובד.

clip_image001שינוי משמעותי כגון שינוי של שיטת עבודה הוא שינוי קשה לרוב האנשים, ולכן לפני שאנשים מוכנים לשקול את ביצוע השינוי אחת השאלות שעולות היא “האם השינוי הזה טוב בשבילי?”. השאלה היא כמובן לגיטימית ועניינית מאוד.
אם תקראו חומר ברשת, וחומר כתוב בנושא אג’יל וסקראם, תגלו שכרגע יש סוג של הימנעות מלהתעסק בחיפוש מדדים וראיות ששיטות אג’יליות וסקראם בפרט, עובדות.
באופן אישי אני חושב שבשלב הזה התעסקות בשאלות כאלה יכולה אמנם להפיק תועלת מסוימת אך לדעתי הנזק שעלול להיגרם הוא גדול יותר, בשורות הבאות אסביר למה אני חושב כך.
• הרגע הגענו… – קודם כל יש להפנים את העובדה שמדובר בנושא חדש, התפיסה האג’ילית הינה דבר חדש. סקראם, שנחשבת ע”י חלק מהאנשים למתודולוגיה האג’ילית הוותיקה ביותר, הייתה בשימוש לראשונה באמצע שנות התשעים, וגם זה, בקנה מידה מזערי. Extreme programming – שהיא אולי השיטה הנפוצה ביותר בתחום כיום, הוגדרה לראשונה בסוף שנות ה-90, ורק בשנת 2000 פורסם הספר הראשון שמתאר את השיטה. אז אתם מבינים שכל הסיפור הזה הוא די חדש.
למרות כל זאת, קיימים מחקרים שמצביעים על כך שחלק גדול “מהעובדות” שעליהן מתבססות המתודולוגיות המסורתיות, ובפרט שיטת המפל, הן עובדות שווא, כמו כן קיימים מספר תחומים אשר יעילותם היא כבר קונצנזוס די רחב בתעשיית התוכנה, דברים כגון תכנות בזוגות (pair programming), צוותים מנוהלים עצמאית (self directed teams) ועוד.
• עוד לא למדנו איך למדוד – עקב הרגלי העבודה שלנו בשיטות המסורתיות, ובהתבסס על הנחות היסוד שמהוות את הבסיס לשיטות אלו, היה קל באופן יחסי למדוד הצלחה, תפוקה או כישלון במונחים “אובייקטיביים”. כל מה שהיינו צריכים לעשות זה להשוות את התוכניות למציאות, ככל שהיינו קרובים יותר לתוכנית נחשבנו מוצלחים יותר, זה קל.
בפרויקטים אג’ילים הנחת היסוד היא שלא ניתן לייצר תוכנית מספיק טובה שתשמש אותנו לכל אורך הפרויקט, דבר זה מייצר בעיה למדוד הצלחה או כישלון בכלים הרגילים, מכאן ברור שהצלחה או כישלון של פרויקט אג’ילי היא דבר שקשה יותר למדוד, הרי עדיין אין נתון חד משמעי שניתן לבדוק מולו את ההצלחה. בעיה.
המדדים שמצביעים על הצלחה של פרויקט אג’ילי לפי דעתי קשורים בעיקר לשני תחומים: שביעות רצונו של הלקוח ואיכות. מכיוון שהראשון הוא סובייקטיבי לחלוטין הרי קשה (למרות שאפשרי) למדוד את נתון זה, ואף קשה יותר לייצר סטטיסטיקות שמתבססות על נתון זה.
נותר לנו מדד מהימן אחר שהוא האיכות, על איכות כבר דיברתי לא מעט, אבל למרות שאין לי כל סטטיסטיקה, ובודאי שאני לא מייצג שום מדגם, הפרויקטים האג’ילים שלקחתי בהם חלק הצטיינו באיכותם פי כמה מהפרויקטים ה”לא אג’ילים”.
לסיכום הנקודה, קשה הרבה יותר למדוד הצלחה של פרויקטים אג’ילים.
• מי שמבקש הוכחות, מחפש משהו אחר – יכול להיות גם שחלק מאותם אנשים שמבקשים הוכחות ל”איכותה” של התפיסה האג’ילית למעשה לא מחפש חיזוקים בכדי לאמץ תפיסה זו. בחלק מהשיחות שאני מבצע עם אנשים אני חש לעיתים כי כשהם שואלים שאלות הם לא באמת מחפשים לחקור, להבין ולבדוק את האפשרות לאמץ תפיסה חדשה, אלא מנסים בכל הכוח להמעיט בערכה של תפיסת עולם שלא נוח להם איתה. האם אנשים אלו ריאלים מספיק בכדי להפנים את העובדה שפיתוח תוכנה בבסיס אינו תהליך פשוט ובטח שלא מושלם? האם הם מוכנים לקבל את העובדה שמה שאני מספר עליו הוא לא פתרון הקסם אלא הצעה לשיפור? האם בכלל הם באמת מחפשים הוכחה שזה עובד, או שמא מחפשים את אותה תחושת ביטחון מזויפת שנגזרת מהאמונה שאם משהו עבד למישהו אחר הוא מתאים גם להם?
דבר אחרון אולי בנושא זה, רבים שאותם אנשים שטוענים שהתפיסה האג’ילית אינה טובה, כלל אינם מכירים או מבינים אותה. לעתים הבקשה הלא מקוימת להוכחה, משמשת אותם כמנגנון הגנה מפני השינוי המתבקש.
טוב, אחרי שטענתי שלדעתי התעסקות בשאלת ההוכחה היא מיותרת בעת זו, בכל זאת צריך שיהיה משהו, לא? אז אם תסתובבו קצת ברשת של הכפר הגלובלי שלנו שנקראת האינטרנט, תוכלו למצוא לא מעט דעות חיוביות, בלוגים, קבוצות דיון וכדומה בנושא, כמעט כולם משבחים את העניין, כמעט כולם מביעים שביעות רצון גבוהה מהמעבר לחשיבה אג’ילית. ישנם סקרים של גופים לא נייטרלים שמראים שביעות רצון גבוהה ממעבר למתודולוגיות אג’יליות – זה גם משהו לא? בנוסף יש לא מעט סיפורים (case studies) על מעבר לתפיסה האג’ילית, ואף אוסיף ממש בקרוב דף באתר שמרכז לינקים בנושא.
על היתרונות של התפיסה כבר כתבתי לא מעט ועוד אכתוב הרבה, אם אתם מאלה שלא מוכנים לנסות עד אשר תוגש להם ההוכחה שזה עובד על מגש של כסף (וזה לגיטימי לגמרי מבחינתי) אני מזמין אתכם להישאר קשובים, להמשיך לקרוא ולהתעניין בנושא, ומקווה שיום אחד יקרה אחד מהשניים: תסכימו לתת צ’אנס לנושא, או שמישהו יספק איזה שהוא סקר שירצה אתכם.

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

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

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

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

תפיסת ה-“בחינה והתאמה” מיושמת בסקראם באמצעותה של ישיבה שמתבצעת בסוף כל ספרינט ונקראת רטרוספקטיבת הספרינט (Sprint retrospective).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איכות ללא תחרות….

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

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

בואו נדון רגע בשאלה – כיצד מודדים איכות של תוכנה ? ישנם מספר מדדים מקובלים:

  • איכות הקוד – קריאות, תיעוד (הערות), סיבוכיות, מספר אזהרות הידור (Compilation warnings)
  • איכות המוצר – כמות באגים, כיסוי הבדיקות, היקף הבדיקות, סוגי הבדיקות.
  • ביצועי המוצר – משך הזמן שלוקח לפעולה מסוימת להתבצע, השפעה של עומס על המערכת, השפעת התוכנה על הסביבה שבה היא רצה.
  • אוסיף כי בספרות מופיעים גם הדברים הבאים כמדדים לאיכות, ואין לי כוונה להסביר כל אחד מהם (חפשו בויקיפדיה): Completeness, Conciseness, Portability, Consistency, Maintainability, Testability, Usability, Reliability ועוד ועוד….

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

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

איך מתמודדים עם זה בסקראם? DoD – Definition of DONE.
כפי שכבר הזכרתי בעבר בסיום כל ספרינט מציג הצוות את המשימות שהוא הצליח לסיים וה-product owner צריך להחליט האם המשימות נעשו לשביעות רצונו.
מה זה לשביעות רצונו – DoD.
אחד הדברים שהגדרת ה-DONE מתמודדת איתו היא האיכות, הגדרת ה-Done עלולה לכלול דברים כגון, משימה נחשבת DONE רק אם היא:

  • עברה Unit test עם כיסוי של 80% מהקוד.
  • עברה System test עפ”י הגדרה מסוימת.
  • עמדה בעומס כזה וכזה…
  • עברה Clean build
  • וכו’

כל הדברים הללו הינם דברים מוחשיים שניתן להציג ל-product owner, אני לא מדבר על מסמך שמראה שנעשו בדיקות או על גרפים כאלה ואחרים בפאואר פוינט, אני מדבר על להראות את ה-unit tests רצים, ואח”כ להראות את התוצאות של ה-Code coverage, ולהדגים את התנהגות בעומס וכו’.

הגדרת ה-DONE הינה אחריות משותפת של ה-product owner והצוות, ולמעשה הגדרת ה-DONE מהווה (בין השאר) מדד לאיכות, שהרי אנו יודעים שכל מה שנמצא במערכת עונה להגדרת ה-DONE. אם הוא לא עומד בהגדרה, אחריותו של ה-product owner לדחות את הפיתוח כולו, עד אשר יעמוד בהגדרה – התנהלות זו מבטיחה לנו למעשה עמידה בסטנדרטים שהציב לנו ה-product owner ומעבר לכך, הופכת את האיכות לדבר מוחשי, וברור. *שימו לב איך מה שכתוב כאן משתלב עם העיקרון האג’ילי – Working software is the primary measure of progress.

ולמי ששואל את עצמו, אז כן – אין אמצע, אם זה לא DONE זה לא קיים! (שוב נושא לפוסט אחר)

אלמנטים של סקראם…מה זה DONE ?

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

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

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

בואו נתבונן רגע בהגדרת DONE:

  • הקוד גמור
  • בדיקות גמורות
  • הפיצ’ר אושר ע”י מנהל המוצר.

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

  • הקוד גמור
  • נכתבו Unit tests והם רצים בהצלחה.
  • נכתבו Integration tests והם רצים בהצלחה.
  • הבדיקות התווספו לתשתית האוטומציה.
  • הפיצ’ר תועד (לפי הצורך).

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

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

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

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

נ.ב. – התוספת של התמונות לפוסטים מפריעה? מוסיפה? לא משנה? – אנא תגובתכם.

זהו – אני סיימתי – …I am DONE

 

*מקור התמונה : http://www.flickr.com/photos/hawaii-mcgraths/2701705139/lightbox/

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

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

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


דוגמא לגרף ספרינט (אמיתי לחלוטין)

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

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

מצב ראשון: ספרינט 2, התקדמות כצפוי, נראה שנסיים אחרי 7 ספרינטים:
clip_image004

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

עוד המחשה לשקיפות היא שפירוט המשימות ברמת הספרינט הוא זמין ונראה לכל עקב כך שמתוחזק על גבי לוחקירטבלת אקסל. (בניגוד לאחרות התמונה הזאת לא שלי…)

ישנם עוד מססר אלמנטים שמקובל לשקף בשיטות דומות.
זהו. שקיפות. יתרון גדול של סקראם!

למה אנחנו לא עומדים בזמנים ?

אני לא מבין למה אנחנו לא עומדים בזמנים?

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

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

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

אם התשובה לשלושת השאלות היא כן, איחולי – שברתם את הסטטיסטיקה!
http://net.educause.edu/ir/library/pdf/NCP08083B.pdf
הלינק הוא סקר CHAOS המקובל מאוד בעולם המציין שיעור ההצלחה לפרוייקטי תוכנה הוא שרק 9% מפרוייקטי התוכנה בחברות גדולות ו-16.2% ו-28% בחברות בינוניות וקטנות (בהתאמה) מצליחים.