על היתרונות של שיטת הפיתוח אג’ייל ואיך תעשו את זה נכון

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

gilaxia/ Getty Images Israel

צלם/תמונה: gilaxia/ Getty Images Israel

מאת ארז מורביה

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

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

1. סינכרון בין צוותים: צוותים אג’יליים הם הטרוגנים טכנולוגית (cross functional) ומסוגלים לפתח יחד (ללא תלות חיצונית) יכולת מקצה לקצה במוצר, על ידי עבודה במקביל ובאופן מסונכרן על בסיס יומי. זאת בניגוד לצוותים הומוגניים טכנולוגית היוצרים תלות בין הצוותים.

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

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

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

5. גילוי מוקדם של בעיות וטיפול מהיר בהן (fail early, recover fast): באג’ייל מאמינים שהדרך האפקטיבית והמספקת ביותר לשיתוף מידע בקבוצת הפיתוח היא שיחה פנים מול פנים. דו שיח רציף ומתמשך בין אנשי הצוות עוזר לגילוי מוקדם של בעיות התוכנה, וגילוי מוקדם של בעיות מוביל כמובן לטיפול מהיר בהן. קן שוובר (Ken Schwaber), ממציאי הסקראם, השכיל לומר: “שיטת הסקראם היא כמו חמותך, מדגישה את כל הפגמים שלך”.

השינוי המחשבתי

סקר של VersionOne מראה ש-94% מהמשתתפים משתמשים באג’ייל (ובעברית צחה “זמיש” – הלחם של זריז וגמיש), ושמתודולוגיית האג’ייל הנפוצה ביותר (68%) היא סקראם (Scrum). רוב העונים על הסקר הם ארגוני פיתוח תוכנה, אבל לא רק. חמשת היתרונות העיקריים שהמשתתפים בסקר ציינו הם: היכולת לנהל ולהגיב לשינויים בדרישות, שקיפות מצב הפרויקט, גדילה בתפוקת הצוות, מהירות גדולה יותר בהבאת מוצר עובד לשוק והמורל של הצוות.

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

מתוך הסקר של VersionOne

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

העובד

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

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

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

המנהל

תפקיד המנהל במודל “מפל המים” מוגדר היטב: מעין מפקד צוות בגישת command & control. בסקראם טועים לחשוב שתפקיד המנהל נעלם, אך ההיפך הוא הנכון – תפקיד המנהל נחוץ ומרכזי. המנהל נדרש ליישם מנהיגות משרתת (servant leadership); הוא לא מקצה משימות לעובד, אלא תומך בו במשימות שבחר. המנהל לא מעריך את משך זמן המשימה, אלא עוזר לעובד להעריך זאת בעצמו; המנהל דואג לפיתוחו האישי של העובד וחונך אותו ותומך בו תוך כדי הטמעת תהליך האג’ייל.

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

איך להטמיע אג’ייל נכון?

האתגרים הללו כנראה גורמים לארגונים רבים לעצור את ההטמעה ברמת בשלות בסיסית. בסקראם לדוגמה קל יחסית לבצע חלק מהטקסים (sprint planning, daily) ולהגדיר את בעלי התפקידים החדשים (כגון scrum master), אבל קשה בהרבה ליישם את כל השאר ולכן עוצרים ברמה הבסיסית.

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

ואיך בכל זאת מטמיעים אג’ייל בצורה נכונה? לאט ובזהירות. אני ממליץ קודם כל לקרוא על הנושא: ספרים (essential scrum, scrum shortcuts), בלוגים (Mike Cohn’s Blog), אתרים (The Scrum Guide), הרצאות ביוטיוב (Scrum under 10 minutes). אם יש תקציב ניתן לקחת חברת ייעוץ שמלווה את התהליך או לוודא שיש מישהו בארגון שהמעבר לסקראם בוער בעצמותיו והוא יכול להוביל את התהליך. וכמובן להתחיל בקטן ומלמטה – לקחת פרויקט לא גדול ולנסות להטמיע בו סקראם; לחגוג ניצחונות קטנים ואז להמשיך לקנה מידה גדול יותר. והכי חשוב –  לא לשכוח לתקשר את חשיבות המעבר לאג’ייל לאורך כל הדרך הן לעובדים והן למנהלים, ולזכור שלמרות שמדובר בתהליך ארוך ומפרך (אצלי רמת בשלות מתקדמת בהטמעת האג’ייל בקבוצת הפיתוח ארכה כשנתיים), היתרונות עולים עשרות מונים על המאמץ הכרוך בהטמעתו.

הכותב הוא מנהל פיתוח בחברת Avaya

המשרות הכי שוות בהייטק מחכות לכם ב-Geetime Insider

כתב אורח

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

הגב

5 תגובות על "על היתרונות של שיטת הפיתוח אג’ייל ואיך תעשו את זה נכון"

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

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

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

סקראם – מימוש רעיונות Lean שמתמקדת בזוטות ובטכני – במקום בעיקר.

94% אימוץ עם 80% כישלון מראה שזו אחת המתודולוגיות הכושלות ביותר: עם עשור של השקעה אדירה מצד כל ארגון כמעט בעולם – וזה עדיין לא עובד. חבל על ההשקעות האדירות שנעשו.

הגיע הזמן לקבור את סקראם בין EJB ו CMM – ולהמשיך הלאה. לא כל מה שנשמע יפה (ומפרנס מאות אלפי יועצים) מצליח להביא ערך….

ארז מורביה
Guest

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

Yaron
Guest

אהבתי את הכתבה, מאוד מתומצת אבל בדיוק במידה.

ארז מורביה
Guest

תודה. יש כל כך הרבה מה לכתוב על הנושא וכל כך מעט מקום… :)

התכנת
Guest

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

wpDiscuz

תגיות לכתבה: