Posts tagged ‘עמידה בזמנים’

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

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

מנהל: יש לנו בקשה חדשה מלקוח לתמוך ב-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 בפרט.

אלמנטים של סקראם… מיון רשימת הדרישות (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, אז אולי למשל אפשר להשתמש במודל קאנו, להבין מהם פריטי החובה, ולבצע ניקוד יחסי רק לפריטים המרגשים והליניאריים, וזו רק דוגמא אחת לשילוב אפשרי. וכמובן שאתם מוזמנים גם להמציא מודלים משלכם.

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

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

קודם כל וידוי – הפוסט הזה נכתב בהשראת המצגת שהכנתי לפורום 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 שעליה ארחיב בפוסט אחר, אולי אפילו הבא.

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

אלמנטים של סקראם…מה זה 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

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

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

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

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

  1. יותר מידי תכולה – מה? מי נתן לי את הזכות לטעון טענה כזאת?
    לא טוב לך? לך תעבוד בחברה אחרת שם יש פחות תכולה לפרויקטים!
    ובכן, תוצאות המחקר ה”מחמיא” ביותר מראות כי 40% מכל התכונות (Features) שמפותחות אינו כלל בשימוש ו-25% מהתכונות נמצאות בשימוש לעיתים רחוקות. כלומר – יש יותר מידי תכולה!
    נכון, אתם צודקים,בד”כ הלקוח מחליט על התכולה (גם לקוח פנימי הוא לקוח), אבל איזה היגיון יש ללקוח אם הוא בוחר לשלם בממוצע 40% תוספת על תכונות שהוא לא ישתמש בהן?
    ואני אומר – היגיון בריא!
    בשיטת המפל, עוד לפני תחילת הפיתוח, מספק הלקוח לחברת התוכנה את הגדרת התוכנה ומאפייניה, עכשיו דמיינו לכם שאתם מזמינים תוכנה, ואומרים לכם “תחשוב טוב מה אתה רוצה בתוכנה עכשיו, כי אם תרצה שינוי, זה יעלה לך, והרבה!”, מה תעשו? תכנסו ישיבה ותגדירו את הדרישות, ואז פתאום תעלה שאלה, “נראה לכם שנזדקק לתמיכה באורקל ?” אז תגידו, “לא בטוח, אבל אם נזדקק זה יעלה המון, אז תכתוב שכן.”, וכך עקב העובדה שהלקוח לא רוצה לשלם יותר, ועקב העובדה שהוא מודע לכך שכנראה הדרישות שלו ישתנו בעתיד, הוא משלם הרבה כסף על דברים שהוא לא צריך. מעניין. ב- Agile רוצים שינויים – אוהבים שינויים ! והלקוח לא צריך להגדיר הכל מראש
  2. תעביר את זה הלאה – בשיטת המפל, ברגע שמתחילים לפתח, כבר יש תוכנית מפורטת שמתארת את סדר הפיתוח, כמה זמן כל דבר ייקח ואת התלויות בין המשימות (תרשימי גאנט ופרט – GanttPert). התבוננו נא בשרטוט הבא:
    clip_image002
    למי שלא הבין את השרטוט: משימה ג’ יכולה להתחיל רק כשמשימה א’ ומשימה ב’ נגמרות, למזלנו משימות א’ וב’ יכולות להתבצע במקביל ובל לחסוך זמן.
    כעת, נניח שמשימה א’ ו-ב’ תוכננו להסתיים ביחד, וקרה מקרה ומשימה א’ איחרה בגלל אחת מאלף סיבות, מה עשינו, גרמנו לאיחור של ג’ (וכל מי שתלוי בה). עכשיו תגידו: ברור – יש דרך אחרת, הרי ג’ תלויה ב-א’ ו-ב’. צודקים אבל עכשיו דמיינו לכם תרשים גאנט אמיתי, שיש בו תלויות מספיק בשביל לגרום לאשפוזכם, והא לכם עוד פרויקט שלא עומד בזמן. ב-Scrum (מימוש של Agile) יש צמצום של התלויות על ידי תכנון שונה.
  3. יחידות המידה לא נכונות – אחת הבעיות בתכנון זמנים המסורתי של פרויקטים היא, תאמינו או לא, יחידות המידה.
    יש לנו מדד מקובל שקוראים לו זמן (או שעה), ומבחינה אנושית ופסיכולוגית אנחנו די מוגבלים ביכולת שלנו לחוש באמת את יחידת המידה הזאת, בשביל זה יש לנו שעונים. בעזרת יחידת המידה הזאת אנו מודדים מספר דברים שונים :
    מאמץ (Effort) – משימה X תיקח Y שעות עבודה.
    זמן קלנדארי – אמנם Y שעות עבודה, אבל זה ייקח חודשיים עקב אילוצים אחרים.
    דוחות – כמה שעות עבדנו על מה.
    העניין הוא שבכל שימוש מסתתר מידע שאינו חשוף לקורא, לדוגמה – 100 שעות, אולי מסתתר מי יעשה את המשימה או כי 100 שעות של מפתח מנוסה הן לא 100 שעות של סטודנט, או שיש מישהו בחופש בחודש יולי ולכן המשימה לא תוכל להתקדם, או שבדוחות לא מוכנס למשל ש-M עזר ל-Z שעה בפרויקט אחר ביום שני.
    בנוסף, ובאופן מסורתי, ההנהלה תמיד מנסה לאזן את המשוואה של שלושה גורמים, שאמנם תלויים זה בזה אך בד”כ לא שווים:
    זמן קלנדארי = מאמץ ( של גרסא נניח) = זמן בדוחות.
    אסיים בשאלה האלמותית : האם אנשים = שעות ? או, האם תשע נשים בחודש ראשון יכולות לייצר תינוק ?
    לשיטות התכנון האג’יליות יש אלטרנטיבה לתכנון בשעות.

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

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

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

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

  1. העתיד מלא הפתעות: בואו ניזכר רגע בהגדרת התפקיד של אנשים שמתעסקים בפיתוח תוכנה, “Software R&D Engineer”.
    R&D = Research and development, או בשפתינו מחקר ופיתוח.
    לדעתי, מעצם הגדרת התפקיד בולטת בעיה משמעותית, אנחנו מתעסקים במחקר!
    תנסו לשאול מישהו שמפתח תרופה מתחרה לאקמול כמה זמן ייקח לו, מה הוא יגיד? כנראה “לא יודע”.
    אז למה כששואלים אותנו “כמה זמן ייקח לפתח תמיכה באורקל ?” אנחנו עונים “שבועיים, עד חודש..” או משהו בסגנון. איזה כלים יש לנו לומר דבר כזה ? מתי פעם אחרונה פיתחנו בפרויקט שלנו תמיכה באורקל ? כנראה אף פעם, אחרת לא היה צריך.
    מעבר לכך, גם אם פיתחנו משהו דומה, הרי הפרויקט השתנה מאז, כמות אי הודאות וההפתעות היא גדולה, פתאום מסתבר שזה יוצר בעיית ביצועים, או שבכלל צריך לשנות ארכיטקטורה. אני יודע שלכם זה לא קרה, אבל יש מתכנתים שבפיתוח מסוים הכפילו (או יותר) את הזמן שהוערך מראש…
  2. פחד מטעות – דמיינו לכם סיטואציה: יוסי, מפתח מנוסה ומוערך נשאל ע”י המנהל שלו: “כמה זמן ייקח לך לפתח את X ?”, עונה יוסי שייקח לו יומיים (כך הוא באמת חושב), ואז, קצת מסתבך X, לא נעים. אחרי יומיים מגיע המנהל ומצפה לקבל את X, אך הפלא ופלא, X לא מוכן… לא נעים ליוסי. מה עושה יוסי פעם הבאה ששואלים אותו כמה זמן זה ייקח לפתח משהו ? יוסי יגיד 4 ימים (ליתר בטחון), צודק יוסי! מה הוא צריך צרות?
    אני חושב שאין צורך להסביר מעבר לכך.
  3. Procrastination – סינדרום הסטודנט – מי שהיה סטודנט מכיר טוב את הסיטואציה: לדני יש מבחן ביום שישי, היום יום ראשון, הוא מעריך שייקח לו יומיים ללמוד למבחן, אז מה עושה דני בד”כ? הולך לים… אחרי יומיים (ביום שלישי) הוא מתיישב ללמוד, לעיתים על 12 בלילה כי, אופס, צריך עוד קצת זמן – זה סינדרום הסטודנט, תופעה אנושית ידועה ומקובלת בפסיכולוגיה.
    עכשיו, בואו נדבר על יוסי מהסעיף הקודם: יוסי, כאמור, מעריך כפול ממה שהוא חושב, אהה, אז אם ליוסי יש 4 ימים לפיתוח שאמור לקחת יומיים לדעתו, מה יעשה יוסי? אמנם לא ילך לים, יעשה דברים אחרים מקבילים במקום העבודה כגון, קפה, ארוחות צהריים של שעתיים, יתכנת לעצמו תוכנה קטנה שצובעת את המסך בירוק ועוד…. מה לא יעשה יוסי ? את זה אתם כבר יודעים.

יש עוד סיבות רבות – המשך בפוסט הבא….
בינתיים, ולמי שמעניין אותו סינדרום הסטודנט : http://en.wikipedia.org/wiki/Student_syndrome

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

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

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

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

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

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