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

בשנת 1975, נכתב הספר האלמותי “The Mythical Man-Month” ע”י בחור בשם פרדריך ברוקס (שכדרך אגב היה מנהל טכני בכיר בחברת יבמ, בימים בהם הייתה בחזית הטכנולוגיה). הספר זכה להערכה רבה בקהילת התוכנה, ונחשב עד היום כבעל מקום של כבוד בספריה של אנשי תוכנה “רציניים” [א].

הספר נגע בכמה נושאים, אבל סבב בעיקר מסביב ליעילות של כתיבת תוכנה / פרויקטים גדולים / ניהול פרויקטים.
הוא העלה בספר שלוש טענות חשובות:
  1. הטכניקות שלנו להערכות זמני פרויקטים הן לא מפותחות / יעילות מספיק. לעתים הן פשוט משקפות את השאיפה האנושית ש”יהיה בסדר”.
  2. הטכניקות להערכות זמנים כושלות בהבחנה בין תשומה (השקעת זמן) להתקדמות. אנו מודדים ומתמקדים בזמן שהושקע – ולא בהתקדמות בפועל. לעתים הן משקפות את השאיפה הנאיבית לרצות להמיר זמן בכח-אדם (אבל: “תשע נשים לא יכולות להוליד ילד בחודש אחד”)
  3. בגלל שאנו לא באמת בטוחים בהערכות שלנו – אנו לוקחים “באפרים”, ומזריקים חוסר-יעילות מובנה למערכת, כחלק מהתהליך. לחלופין – אנו לא מסוגלים להתגונן מול הנהלה שדורשת מאתנו “לקצר זמנים”, וכך נאלצים להתחייב לביצוע פרויקטים בזמני-חסר.
דמיינו שף המכין אומלט.
למען הסר ספק: אומלט = חביתה שמבושלת בצורה שלא תגיע “להזהבה” (כמעט rare), וכך תשמור על הטעם הטבעי של הביצה. לחלופין: תבשיל שיש בו מורכבות מסוימת [ב].
השף, ממש כמו המתכנת – כמהה לרצות את הלקוח.
כאשר השף מכין את האומלט – הלקוח מצפה שתגיע לשולחנו בתוך 2 דקות. עיכוב קטן כלשהו עלול לגרום לשף לא להספיק לסיים את האומלט בזמן המצופה. במקרה כזה, עומדות בפני הלקוח שתי אפשרויות: להמתין עוד, או לקבל ביצה לא מבושלת.
יש גם אופציה שלישית כמובן: להגדיל את הלהבה, ולספק בזמן המבוקש – אומלט שהוא לא הרבה יותר מ”חביתה מעט שרופה”.
לקוח של התוכנה – ניצב בפני ממש אותן ברירות.
מה השתנה מאז?
האם התקדמנו באמת, ב-40 השנים שעברו?
האם יש באפשרותנו היום לתאם בצורה טובה את ציפיות הלקוח, או האם אנו עדיין מתמודדים עם כל התחלואים הנ”ל?

רק עוד דקה…

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

  1. ישנן משימות צפויות, שכבר עשינו אותן כבר כמה פעמים (לרוב: “משימות copy-paste”) – אותן ניתן פחות או יותר לחזות בצורה טובה. משימוש שלא נעשו בדיוק כמותן לאחרונה – קשה הרבה יותר להעריך.
  2. יש שוני גדול בין משימה x במערכת קטנה, לביצוע משימה x במערכת גדולה. ביצוע משימה במערכת גדולה יותר – היא תובענית משמעותית יותר. (חשבו על פאזל, למשל: מה יותר קל? להוסיף עשרה חלקים לפאזל חצי-מורכב של 50 חלקים או לפאזל חצי-מורכב של 500 חלקים?)
  3. יש שוני גדול בין מורכבויות של סוג התוכנה. למשל: מערכות הפעלה נכתבת הרבה יותר לאט מקומייפלר, שכתב הרבה יותר לאט ממערכת עסקית / מערכת ווב.
  4. לרוב: המתכנים לא יצליחו להקדיש יותר מ 50% משעות העבודה לכתיבת קוד / טיפול בבאגים. מפתיע?!
    1. זמן בדיקות – הוא החלק שנוטים להעריך בצורה חסרה ביותר הוא בדיקת התוכנה ותיקון שגיאות. “יהיה בסדר!”.
  5. הערכות הזמנים שלנו – משתפרות ככל שאנו מתקרבים למועד תחילת המשימה הספציפית.
    בגרסה מעט אחרת: הערכות זמנים בתוך הפרויקט משתפרות ככל שהוא מתקרב לסופו.
    לסיכום: ככל שאנו מעריכים זמנים מאוחר יותר – אנו עושים זאת טוב יותר. (הערכות בדיעבד – הן הכי טובות!)
  6. את זה אני כותב מהזיכרון (לא מצאתי בספר. אולי זה מספר אחר?!): בשקלול של דיוק וצמצם – המתכנת הוא זה שעדיף שיעשה את ההערכה.
    למשל: אם מנהל מעריך “12 יום” – המפתח יקפיד בד”כ לעמוד בהערכה. אם נשאל את המתכנת עצמו, הוא יאמר “8 ימים” – וישיג את התוצאה הרצויה בתשעה – וזה מה שעדיף לפרוייקט.
    כל זה עוד לפני העובדה שמנהל יש אחד – והוא מהווה צוואר בקבוק, ומתכנתים יש יותר.
  7. אווירת לחץ, באופן דיי עקבי – פוגעת בפריון.
עוד תובנות מקובלות (אין לי רפרנס ברור) של ימנו:
  1. קביעת מסגרת זמן היא חשובה מאוד בכדי להתמקד במטרה ולא להתבזר [ג].
    כלומר: אם נותנים למפתחים “את כל הזמן שנדרש” בכדי להשיג תוצאה – הם יהיו משמעותית פחות יעילים מאשר כאשר יש להם מסגרת זמן, ידועה שעוד אנשים בוחנים אותה (רפרנס קרוב: חוק פרקינגסון). אפילו אם מסגרת הזמן הזו הוגדרה ע”י המתכנתים עצמם.
  2. חוק ה”90-90″ (הומריסטי) : תשעים אחוז מהקוד – ייכתב בתשעים אחוז מהזמן. יתר עשרת האחוזים מהקוד – ייכתבו ב 90 אחוז נוספים מהזמן. בקיצור: הערכת זמנים נועדה להערכת-חסר.

פרויקטי תוכנה בתקופתנו

האם פרויקטים כיום מצליחים יותר מהזמן בו כתב ברוקס את ספרו?

מקור: http://www.ambysoft.com/surveys/
ע”פ המקור הזה – ניתן אכן לראות שיפור לאורך השנים.
הנתונים שהציג ברוקס בספרו – היו בכלל מזעזעים: רק 2% מפרויקטי התוכנה של ממשלת ארה”ב הצליחו, 3% הצליחו לאחר שעשו בהם שינויים. כחצי מהם פשוט לא הועברו ללקוח.
למה ניתן לייחס את השיפור?
ע”פ גרסה אחת – ניתן לייחס אותה למהפיכת האג’ייל (נושא שכתבתי עליו הרבה בבלוג). למשל:
בעיה אחת בנתונים הללו – היא שרבים מהארגונים שמצהירים שהם עובדים ב”אג’ייל”, מבינים את המתודולוגיה בצורה חלקית בלבד, וקשה לייחס בצורה ברורה את השיפור למתודולוגיה.
הנתונים אומרים: “מי שמצהיר שהוא עושה אג’ייל – מצליח יותר”, אבל לא יותר מכך. אין הוכחה לסיבתיות.
גורם אחר שיש מייחסים אליו את השיפור, הוא התמסדות מקצוע “מנהלי הפרויקטים”, כדוגמת תואר ה PMP של ארגון PMI. זה הארגון שיצר את “Project Management Body of Knowledge”, והסמיך יותר מחצי מליון מנהלי פרויקטים ברחבי העולם.

תובנות של “עולם ה Enterprise”

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

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

הנה למשל תובנה נפוצה ראשונה: מודל שנקרא Cone Of Uncertainty.

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

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

מה המודל בעצם נותן לנו?
  • חוסר הודאות המשמעותי בהערכות זמנים של פרויקט – מונחות על השולחן, בצורה שקל יחסית לתקשר (יש לזה ערך).
  • יש מן “אומדן אצבע” לטווחי הטעות הממוצעים. מספר מדויק שניתן לעבוד איתו. המספר מדויק (precise), אבל לא תמיד נכון (accurate) – כמובן.
זווית אישית
במהלך שנותיי כאיש-תוכנה, נתקלתי בשאלה “כיצד להעריך זמנים של פרויקט תוכנה?” פעמים לא מעטות. השאלה הזו הטרידה והעסיקה אותנו לפעמים יותר מהשאלה “באיזה בסיס נתונים כדאי להשתמש” – ובאופן טבעי, “נשאבתי” גם לעסוק בה.אני זוכר שפעם שיתפתי משרד עם מנהל פרויקטים שבדיוק עבר קורס PMP לניהול פרויקט וקיבל את הספר על ה “Body of Knowledge משהו…”. לאחר קורס של שבוע-שבועיים היה לו חשמל בעיניים – והוא קרא בספר כמו שתלמיד ישיבה מתלהב קורא בגמרא (גילוי דעת: אני מדמיין כיצד זה נראה – מעולם לא חזיתי בזה באמת).

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

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

ספר מפורסם אחר הוא “Agile Estimation and Planning” שלא קראתי. את הידע שלי על Agile Estimation שאבתי ממקורות רבים שונים.

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

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

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

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

משפחת כלים: Expert Estimation

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

Bottom-Up – מומחים (מתכנתים/ראשי צוותים) מעריכים את כל המשימות בפרויקט, ואז מחברים את ההערכות הללו (עם באפרים ופאקטורים) לתמונה אחת. החיבור של ההערכות נעשה באקסל או ב”תוכנה לניהול פרויקטים” – קשה לעשות אותו בלי איזה כלי. וריאציות של טכניקה משתמשות במונח בשם WBS (קיצור של Work Breakdown Structure) – כאשר החלוקה היא למשימות, או RBS (קיצור של Resource Breakdown Structure) – כאשר הבסיס לחישוב הוא המשאבים (תחומי-מומחיות) להם זקוקים. כלומר: החישוב הוא לא כמה זמן המשימה תיקח, אלא לכמה אנשים נזדקק (פה 2 אנשי QA ושם עוד אחד – אז סה”כ שלושה).

Group Estimation – יש פה כמה טכניקות, המנסות לצמצם את הטעות של ההערכה הסובייקטיבית של מומחה יחיד.
טכניקה מקובלת אחת היא ה Planning Poker בה כל מתכנת נותן הערכה ומניח קלף עם הערכות הזמנים שלו (21 = 21 שעות, למשל) הפוך על השולחן. כולם הופכים ביחד את הקלפים וכשיש פערים משמעותיים – מתפתח דיון בו מסכימים על הערכה משותפת.
טכניקה נוספת היא Wideband Delphi שהיא מאוד דומה, אבל במקום להעריך ולעשות דיון פיצ’ר אחר פיצ’ר – דנים קודם בכל הפיצ’רים ומעלים מורכבויות אפשריות. אח”כ נותנים הערכות (בצורה אנונימית, למשל קובץ אקסל משותף) לכל הפיצ’רים ודנים באלו שהיה בהם פערי הערכות גדולים (מבלי לציין מי נתן איזו הערכה).ההערכות ממשפחת כלים זו הן יחסית מדויקת – אך זמן רב נגזל מושקע על מנת לקבל / לעדכן את ההערכות.

 
משפחת כלים – Analogy-Based-Estimation

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

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

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

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

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

למרבה ההפתעה הן מפורמלות ע”י מסמכים אקדמים וע”י כל מיני סטנדרטים בתעשייה (COSMIC הוא כמובן ISO/IEC 19761:2011, או IFPUG שהוא ISO/IEC 20926:2009, וכו’) – מה שעלול להעלות את השאלה כיצד גופים רציניים שכאלו לא פסלו אותם מכל-וכל. התשובה: א. כנראה שלעתים זה הכי-טוב שיש. ב. כנראה שנוח לגופים הללו להמשיך להתעסק בזה.
 
משפחת כלים: גם וגם…

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

אחסוך מכם את ההתנסות הזו – ואומר שיש כל מיני טכניקות שמנסות לעשות על מיני ממוצעים בין 2 סוגי הערכות ולהיות גם “יחסית מדויקות” וגם “לא יקרות”.
דמיינו אותן לרגע בעצמכם… – וזהו כנראה ה State Of The Art של עשרות שנות מחקר באקדמיה (סליחה על הביקורת הלא-מרומזת…, אולי קצת הגזמתי).

ההערכות בעולם ה Agile

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

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

הערה: יש גישה שכן מנסה לבצע הערכה גסה של הפרויקט בכללותו: מנסים להגדיר את כל ה backlog items “בערך באותו הגודל” וכך אם רוצים שכל ספרינט מתקדמים ב (נאמר) 5 פריטים, ובכל הרשימה יש עוד 30 פריטים – ניתן לומר בצורה גסה שעוד שישה ספרינטים יסתיים הפרויקט (סוג של Function Points estimation).

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



