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

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

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

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


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

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

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

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

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

הערה: זו ההגדרה האישית שלי. כן, אני מודע להגדרות "הרשמיות", אך אני מוצא אותן פחות שימושיות. תודה.

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

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

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

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

במודל מפל המים מניחים שהתוכנה דומה לבניית מבנה מגורים: 

1. יש מגבלות קשיחות על סדר הפעולות (אי אפשר לבנות את הגג לפני היסודות).
2. טעויות הן יקרות מאוד לתיקון ("העמוד הזה צריך להיות פה?!") אך תכנון מדוקדק ובקרה בביצוע יכולים לצמצמם אותן.
3. יש חזרה רבה על פעולות ("40 דלתות, 600 חלונות, 40000 מרצפות") - כך שריכוז פעולות מייעל את הביצוע.

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

מתודולוגיות גמישות (כלומר Agile / Lean / Scrum) מניחות שבניית תוכנה היא דומה יותר לעיצוב חנות כלבו:

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

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

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

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

מקור: http://cafecrem.wordpress.com

מה המשמעות של סקראם בפועל?

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

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