סקראם אוף סקראמס? שלא יעבדו עליכם

ההתחלה

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

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

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

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

התחיל ספרינט ראשון:

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

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

אחרי שעברנו לפיצ’ר טימס

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

הדילמה

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

image רשת בטחון?

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

  שורה תחתונה

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

מקור התמונות :
* אמזון
* http://www.flickr.com/photos/kj-an/2299557485/

8 Responses to “סקראם אוף סקראמס? שלא יעבדו עליכם”

  1. נעמה says:

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

    שוב תודה!
    נעמה.

  2. רועי says:

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

  3. Alon says:

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

    • eladsof says:

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

  4. איליה says:

    כל זה נכון אבל יש מחסום אחד חזק : ורסטיליות של אנשי צוות. אם ה- feature team יהיה מורכב מאנשי low-level שכותבים ב-native, אנשי business logic שכותבים ב- Java ואנשי UI של FLEX (כמו במקרה שלנו) – האבטלה בתוך הצוות מובטחת !!! כי אנשי FLEX לא יכולים לעזור באזורים של low level והפוך והמשימות אף פעם לא מתפזרות בצורה אחידה בין השכבות…

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

    • eladsof says:

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

  5. חגית says:

    פוסט מצויין.

    הבעיה נובעת התלות הדוקה מדי בין הצוותים ולא מהמבנה שלהם.
    1. צריך בשלב התכנון של הספרינט שיהיה משהו עם ראיה מערכתית ויזהה את התלויות.
    2. כדי לנתרל את התלויות צריך לעבוד עם MOCK ו- STUB.
    בשלב ראשון הצוותים צריכים לתאם את הממשקים ביניהם. וכל צוות שמשתמשים בממשק שלו צריך לתת מימוש ריק לצוותים האחרים.
    כך אין המתנה בין הצוותים ומקטינים את רמת התלויות. בנוסף ניתן להשתמש ב- MOCK לשלב ה- Unit testing ובדיקות אוטומטיות כך שזה קוד שלא הולך לאיבוד.

  6. אבנר says:

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

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