עיקרון: מנהלים רשימת פיצ’רים – מבלי להציב אותן על לוח-שנה
כותבים רשימה ארוכה של כל היכולות שאנו רוצים במוצר (product backlog) – וממיינים אותם ע”פ סדר חשיבות / סדר בניה נכון של הפרויקט.
בתחילת כל ספרינט (שבועיים עד ארבעה, בד”כ), שולפים משימות מה product backlog ומעריכים אותן. הן נכנסות לרשימה שנקראת ה Sprint Backlog. ממשיכים בתהליך הערכות הזמנים עד שיש לנו מספיק משימות מוערכות (נניח: 5 שבועות עבודה, אם אנו עובדים בספרינטים של 4 שבועות).
עכשיו מתרכזים בספרינט ומבצעים את המשימות.
תוך כדי הספרינט מרעננים את ה product backlog (לא נוגעים ב sprint backlog) בעקבות תובנות שאנו רוכשים במהלך הזמן.
מוטיבציה:
  • אנשים הם יעלים יותר כשיש להם מסגרת זמן (=ספרינט).
  • אנשים הם יעלים יותר כשיש להם מסגרת זמן ללא הפרעות (=ספרינט, כאשר לא משנים את ה sprint backlog במהלך הספרינט).
    • יש איזה איזון בין ה product backlog שהוא “דינאמי ומשתנה” (= למידה), לבין הספרינט שהוא קבוע (= יציבות).
  • לאפשר לבצע הערכות מאוחר ככל האפשר – על מנת שיהיו מדויקות ככל האפשר.
  • הבנה שגם הערכה כמה שבועות קדימה היא לא מדויקת (על כן – מעריכים מעט יותר משימות ממה שנדרש).
וריאציה: Planning Poker היא טכניקה שהכרתי קודם מעולם האג’ייל – ורק אח”כ למדתי שהיא טכניקה “קלאסית”.

Planning Poker בפעולה! בפרויקט אחד אפילו רכשנו את “הקלפים המקוריים של CRISP”. אם רוצים להעריך 31 שעות – מניחים על השולחן 3 קלפים (20+10+1). בחפיסת הקלפים שלנו – היו מספרים לא עגולים (7, 21, 44 אך ללא 10 או 5) – בכדי להזכיר לנו שהערכות הן לעולם לא מדויקות.

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

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

הרציונל: לבני-אדם הרבה יותר קל להעריך רצף אירועים פשוט (“יום מושלם”) על פני המציאות המורכבת (“יום מלא הפרעות”).

במהלך כל ספרינט לומדים מה הפער בין “היום המושלם” ל”יום המעשי”. הפער נובע מזמן שהמפתחים מקצים לדברים אחרים, כמו הטיות שלהם בהערכה. זה לא משנה. לאורך כמה ספרינטים ניתן ללמוד שצוות x מספיק בין 50% ל 60% מהמשימות שהעריך – ועל כן קובעים לו Velocity של 55%. כלומר: אם בספרינט יש 20 ימי עבודה – נעריך שבפועל יש לנו ספרינט של “11 ימים מושלמים”. נבצע כיול של המציאות של הצוות הזה. ה Velocity הוא לרוב אינדוודואלי לשילוב צוות+פרויקט, ויש ללמוד אותו כל פעם מחדש.

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

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

מוטיבציה:

  • מציאות – בואו לא “נשלה את עצמנו”.
  • הבנה שהערכה היא מלאכה לא מדויקת ולא-פשוטה, ועל כן נקל את המתכנים שלנו (= חשיבה ב”ימים מושלמים”, נקראים לעתים גם “Story Points”, הגבלת גודל התכולות אותן מעריכים).

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

מילת סיכום אישית

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

למשל:

  • פעמים רבות: התחייבנו על תכולה ולוחות זמנים חודשים קדימה (ולכן הוספנו “באפרים”). לא מיסדנו “חוזה אג’ילי” עם ההנהלה או הלקוח.
  • התעלמנו מהרעשים שיש למפתחים ביום העבודה – ובמשך שנה+ המופע בו צוותים לא סיימו 70% מתכולת הספרינט חזרה על עצמה כל ספרינט, וללא תיקון – כאמת עצובה שאין לה פתרון.
  • שימוש בבאפרים ואומדני “Function Points” שונים ברמת ההנהלה הזוטרה (במקום לבצע הערכות ע”י מפתחים).
  • מנהל פרויקטים שמרכיב תוכנית שבועיים קדימה: מה עושה בדיוק כל אדם בכל יום (ואז זו תוכנית שלמתכנת יש קשיים לזוז ממנה).
  • וכו’….

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

שיהיה בהצלחה!

——
[א] לא אנסה להגדיר זאת יותר מכך.[ב] מה ההבדל בין אומלט לחביתה? – “20 שקל” – ע”פ בדיחה נפוצה.

[ג] הערה: זה הקונצנזוס שאני מכיר, על אף מחקר שהוצג בספר Peopleware שהציג תוצאות שונות. בתכלס: מחקר בודד הוא לא משהו להסתמך עליו. עדיף בהרבה להסתמך על סדרה של מחקרים בלתי-תלויים המחזקים זה את זה.

אם יש לכם מנוי ל”הארץ” שווה לקרוא: http://goo.gl/82IwZb – צוות מדענים בינלאומי שבחן 100 מחקרים בפסיכולוגיה לא הצליח לשחזר את תוצאות 64% מהם: “הקורא הממוצע צריך ללמוד שאין להתייחס לשום מחקר בודד כאל המלה האחרונה”

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

על חנויות אפליקציה (App Stores)

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

  • האגדה על מכירה ויראלית (\”כל קונה יספר ל 3-4 חברים ותגיעו למיליון מכירות בחודש\”) – לא ממש עובדת.
  • איש מכירות ייקח מכם בערך 50$ למכירה, מה שישאיר אתכם עם 48$- לעסקה, במקרה הטוב.
  • פרסומות (שלטי חוצות, עיתונים, רדיו) יעלו עשרות אלפי דולרים, אולי יותר. ספק אם תוכלו לכסות את ההוצאות
  • נניח שכבר הייתה לכם שיחה אקראית ב\”סנטר\” ועניינתם מישהו באפליקציה, אבל הוא מפחד להתקין על המכשיר מן קובץ ipa[א] ממישהו שהוא לא ממש מכיר!

אם אפל הייתה מספקת רק SDK, ואומרת למפתחים: \”אתם יכולים להפיץ את האפליקציה איך שאתם רוצים! אנחנו לא מגבילים אתכם בכלל\” – ספק אם מישהו היום היה מתרגש מ\”דגם חדש של הטלפון ההוא שנקרא אייפון\”.

