מה באמת חשוב ב-SCRUM?

האם ניתן לנסות סקראם מבלי להתחייב? האם ניתן לאמץ רק את הדברים החשובים כדי להרוויח מבלי לאמץ את שיטת העבודה המלאה? ליאור בר-און מסביר מה באמת חשוב ב-SCRUM.

cc-by paddynapper

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

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

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

ותיקים ידעו לספר שגם על איזו 9000 או 9002 (ISO 9000 – תקינה לבקרה תהליכית) ידעו היועצים לספר ניסים ונפלאות. האימוץ הונע ע”י ההנהלה הבכירה ביותר ואינו היה קל. היה לא קל, התוצאות – מאכזבות משהו, יחסית להשקעה.

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

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

הלכנו והתייצענו עם יועצי הסקראם, אולי בכל זאת ניתן לאמץ את סקראם במשנה זהירות?

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

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

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

תהליך ה-SCRUM. וויקיפדיה

ספקות וחרטות

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

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

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

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

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

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

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

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

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

חוזרים למפל המים? cc-by NeilsPhotography

חוויה שנייה

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

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

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

אומרים שקבלת החלטה אנושית מתבצעת באחת משני אופנים:

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

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

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

עבודת צוות. cc-by LaMenta3

חדל קשקשת

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

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

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

לא… לא מדובר בהעצמת הצוות גם לא באומץ. לא ישיבות סטאנד-אפ (הבנתם כבר את דעתי עליהן…) ולא נראות (Visibility).

כל אלה טובים ומועילים – אך הם יכולים להיות רק סיבוב שיפורים שני ושלישי. להלן העקרונות המינימלייים שיתנו את מירב הערך מסקראם:

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

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

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

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

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

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

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

כמה מילים לסיום

זה מה שאתם צריכים: שני אנשים שיבינו Agile טוב והם יכולים לספק את התמורה הגבוהה ביותר מ-Agile – בהשקעה קטנה יחסית. המבנה הזה יכול לעבוד עם ראשי צוותים וללא SCRUM Masters, ללא burndown charts, ללא planning של הצוות ועוד.

אתם זקוקים רק לשני אנשים שיהיו במשחק ה-Agile:

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

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

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

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

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

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

הפוסט פורסם במקור בבלוג Software Archiblog

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

2 תגובות על "מה באמת חשוב ב-SCRUM?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
יותם
Guest

אחלה מאמר על AGILE .
יכול להיות אם היה שם גם פירוט קצת יותר על השיטה עצמה ולא רק על החוויה עצמה :)

ליאור בר-און
Guest

אתה יכול למצוא מבט על מקורות ועקרונות ה SCRUM בלינק הבא:
http://www.softwarearchiblog.com/2011/11/scrum-1.html

wpDiscuz

תגיות לכתבה: