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

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

אז זה טוב, או לא?

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

אנשי המוצר והUI נהנו מהיכולת לקבל תוצר מהר מהפיתוח, ולתת משוב תוך כדי, ולא בסיום התהליך.

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

אז מי נהנה פחות, תשאלו?

הQA, כמובן.

מדוע הQA נהנים פחות מSCRUM

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

עוד בעיה אופיינית נובעת מעיקרון ה80-20: כיוון שSCRUM מתמקדת במה שכן אפשר להספיק במהלך כל ספרינט, לעתים השלמת ה20% האחרונים תיקח משמעותית יותר זמן מ80 האחוז שלפניהם.

אז איך אפשר להימנע מהבעיות האלו?

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

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

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

ולסיכום

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

יובל לשם

איש פיתוח.