העסקה (נוסח אפל)

נניח שהיה בא מישהו ומציע לכם את העסקה הבאה:

  • אני אמכור עבורכם את האפליקציה. אם היא טובה, היא יכולה להימכר בעשרות אלפי, מאות אלפי או אולי מליוני עותקים.
  • אני אגבה מחיר צנוע: 30% מסכום המכירה. כלומר: 30 סנט לעסקה (לאפליקציה של דולר) – לא תמצאו עסקה טובה יותר!
  • הסיכון שלכם – מזערי. תשלום של 99$ לשנה בכדי להיכנס לעסקה.
  • אני אבצע את הפעולה הכספית מול הלקוח, בצורה מאובטחת, במדינות שונות, מול חברות אשראי שונות – אתם תקבלי ממני העברה בנקאית של 70% מסך המכירות (החלק שלכם) בסוף החודש.
  • אני מתווך מהימן ביותר – לקוחות מרגישים טוב מאוד לרכוש ממני אפליקציות.
  • אני מתווך מאוד ממוקד: מי שיראה פרסומת לאפליקציה שלכם, הוא רק לקוח פוטנציאלי רלוונטי (עם חומרה מתאימה). לא עוד \”פרסומת לטמפונים שמשודרת לגבר בן 60\”.
  • אם אתם רוצים לשווק את האפליקציה שלכם בחינם – אדרבא, אני אפילו לא אקח עמלת מכירה.

איך אפשר לסרב לכזו הצעה? 700,000 אפליקציות אמנם לא סירבו, יצרו +35 מיליארד הורדות ומפתחיהם גרפו לכיסם סכום של כ6.5 מיליארד דולר בארבע השנים האחרונות.

הצמיחה במכירות אפליקציות למובייל. מקור: http://kpcb.com/insights/2012-internet-trends-update
CAGR היא גדילה שנתית ממוצעת (במקרה זה אכן נראית כמו טיל).

האפ סטור, אגב, הופיע רק עם ה iPhone 3G – הדגם השני של האייפון, באמצע 2008. למשתמשי הדגם הראשון לא היה אפ-סטור. אם אתם תוהים \”כיצד זה ייתכן?\” – קראו את הפוסט הזה.

בעקבות ההצלחה המטאורית של האפ-סטור של אפל החל לצוץ חנויות מקבילות אצל המתחרים הישירים: Android Market (שאח\”כ הפך ל Google Play), חנות של נוקיה בשם Nokia Store (לשעבר Ovi), מייקרוסופט עם Windows Phone Store.

איך זה עובד?

אפ סטור היא לא רק \”חנות\”: זהו ערוץ שלם של הפצה, תשלומים ותמיכה.
על מנת להוסיף אפליקציה לאפ סטור של אפל, יש לעבור תהליך אישור לאפליקציה.
המפתח יכול לשחרר גרסה מוקדמת של האפליקציה בהפצת \”ad-hoc\” לצורך בדיקות תקינות / שימושיות / בדיקות-ביטא למספר מצומצם של מכשירים שהוא יודע את ה Unique Id שלהם. משתמשים של מכשירים אלו בלבד יכולים למצוא את האפליקציה ולהוריד אותה. על מנת לצאת ל\”תפוצה מלאה\” – על האפליקציה לקבל את האישור של אפל.

כשמפתח מגיש את האפליקציה שלו לבדיקה – עליו להגיש את ה source code עצמו. תיקון: רק ה binaries נארזים ועל פהם יש static analysis. מסמך NDA דו-כיווני מבטיח שאפל לא תחשוף את הקוד ומצד שני אסור על המפתח לחשוף את ההערות שהוא קיבל מאפל על הקוד שלו, או לפרסם את הסיבה בגינה אפל פסלה את האפליקציה. מסך ברזל קטן, אם תשאלו אותי.
תהליך האישור כולל כנראה כלי Static Analysis אוטומטיים ומרכיב מסוים של בדיקה אנושית. בעבר, התהליך ארך מספר שבועות – אולם מאז הוא התייעל וכיום הוא לוקח לרוב פחות משבוע. בסוף התהליך האפליקציה מאושרת ומשוחררת לאפ-סטור או נדחית עם פירוט הדחייה והצעות לתיקונים – למפתח האפליקציה.

על מה פוסלים אפליקציות? לאף אחד אסור לומר! בכל זאת התגנבו ידיעות על הסיבות הבאות:

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

האפ סטור של אפל בגרסתו הראשונה. מקור: techCrunch

שינוי פרדיגמה

מעבר להצלחה המיידית – נוצר כאן שינוי פרדיגמה משמעותי. רבים מייחסים את ה\”חדשנות\” של אפל לשימושיות הטובה של המכשירים שלה, למוצר הבסיס. אולי דווקא המוצר המקיף (\”Whole Product\”) שהוא המכשיר + האפ-סטור או חנות התוכן iTunes הם אלו שבהם טמונה ה\”חדשנות\” המשמעותית-יותר של חברת אפל.

מצד הלקוח: האפ-סטור מאפשר חווית קנייה פשוטה, מהירה ומהנה – ישר מהמכשיר. חוויה שגורמת למשתמש iDevice לקנות יותר.
מצד הספק: האפ-סטור הוביל לכך שאפשר להרוויח מאפליקציות קטנות מאוד שמפותחות ע\”י מפתחים בודדים (איך בדיוק מרוויחים – אולי בפוסט המשך). המתווכים הקלאסיים – נעלמו, ואיתם הוצאות רבות הקשורות להפצה. אפליקציות קטנות => פשטות שימוש => חוויות שימוש טובה יותר של ה Whole Product. אפל טיפלה בכל שרשרת הערך של המוצרים שלה, בלי להשאיר אף חלק ל\”יד המקרה\”. הכל הרמוני, seamless, ומוכן לשימוש. דוגמאות נוספות:

  • אפל איננה ספקית תוכן, אך על מנת שהמוצר שהיא מוכרת (חומרה/תוכנה) יצליח: היא נכנסה לביזנס, יצרה את iTunes, ועשתה את הבלתי-יאמן כשהחתימה חברות מוסיקה גדולות על הסכמים למכירת שירים ב 1$ (עוד בימי ה iPod). חברה אחרת יכלה בקלות \”לחתום על כמה הסכמים עם שותפים\” ולקוות לטוב.
  • iCloud שירות האכסון / סנכרון בין מכשירים. למי שיש יותר ממכשיר אחד קל מאוד להבין מדוע זה \”נדרש\”.

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

  • Chrome Store – עבור Plugins לדפדפן הפופולרי.
  • Mac App Store ו Windows 8 Store – אפ סטור למחשבים שולחניים. אם הקונספט עובד היטב למכשירי מובייל, למה שלא יעבוד גם למחשבים שולחניים?
  • App Stores אלטרנטיביים. בעולם האנדרואיד, היכן שיש חופש ופחות שליטה מרכזית, צצו כ +20 AppStores שונים כמו ה Amazon App Store למכשירי קינדל (תוכן הוא הביזנס העיקרי של אמאזון), אפאיה, LG World או Samsung Apps. יש גם אלטרנטיבות \”מחתרתיות\” לעולם ה iOS, \”מחתרתיות\” כי בסוף הם מפנות לאפ סטור של אפל להורדה.
  • App Store ל HTML5 apps, כמו זו של מוזילה או OpenAppMarket.
  • ספקיות הסלולר, בפעם המי-יודע כמה, ובאיחור שגרתי מנסות לחזור למרכז הבמה עם אפ-סטור משלהן: Vodafone, Horizon ואחרים.
  • App Store קהילתי מסביב לתחום עיסוק מסויים כמו ה SAP Store, לאפליקציות עסקיות (בעיקר סביב מערכות סאפ).
  • App Store ארגוני המשמש לתוך הארגון.

