.Scrum Forrest, scrum

שלום רב,

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

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

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

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

השיטה..

הרעיון הוא להכשיר קבוצה של מפתחים ובודקים, אשר תהיה אחראית על תכנון, פיתוח ובדיקת הרכיבים החדשים (או שינוי ותיקון הקיימים) של המערכת. מול הקבוצה עומד מנהל המוצר (Product Owner) הרלוונטי אשר אחראי על הגדרת הדרישות ואישור התוצרים המוגמרים לאחר ביצוע. ה Scrum Master הוא אותו גורם שאחראי על הטמעת השיטה ועל ההתמדה בה וגם על הסרת מכשולים מדרכו של הצוות אל עבר יעדיו. 
Feature נקרא User Story וניתן להבין מהשם כמה השיטה היא User Oriented. ה Product Backlog הוא הסל הוירטואלי, בו מאוחסנים כל ה User Stories אשר בקנה ופוטנציאליים להיכנס אל אחד ה Sprints הבאים.
מה זה Sprint?
הפיתוח יתקיים ב Cycles קצרים (Sprints) באופן יחסי (בין מספר ימים למספר שבועות) כך שבסיום כל Sprint יעלו לאויר אותם Features אשר הוגדרו ותוכננו מראש לאותו Sprint (הם נכנסו בעצם ל Sprint Backlog) בפגישת ה Planning אשר מתקיימת לפני תחילת ה Sprint.
על הצוות להעריך את המאמץ הנדרש עבור כל Feature ברמת דיוק של בין מספר שעות עד מספר בודד של ימים.
בסיום כל Sprint תתקיים פגישת Retrospective שהיא מעין פגישת הפקת לקחים של ה Sprint האחרון. 

היתרונות:

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

באופן כללי ה Sprint נותן לנו את היכולת להיות גמישים לשינויים. כאשר דרישה משתנה לאחר הגדרתה, הרבה יותר קל לנו לשנות את תכנון האב כאשר הראייה היא תכנון ל short run.

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

1. הטמעה. על מנת שנוכל לרוץ עם השיטה החדשה בצורה כמה שיותר משוייפת וחלקה, צריך לדאוג לכך שחברי הצוות יכירו היטב את עקרונותיה. על נושא זה אחראי בין היתר ה scrum master. נקיטת פעולות העשרה והכוונה בנושא ה scrum יעזרו בהמשך לחיבור הצוות לנהלים החדשים.
2. רוח גבית. אוקיי, חשבנו, שקלנו ובחרנו לעבור ל scrum, אבל מה אם הארגון/לקוח/כל בעל עניין שקשור אליי לא כל כך מתלהב מהרעיון. במצבים פוטנציאלים כאלה, שווה לנהל מספר פגישות מקדימות עם בעלי העניין הרלוונטים, להסביר את המוטיבציה והיעדים וכל זאת על מנת שלא יערימו קשיים בהמשך ויטילו ספקות בנושא. עדיף לצאת לדרך חדשה עם כל הכוחות כולם.
3. שיתוף פעולה של הצוות (בין חבריו ומול השיטה). שיטה חדשה, גישה שונה, הרבה יותר אנרגיות נדרשות, הרבה יותר שקיפות נוצרת, תאריך היעד לסיום ה Sprint כל מספר שבועות מגיע כמו שעון שוויצרי, ותכל'ס? למי נהיה קשה יותר ולמי נהיה קל יותר? רמז, לצוות נהיה קשה יותר, אינטנסיבי יותר וככל הנראה, הולך להישאר לו הרבה פחות זמן ל YNET מבעבר. אז איך משכנעים את הצוות שזה דווקא טוב לו? באמת לא תמיד קל, אבל תנו לי לתקוף את הנושא מזוית אחרת ולקחת אתכם לדוגמא של צוות אג'ילי מספרד: ברצלונה (ההיא) של פפ גווארדיולה. כשפפ הגיע הוא עשה מהלך גאוני - בנה תלכיד של שחקנים מרובי כשרון ואינטיליגנטים ונטולי אגו, הוא חיפש את ה typecast הזה בכל מקום על כדור הארץ, מכיוון שהאמין שזהו הבסיס להטמעת כל שיטה חדשה ויישומה ב long run. אז לאחר שסיים עם ניקוי האורוות, הוא פנה להטמעת שיטתו (טיקי-טאקה כמובן) עם המון סבלנות. ולמרות שעדיין מהנדס תוכנה חזק מרוויח מעט פחות משחקני הספסל של בארסה ,ניתן לעשות הקבלות בין הצוותים והשיטות. צוות אג'ילי יעיל וטוב, לא יכול להכיל יותר מדי אגו, ההיפך, נדרשת פה עזרה הדדית ושיתוף פעולה. נדרשת פה גם המון סבלנות של מנהלי הפרוייקט בכל הקשור לעקומת הלימוד וההתקדמות. תהליכים אלה אורכים זמן, אבל ככל שהצוות יהיה מגובש יותר, איכותי יותר ומקצועי יותר כך יגברו הסיכויים שהשיטה תיושם בצורה טובה יותר. לצערי אני מחזיק בדיעה ש scrum לא מתאים לכל אחד, הוא באמת דורש יותר מהתוכניתן/בודק, אל גם נותן הרבה יותר (מה בדיוק?? התשובה בסעיף הבא). 
4. צוות איכותי. אין מה לעשות, פפ לא טעה. צריך אינטיליגנציה גבוהה על מנת ליישם שיטות עבודה מתקדמות. איך שאני תופס את זה, הצוות האג'ילי צריך לעבוד בצורה די מטריציונית, כאשר חבילות הפיתוח עלולות לעבור ממפתח אחד למשנהו בעקבות אילוצים שונים, כנ"ל לגבי בודק התוכנה - הוא צריך להכיר את התמונה הגדולה, כל צוות צריך, אי אפשר יהיה להמשיך ולהתבונן במוצר מנקודת מבט צרה יותר ובכדי לתמוך בשיטת עבודה כזאת, על חברי הצוות להיות באמת אינטיליגנטים יותר, טכנולוגיים יותר, נחושים יותר, עם חשיבה/הבנה עסקית גבוהה יותר. הרי הרעיון הוא שהצוות ינהל את עצמו, יקבל החלטות בעצמו, עם המון אחריות לגבי המוצר ולגבי תוצריו ולמה? זה כל העניין: כי אין יותר את מי להאשים! הצוות הוא הכל ולכן מי שרצה מתנות על העבודה הקשה הנה קיבל, הסיפוק האדיר של כל אחד מחברי הצוות, בכל צעד בכל check-in ובכל Feature שתוכנן פותח ונבדק על ידי אותה קבוצה (מופלאה כבר אמרנו?). אותי זה היה מספק, מה איתכם?

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

אז מה היה כל כך רע?

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

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

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

תודה,

יניב