המעניין מכולם, עבורי, הוא ה Enterprise App Stores, בהם מנסים ארגונים להפיץ תוכנות שהארגון קנה בין העובדים. לארגונים יש כמה נקודות כאב (pain points) ייחודיות:

  1. הארגון קנה \”רשיון רוחבי לכל העובדים\” בסכום גבוה – אבל עובדים רבים לא מודעים לכך ולא משתמשים בתוכנה.
  2. תהליך הרכש בארגון, אפילו לסכומים קטנים, הוא מייגע. מה שהייתי יכול לקנות online בחמש דקות עם כרטיס אשראי עלול לקחת חודש או יותר, כשהוא עובר במערכת הרכש של ארגון גדול.
  3. ניהול רשיונות (מבחינה חוקית + כספית) הוא אתגר לארגון, ש App Store הוא נקודת כניסה נוחה שיכולה לסייע מאוד.
ספקי תוכנה ארגונית כבר מספקים בימים אלו \”App Store ארגוני\” ואפילו גוגל הכריזה על הפצה של Play גם כחנות ארגונית סגורה (SaaS).
אין כמובן מניעה מאפליקציה להפיץ עצמה במספר רב של App Stores, כל פעם תחת חוזה קצת אחר. גם אם אפליקציה תופץ ב 20 App Stores שונים – זה עדיין שבריר ממספר המפיצים / מפרסמים שחברות היו צריכות לנהל עימן קשר עד לא מזמן, בכדי להפיץ תוכנה.

סיכום

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

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

שיהיה בהצלחה!

[א] IPhone Application = ipa

על תפקיד ה Product Owner והשפעתו על הארכיטקטורה

בסקראם, ה Product Owner (בקיצור PO) נדרש למלא 2 תפקידים שונים בתכלית:
  • מצד אחד: לחבוש את “מגבעת המרחבים” ולחלום על חזון רחוק, שכרגע אולי ואינו ברור או אפשרי.
  • מצד שני: לחבוש את “קסדת בוב הבנאי” ולהוביל בנייה הגיונית של מוצר מעשי.

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

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

ממש פיצול אישיות!

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

שייך לסדרה: אג’ייל – מתודולוגיות פיתוח רזות

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

בעוד ה PO חובש את מגבעת המרחבים, התמונה הראשונה המתגלה לעיניו על המוצר היא משהו כזה:

אקסל כ”מוצר עוצמתי ורב יכולות עבור המשתמש המקצועי”. מקור: http://nizagreen.blogspot.co.il/2012/01/partes-de-excel.html

או אולי משהו כזה… (עבור ה PO בעל הנטיות השיווקיות):

“אקסל מוכן להשקה”. מקור: מייקרוסופט

“Begin with the end in mind” היא אחת העצות שנותנים למנהלי מוצר בכדי שיהיו יעילים.

תחת הכובע של בוב הבנאי, התמונה הראשונה שעל ה PO לראות צריכה להיות משהו כזה:

היכולות הבסיסיות ביותר באקסל, מפורטות ומדויקות. מקור: וויקיפדיה.

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

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

מה יקרה אם יהיה לנו ״איש חזון ושיווק״ טוב, שלא יחבוש את ״קסדת בוב-הבנאי״?

בואו ניקח לדוגמה סיפור בו אנו רוצים להוסיף למוצר שלנו יכולת חדשה: בדיקת איות.
ה PBIs[ב] של היכולת, כפי שהוגדרו על ידי ה׳ PO, נראים כך:

  1. כמשתמש, אני רצה שבדיקת האיות תהיה מהירה, תוך כדי הקלדה (= שיפורי ביצועים)
  2. כמשתמש, אני רוצה שיוצגו לי כתיקון לשגיאת הכתיב, קודם מילים נפוצות יותר בשפה
  3. כמשתמש, אני רוצה שיוצגו לי הצעות לתיקון ע”פ מילים שמופיעות במסמך
  4. כמשתמש שמגדיר את העדפותיו – אני רוצה לקבוע אם בדיקת האיות תהיה תוך כדי הקלדה וכמה משאבים יוקצו לה
  5. כמשתמש שמגדיר את העדפותיו – אני רוצה לקבוע אילו מילונים יהיו בשימוש
  6. כמשתמש שמגדיר את העדפותיו – אני רוצה לקבוע חוקים ספציפיים לבדיקת האיות בשפה נתונה
  7. כמשתמש בגיליון – אני רוצה לראות סימון אדום כאשר יש לי שגיאת כתיב
  8. כמשתמש בגיליון – אני רוצה לקבל המלצות לתיקון
  9. כמשתמש בגיליון – אני רוצה להיות מסוגל להחליט שמילה שנתפסה כשגיאה היא תקינה – ולהוסיף אותה למילון

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

 
שאלה: בהנחה שיש לצוות יכולת לבצע את כל 9 ה PBIs בוודאות, האם יש משמעות לסדר של ה PBI שהוא מגיש?
תשובה: בהחלט כן! לסדר בו יגיש ה PO את ה PBIs לצוות יש השפעה ניכרת על התוצאה הסופית מבחינת ארכיטקטורה ואיכות הקוד.

אנו נוגעים כעת במרכז העצבים של מתודולוגיות ה Lean / Agile.

על קביעת העדיפויות

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

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

זכרו את הקונטקסט: בסקראם, כולם נמצאים בריצה מספרינט לספרינט. ברוב הפעמים, לא יהיו הגדרות מדויקות של PBIs, ולא יהיו UI Mockups מוכנים אלא אם זה PBI שצפוי להתממש בספרינט הקרוב. כולם עובדים “Just-In-Time”.

הנה תוצאה אפשרית וסבירה למצב הנ”ל:

  • המפתחים יפתחו מנגנון Cache. כי cache = ביצועים.
  • כיוון שהם לא יודעים מה תהיה התנהגות הריצה של מנוע בדיקת האיות, ואלו תבניות התנהגות הוא יכתיב ל Cache – הם יוכלו לכתוב רק Cache “גנרי”. כזה שעושה הכל “בסדר”, אך לא מצטיין באף תסריט ספציפי.
  • סביר אפילו, שעבור הרגשת הביטחון שה Cache בסדר (“!Done means Done”) יפתחו אותו קצת אקסטרה – רק כדי “להרגיש בטוחים”, וללא קשר לידע קונקרטי.
  • אם נקביל תהליך זה להתאמת מבנה-נתונים לבעיה, אזי על צוות הפיתוח לבחור מבנה נתונים לבעיה שלא הוגדרה. כיצד בוחרים מבנה נתונים כזה? מחפשים כנראה הרבה (O(1 – אולי HashTable שמאונדקס כפול ברשימה-משורשרת. ברור שזה מבנה נתונים שאינו “גרוע” למקרים רבים – אך כנראה שגם לא אופטימלי לכמעט אף מקרה.

מה לא היה בסדר? ה PO שם במקום הראשון את הדבר שמרקטיאלית הוא החשוב ביותר – זה נשמע הדבר נכון לעשות.
ה PO גם לא יכול היה לספק Functional Spec מפורט להכל מראש – זה לא Waterfall.

כלומר: ה PO יכול “לעשות הכל ע“פ הספר” – ועדיין להגיע לתוצאה לא-טובה.

“Amplify Learning / Amplify Feedback”

אם נחזור לעקרונות ה Lean, ניזכר שאחד מעקרונות היסוד הוא “הגבר את הלמידה” – זהו עקרון מרכזי בעולם האג’ייל[ג].

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

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

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

חתרו למשהו מינימלי ועובד, ורק לאחר שהוא עובד – חזרו ועבו (מלשון עיבוי) את הפ’יצר.

מי שבא מרקע של מדעי המחשב בוודאי זוכר את האלגוריתמים לסריקת גרף: BFS ו DFS. בכדי “לגדל מערכת” באג’ייל אנו נרצה בבירור לעשות DFS (להגיע ל”משהו עובד” מהר ככל האפשר) ולא BFS (לעבוד שכבה שכבה ולסיים עם כולן בו-זמנית).

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

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

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


הגדירו Maximum Learning PBIs – ויישמו אותם ראשונים
ה PBIs מהם נלמד הכי הרבה הם לרוב כאלו שכוללים UI.

מדוע? “תמונה אחת שווה אלף מילים”. כבני אדם, אנו יכולים להפיק מהגדרות ה UI הבנה טובה יותר של הדרישה מאשר מהתיאור המילולי שלה. אפילו ה PO בעצמו יתגבש טוב יותר – אם הוא יעבוד עם איש ה UX בשלב מוקדם להגדיר את ה User Interaction. בעיות רבות עלולות לצוף באופן זה בשלב מוקדם.
במערכות ללא UI, כגון שרתים – יהיו אלו הנתונים. “נתונים לפני” ו “נתונים אחרי” או “מה נכנס” מול “מה יצא”. התבוננות בנתונים ראליים, בעלי משמעות – שווה יותר מעשרות מצגות ופגישות הדנות ב”כוונות” וב”המוצר – לאן?”. פשוט אספו נתונים ראליים שאתם רוצים שהמערכת שלכם תעבד והציגו אותם.ב”מפל המים” לימדו אותנו שאי אפשר לכתוב UI לפני שהשירותים שמאחוריו כבר כתובים ועובדים. בואו נתקן אמירה זו: לא ניתן לסיים לכתוב את ה UI לפני שסיימנו לכתוב את השירותים שמאחוריו, אבל אפשר להתחיל.
UI שבו רוב הכפתורים הם disabled – הוא התחלה סבירה על מנת להגביר את הלמידה. כיתבו קוד שמציג התנהגויות מרכזיות שהוגדרו מראש, אפילו בצורה hardcoded, ועליתם מדרגה ברמת הלמידה שניתן להשיג בשלב מוקדם זה.

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

הערה: כל אלה נכונים, באין UI, גם לנתונים איכותיים.

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

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

תרגיל מחשבתי: גישה כנגד גישה
בתרגיל המחשבתי שמוצג בתמונות הבאות, ניתן לראות התפתחות אפשרית של מוצר בשני מקרים:

  1. אנו עובדים תחת הנחות מסורתיות של “מפל המים” / BFS: קודם נסיים את התשתיות – ואז נגיע בסוף ל UI.
  2. חתירה, מרבית, ל End 2 End flow – שגם מתחילה מהUI.
התרגיל הוא דמיוני, אך אני מרגיש שהוא מתאר יפה את הדינמיקה המציאותית.
הוא ממחיש כיצד עבודה ממוקדת תוצאה-מוקדמת יכולה למנוע מאיתנו להשקיע בכתיבת קוד שלא יהיה לבסוף בשימוש.
יש גם יתרון מובנה בלסיים “Flow” מוקדם יותר: יש זמן יותר לבחון את ה Flow, לתקן בו בעיות או להציע בו שיפורים.את ההשפעה החיובית של גישה זו על הארכיטקטורה – התרגיל המחשבתי הזה לא מפגין. תאלצו לנסות בעצמכם את שתי הגישות בכדי להיווכח בהבדל.

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

לחצו על התמונות להגדלה.

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

—-

[ב] Product Backlog Item – יחידת עבודה לספרינט עבור הצוות או חלקים ממנו.

[ג] תוכלו לקרוא על עקרון זה ואחרים בפוסט “קיצור תולדות הסקראם – חלק 2” בסדרה זו.

סדרה: Agile (מתודולוגיות פיתוח רזות)

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

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

– כל אלו נחשבו חוסר-הבנה או טירוף, בימים שאני התחלתי לפתח. בסך הכל לפני עשור.

נתקלתי ברעיונות האג’ייל לראשונה בשנת 2002, עוד בתקופת האוניברסיטה, בעת שמנחה הפרויקט שלנו דרש מאיתנו לעבוד ב Extreme Programming – קיצוני למדי לאותה התקופה, אולי בכלל. רעיונות אלו טלטלו אותי והשפיעו עלי עמוקות.

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

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

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

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

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

קיצור תולדות הסקראם – חלק ב’
בעוד חלק א’ הוא יותר סיפורי – חלק ב’ מתמקד בעקרונות עצמם, כפי שהושמו ע”י טויוטה וה TPS.
עקרונות אלו נקראם Lean או Lean Manufacturing – סקראם הוא רק תרגום שלהם, לעולם התוכנה.

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

סקראם – על חודם של שני אנשים
בואו נדבר ת’כלס: סקראם כולל הרבה רעיונות / כללים, אבל מה באמת הכי חשוב?
אם אנו רוצים להתמקד ברעיון אחד או שניים – מה הם צריכים להיות?

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

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

מה הקטע של… סקראם? (ת’כלס)

בוודאי שמעתם לא מעט דיבורים על סקראם (Scrum).

  • אם עוד לא התנסתם בסקראם – ייתכן מאוד והדיבורים הללו נשמעים לא-ברורים או מופרכים.
  • אם כבר התנסתם בסקראם – ייתכן ויש פער בין הדיבורים למה שאתם מכירים בפועל.

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

שייך לסדרה: אג’ייל – מתודולוגיות פיתוח רזות

רקע
סקראם היא מתודולוגית פיתוח תוכנה המיישמת עקרונות של ייצור רזה (Lean) בעולם התוכנה (מה שנקרא אג’ייל Agile).
אם השמות מבלבלים, אתם יכולים להניח כרגע ש Agile = Lean = Scrum.

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

מתודולוגית סקראם עוסקת ב:

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

סקראם! (בספורט)

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

  • סקראם או שיטות אג’יליות אחרות (XP, Kanban)
  • כל השאר, שנקרא לו בפשט(נ)ות “מפל המים” (Waterfall).

מפל המים הוא מודל אקדמי, משנות ה-70, המתאר כיצד יש לפתח תוכנה, שהושפע כנראה מהתעשייה המסורתית.

במודל מפל המים מניחים שהתוכנה דומה לבניית מבנה מגורים:
  1. יש מגבלות קשיחות על סדר הפעולות (אי אפשר לבנות את הגג לפני היסודות).
  2. טעויות הן יקרות מאוד לתיקון (“העמוד הזה צריך להיות פה?!”) אך תכנון מדוקדק ובקרה בביצוע יכולים לצמצמם אותן.
  3. יש חזרה רבה על פעולות (“40 דלתות, 600 חלונות, 40000 מרצפות”) – כך שריכוז פעולות מייעל את הביצוע.
במפל המים קודם אוספים דרישות עבור כל המוצר, אח”כ מבצעים תכנון כללי (“ארכיטקטורה”) של כל המוצר, אח”כ תכנון פרטני (“Design”) של כל חלקי המוצר, אח”כ כותבים את הקוד, מבצעים אינטגרציה, בודקים היטב את כל המערכת, מבצעים תיקונים ומשחררים.
מתודולוגיות גמישות (כלומר Agile / Lean / Scrum) מניחות שבניית תוכנה היא דומה יותר לעיצוב חנות כלבו:
  1. אין לרוב מגבלות קשיחות על סדר הפעולות (אפשר לסדר את מחלקת כלי הבית לפני או אחרי מחלקת ההנעלה).
  2. יש מגוון רחב מאוד של פריטים (“פיצ’רים”) – אדם אחד יתקשה לשלוט בכל הפרטים.
  3. תכנון מפורט ונוקשה מראש עלול להחטיא את המטרה. כדאי להתחיל בהדרגה, ללמוד מטעויות ולשפר את ארגון החנות עם הזמן.
  4. ריכוז פעולות יכול לייעל את העבודה, אך בצורה מוגבלת.
כמובן שהנחות אלו, שרבים יסכימו שהן מתארות את עולם התוכנה בצורה טובה יותר, מובילות למסקנות שונות לחלוטין.
כשמישהו בעל ניסיון ב”צורת עבודה רגילה” (קרי “מפל המים”) נחשף לסקראם לראשונה, הוא לרוב נוטה לחפש ישר את הסדר המוכר.
אם נדמה לכם שסקראם היא “רק עבודה במחזורים קצרים + שמות תפקידים קצת שונים” – אזי אתם בחברה טובה: רוב האנשים שנחשפים לסקראם לראשונה לא מבינים את מהות הגישה השונה. זה לוקח זמן.
מה המשמעות של סקראם בפועל?
במבט של מי שרגיל ל”מפל המים”, ניתן לומר שההבדלים העיקריים בדרך העבודה הסקראמית הם:

  • בסקראם אכן עובדים במחזורים (נקראים ״ספרינטים״) קצרים: שבועיים עד חמישה, כאשר בכל מחזור יש עוד טיפה פונקציונליות עובדת: “הוספת מדף מתנות במחלקת מתוקים” או “שיפור התצוגה של נעלי טיפוס הרים”, בהקבלה למטפורת ההכלבו.
    במפל המים המשימות כנראה היו “מדפים (כל הכלבו)”, “תאורה (כל הכלבו)” או “תצוגות מבצע (כל הכלבו)”. אם הערכות הזמנים היו שגויות, היה יכול להגמר הזמן המתוכנן לביצוע הפרוייקט מבלי שיש מוצרים על המדפים.
  • בניגוד למפל המים בו יש מסמכים מפורטים כמו MRD, PRD ו Functional Spec, בסקראם מחליפים את המסמכים ברשימות מתומצתות (״backlog״) והרבה פגישות / עבודה פנים מול פנים של האנשים המעורבים. התקשורת היא ישירה, תדירה ודינמית – ולא באמצעות ניירת.
    סקראם מגדיר מספר גדול  של ישיבות שיש לקיים, כגון “Daily Stand-up”, “Sprint Planning”, יש גם “Sprint Sprint Demo”, “Retrospective” ועוד.
  • בסקראם יש דגש על השגת יעילות (effectiveness): “כמה פ׳יצרים מועילים נוספו למערכת בפרק-זמן נתון?”.
    הדרך היעילה ביותר להשיג זאת היא להפעיל שיטות לזיהוי פ׳יצרים שלא באמת זקוקים להם – ולבטלם. בסה״כ המפתחים יכתבו פחות שורות קוד, אך הם יכתבו יותר שורות קוד שלקוחות באמת משתמשים בהן.
  • סקראם מסירה סמכויות ואחריויות מהמנהלים ומטילה אותם על אנשי הצוות. אין ראש צוות שמרכז את העבודה, המעקב אחריה וההתחייבות ללקוחות. הצוות מנהל את אלה בעזרת תהליך מובנה שאמור לאפשר לצוות לעשות זאת ללא ״דמות מרכזית שלוקחת את הדברים לידיים״
  • הצוותים בסקראם הם “צוותי פ’יצר” בניגוד ל”צוותי רכיב” של מפל-המים.
    במפל המים היו צוותים כגון “צוות בסיס נתונים”, “צוות UI” וצוות “לוגיקה” – צוותים הממופים לרכיבי המערכת. אם צוות ה”UI” קורס מעומס – הצוותים האחרים לא מסוגלים לעזור לו – יש להם את ההתמחויות והאחריות שלהם.
  • בסקראם כל צוות אמור להיות מסוגל לבצע “כל משימה”. בצוות יש כישורים כגון בסיס נתונים, UI ולוגיקה, QA, תיעוד – כל מה שצריך על מנת לסיים משימה “מקצה לקצה”.
    הנוהג הוא להימנע מלקרוא לצוות על שם רכיב במערכת (“צוות DB”), אלא להשתמש בשנות ניטרליים כמו צוותים “1,2,3” או צוותים “אדום, כחול, וירוק”.
  • בסוף כל ספרינט, יש פגישה יזומה של “הפקת לקחים” על מנת לאפשר שיפורים בתהליך, שללא תשומת הלב הנוספת, לא היו מתקיימים.
אג’ייל היא לא רק סט של חוקים, כי אם פילוסופיה. פילוסופיה שניתן לקחת מחוץ לעולם התוכנה (משם היא בעצם הגיעה). הנה דוגמאות:
  • דרך חשיבה / עבודה בולטת בסקראם היא Prioritization and Time Boxing. כל פעילות (ישיבה, workshop, משימה) יש לתחום בזמן ולהתחיל מהנושא החשוב ביותר לנושא החשוב פחות. כשהזמן ייגמר, יהיו לנו כמה נושאים חשובים – שסיימנו, וכמה נושאים פחות חשובים – שכנראה נוותר עליהם. זאת במקום הרבה נושאים לא גמורים או השקעת זמן בלתי-נשלטת.
  • בניגוד לשיטת מפל המים, בה משתדלים מאוד לכתוב קוד “פעם אחת, ולא לגעת בו יותר”, כשכותבים קוד בסקראם כותבים בדיוק את מה שצריך ולא טיפה יותר. סביר למדי שנחזור לקוד הזה ונבצע בו שינויים / תוספות עוד כמה פעמים. בדיקות-יחידה ו CI הם הכלים שמאפשרים לגישה כזו להיות אפשרית.
הפילוסופיה של מפל המים (“כותבים קוד פעם אחת ולא נוגעים בו יותר”) היא גם הגיונית, ושימושית במקרים מסוימים גם בעת עבודה בסקראם. אני בטוח שיישום מפל המים היה שיפור משמעותי על חוסר-השיטה שקדם לה.

הנה סרטון מצחיק (אבל נכון) המסביר מהו תפקידו של ה Scrum Master

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

לסקראם יש גם כמה בעיות:

  • שוק גדול של הסמכות ויועצים – שיש להם אינטרס קודם ל”מתודולוגיית הסקראם” מאשר להצלחת הארגון שלכם.
  • כמה אלמנטים (כמו “צוות שמנהל את עצמו), פשוט לא עובדים היטב / קשים מאוד ליישום. סקראם איננה קהילה דינמית ובמשך השנים אני רואה מעט הצעות חדשות מהותית להתמודדות עם הבעיות. בעוד סקראם חרתה על דגלה את עקרונות ה”למידה ושיפור תמידי”, קהילת הסקראם היא דיי מקובעת ושינויים ו”גמישות” באימוץ הסקראם הם לרוב לא-באים-בחשבון. אירוני משהו.
  • סקראם מכילה חוקים רבים, אך משאירה גם שאלות מהותיות פתוחות: כיצד מפתחים אמורים להתמודד עם בעיות שנובעות מ”צוותי פי’צר” או “עבודה ביחידות קטנות”. מתודולוגיות אחרות, בעיקר Extreme Programming ו Lean Startup מכסות רבים מהחורים שלא נפתרו ע”י סקראם – ונפוץ למדי למצוא שילוב שלהן בתוך הסקראם.
    “חסידי הסקראם” נוהגים לדקלם ש “Scrum is a Framework” ועל הארגון להשלים בעצמו את החסר. עדיף היה לו היו מספקים פתרונות (אפילו בדמות XP ו LS).
  • סקראם מתאים לאופי מסויים של אנשים. מקובל מאוד לאמץ סקראם במלואו, הכל או לא-כלום. הגדרות תפקיד כגון “סקראם מאסטר” או “Product Owner” הן מוגדרות היטב ואין כמעט דיון על “וריאציות אפשריות” שלהן. ארגון שגייס אנשים ע”פ פרופיל X – יתקשה לרוב לומר לאנשים יום בהיר אחד “עכשיו עושים סקראם, אתם צריכים להיות Y”. כשהוא אומר להם את זה (ראיתי את זה קורה) – יש טלטלה ארגונית גדולה.
אמרנו כבר שאם ניישם סקראם, לא נכון לצפות שהתוצאה תהיה “כמו בספרים”.
שאלת השאלות היא אם כן:

האם “סקראם ממוצע” עדיף על “מפל-המים ממוצע”?

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

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

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

בואו נביט בחלון החיפוש של כרום גרסה 22. מוצר בן 4 שנים שנמצא בפיתוח אינטנסיבי:

האם זה לא היישום הפשוט ביותר? זה שמתאים לספרינט ראשון של מימוש הפ’יצר?

לא. אפשר להוריד את האינדקס (“1 מתוך 11”). אפשר גם לוותר על הרקע האדום, שמוצג במידה והחיפוש לא מצא כלום. שניהם לא הכרחיים על מנת לסגור את פונקציונליות החיפוש הבסיסית ביותר.
שני אלו יכולים להכלל בדרישה מאוחרת יותר, שתקרה ספרינט מאוחר יותר, גרסה מאוחרת יותר, או אפילו לעולם-לא.
אם הצוות חושש שגם זה יותר מדי- אפשר לחפור ולצמצם עוד: ויתור על הפינות מעוגלות ב UI, לכתוב קוד נאיבי שלא יעיל  מבחינת ביצועים, לוותר על הכפתורים (למעלה / למטה) ולבצע חיפוש עבור ערך ראשון בלבד. כל אלו אולי חשובים ללקוח, אך ניתן לעשות אותם בספרינט הבא. זכרו: מה שאתם רוצים הוא To Nibble [זהירות! וידאו].

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

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

עלינו לקבל בקשות שמנהל המוצר ביקש ולהשתדל לעשות את המינימום שעליו סוכם. אם זה לא יהיה מספיק – אין מה לדאוג: מנהל המוצר יבין זו במהרה (יש תצוגת-יכולות כל כמה שבועות) ויגדיר PBI נוסף להשלמת הפערים.

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

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

שיהיה בהצלחה!

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

[ב] תודה לאנונימי על החידוד.

http://en.wikipedia.org/wiki/Lean_Startup