האם הדור הבא של פיתוח התוכנה הוא פיתוח גמיש?
שיטת הפיתוח הגמיש היא שיטה יעילה משמעותית מהשיטות המסורתיות לפיתוח אג'ילי בכך שהיא מתבססת על גמישות בגודל ובהרכב צוות הפיתוח
מאת רוברט דן ינוביץ'
גישת פיתוח התוכנה האג'ילי נמצאת בשימוש נרחב בפרויקטי פיתוח מזה שנים רבות, אך בשנים האחרונות קיים ויכוח בנוגע לרלוונטיות שלה. על פי Project Management Institute, כמעט שלושת-רבעי מהארגונים (71%) מדווחים כי הם משתמשים בגישה זאת ברמה זו או אחרת, אולם למרות הפופולאריות, מסתבר כי בפועל היא דורשת שינויים והתאמות על מנת לאמץ אותה ולהפיק ממנה את המיטב בפרויקטים טכנולוגיים בסוגים שונים של ארגונים.
על פי Gartner Hype Cycle גישת פיתוח התוכנה האג'ילית הגיעה לשיא של מחזור ההייפ שלה (Peak of Inflated Expectations, "שיא הציפיות המנופחות"), כלומר על פי ההגדרה של מחזור ההייפ, מדובר במודל שהגיע לשלב של התלהבות מוגזמת, כאשר בפועל יש יותר כישלונות מהצלחות ויותר חברות בוחנות האם המודל מתאים לסדר היום העסקי שלהן. בעיות מתחילות להיערם על שולחנו של מנהל הפרויקטים, יחד עם פרסומים שליליים במדיה.
התוצאה הבלתי נמנעת היא איבוד גובה של הגישה האג'ילית הקלאסית, בד בבד עם הופעתו של דור שני ושלישי של מודלים, כלים ומתודולוגיות. בשנים האחרונות החלו להופיע מודלים חדשים ומעודכנים יותר לפיתוח תוכנה, בהם גם מודלים ישראליים חדשניים לפיתוח תוכנה כשרות (R&D As a Service), המוצעים על ידי שותפים עסקיים. יחד עם זאת, לא כל המודלים שווים, ולא כולם מציעים אלטרנטיבה אמיתית, שכן הם לא תמיד עונים על בעיות המפתח שקיימות במודל הקלאסי של גישת הפיתוח האג'ילי.
לפני שבוחנים גישות פיתוח חדישות, חשוב להכיר ראשית את הקשיים הקיימים בגישה האג'ילית הקלאסית ולנתח את יכולתה לענות על הקשיים הללו.
מהם הקשיים העיקריים במודל הפיתוח האג'ילי הקלאסי?
גישת הפיתוח האג'ילי פותחה בתחילת שנות התשעים על בסיס עקרונות הניהול הרזה (Lean Management). היא נועדה לפשט ניהול של פרויקטים מורכבים של פיתוח תוכנה בכל קנה מידה. הרעיון העומד מאחורי הגישה הוא לחלק את הפרויקט הארוך או המורכב לשלבים קטנים ופשוטים יחסית, ביצוע ביקורות בזמנים קצובים ובהתאם להן ביצוע שינויים או התאמות במהלך הדרך. גישת הפיתוח האג'ילי מכילה אוסף של שיטות שהמפורסמת והנפוצה שבהן היא שיטת סקראם (Scrum).
כפי שציינו, ארגונים רבים מתקשים לאמץ שיטה זו בשל מספר סיבות עיקריות:
ניהול ללא מנהלים – בגישה הניהולית האנטי-היררכית של הפיתוח האג'ילי, הבאה לידי ביטוי בעיקר בשיטת הסקראם, אין התייחסות לראש צוות הפיתוח או למנהלים בכלל. הנחת העבודה היא שצוות הפיתוח מנהל את עצמו. לעיקרון הניהול העצמי יתרונות משמעותיים דוגמת העצמת הצוות והגברת המוטיבציה והמחויבות שלו, אולם יש לבצע הרבה התאמות על מנת להטמיע אותה בארגונים גדולים והיררכיים. במחקר שבוצע על ידי VersionOne, מתוך יישומי הפיתוח האג'ילי שנכשלו, 63% מהמשיבים האשימו בכך את ההתנגשות בין התרבות הארגונית לפילוסופיה העסקית האג'ילית.
קושי בתכנון ארוך-טווח וסנכרון בין הצוותים – קשיים נוספים המתעוררים מיישום הסקראם כפשוטו הם התעלמות ממצבים בהם יש מספר צוותי פיתוח התלויים זה בזה, והיעדר אופק תכנון מעבר לטווח המאוץ הקרוב (שאורכו האידיאלי כאמור הוא שבועיים). כדי להתמודד עם פערים אלו (ועם פערים נוספים) פותחה "המסגרת האג'ילית המורחבת" (Scaled Agile Framework ובקיצור: SAFe), המוסיפה רובד נוסף לסקראם ומאפשרת סנכרון בין מספר צוותים, יישור קו בין כולם על ידי יצירת מקצב ארגוני ותכנון רבעוני.
היעדר גמישות בגודל והרכב צוות הפיתוח – השיטות האג'יליות המסורתיות מדגישות את חשיבות השמירה על גודל קבוע של צוות הפיתוח ועומדות על כך שצוות הפיתוח יהיה ורסטילי ושוויוני, כלומר בצוות אין אבחנה בין מתכנתים ובודקים, אין אבחנה בין חזית (Front-End) ועורף (Back-End) – כולם מפתחים. רעיון השוויון נועד ליצור אווירה של לכידות וערבות הדדית בצוות הפיתוח, אבל זה פשוט לא עובד במציאות. קיימים תחומי התמחות שונים והשיטה צריכה להכיר בשונות ולא להתעלם ממנה.
הבעיה האקוטית ביותר – היעדר הגמישות
היעדר הגמישות בגישה האג'ילית הקלאסית הוא הבעיה הקשה ביותר מהקשיים שציינתי וזאת משום שהוא עשוי להיות הגורם המכריע בין הצלחה לכישלון פרויקט ואפילו בין הצלחה לכישלון של חברה, אם מדובר בחברת הזנק.
ארגונים בעולם האמתי חייבים להיות מסוגלים להתאים את גודל והרכב צוות הפיתוח לצורך העסקי שלהם. דמיינו חברת סטארטאפ שפיתחה אבטיפוס למוצר וכעת מעוניינת להקפיא את הפיתוח עד לגיוס משקיעים, ולאחר מכן לשוב לתנופת פיתוח בכל הכוח. חברה כזאת תצטרך לפטר עובדים ואחר כך לגייס עובדים חדשים, דבר בא לידי ביטוי בבזבוז של זמן, כסף ואובדן ידע. המשך ההעסקה של כולם במשך תקופת השפל יכול להביא אותה להתמוטטות כלכלית.
כמו כן, לעתים נדרש לשנות את הרכב צוות הפיתוח: בהחלט ייתכן מצב שבו אחרי גרסה שהתמקדה בתשתית האפליקטיבית (דגש על מפתחי Back-End) מחליטים בגרסה הבאה להשקיע דווקא בחוויית המשתמש (יותר מפתחי Front-End).
הדור הבא: פיתוח גמיש
בשנים האחרונות בוצעו מספר רב של פרויקטים בהצלחה רבה תחת מודל הפיתוח הגמיש (Flexible R&D). המודל מבוסס על גישת הפיתוח האג'ילי, אך לוקח אותה עוד צעד ענק קדימה במונחי יעילות, חסכון במשאבים, אפקטיביות וניהול תקין של לוחות הזמנים של הפרויקט.
מודל הפיתוח הגמיש מוצע כיום לארגונים בכל סדרי הגודל כשרות (R&D as a Service) על ידי שותף מקצועי. הרעיון העומד מאחורי המודל, כשמו, הוא לספק מקסימום גמישות בתמהיל ובגודל צוות הפיתוח. תחת מודל זה, שותף הפיתוח שלכם מספק לכם את הכמות והתמהיל המקצועי המדויק של מומחים על פי התנודתיות בצרכי הפרויקט בשלביו השונים. הגמישות הזאת מאפשרת לנהל את הפרויקט בצורה יעילה ולשלם רק על שעות העבודה שבהן אכן הצוות נחוץ. ניתן להשוות את מודל הפיתוח הגמיש ל'שירות ענני' – אתם משלמים רק לפי צריכה – בדיוק כמו כל שירות ענני אחר.
היכולת של השותף המקצועי שלכם ליישם את השיטה תלויה ביכולת שלו להציג מגוון מיומנויות ופרויקטים. אם השותף שלכם מנהל מגוון פרויקטים בעת ובעונה אחת וברשותו מומחים מכלל הקשת הטכנולוגית, הוא יכול לנייד את העובדים המומחים שלו בין הפרויקטים לפי הצורך של הלקוחות השונים ולאפשר את הגמישות הזאת.
פרויקטים רבים בסדרי גודל שונים, שבוצעו תחת מודל הפיתוח הגמיש, הוכיחו את יעילותו. מעבר לחסכון כספי, הפיתוח הגמיש מאפשר פינוי אדיר של משאבי זמן, אשר יוצר הזדמנות מצוינת לתכנון ארוך טווח והשקעת משאבים בתחומים אחרים ואקוטיים לא פחות לארגון, דוגמת יציאה לשוק של המוצר הנמצא תחת פיתוח.
הכותב הינו ראש תחום ייעוץ מתודולוגי בחברת Comm-IT
הגב
17 תגובות על "האם הדור הבא של פיתוח התוכנה הוא פיתוח גמיש?"
* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.
אז פשוט הצעתם outsource? זה החידוש הגדול בשיטה?
כן. תהפכו את כולנו לעובדי קבלן.
התוכן המקודם הכי משעמם שהיה כאן, אבר.
פיתוח גמיש…. כמי שעבד ככה אני אגיד לכם שיש לזה יתרונות וחסרונות, אבל זה בהחלט לא לשלם לפי שעות עבודה, כי בפועל אתה רוצה אותם full-time אחרת הם ילכו לפרוייקט אחר לאלוהים יודע כמה זמן ואז איבדת את ההכשרה והידע (בדיוק כמו פיטורים). הייתרון היחיד – הם זולים…
קרה לכם שסיפרו לכם בהתלהבות על רעיון חדש ומהפכני ולא הבנתם מה חדש בזה?
זה מה שאני חווה עכשיו
סיכום:
בעל חברה! אל תשלם לצוותי פיתוח. זה יקר וקשה לנהל צוותי פיתוח. במקום עבוד עם שותף עסקי שיספק לך מתכנתים. זה משהו חדש לגמרי, באז וורד, באז וורד, באז וורד.
זה לא שבשנות ה90 כבר עבדו עם מטריקס.
אני יועץ מקצועי שכותב כתבה מקצועית על התקדמות במתודולגיות חדשניות ויעילות. אני לא מנסה למכור לך חרא מחומם במיקרו בכלל בכלל בכלל.
תגידו לי גיקטיים, אין מקום שאתם מסננים את התוכן שאת מקבלים?
במילים אחרות. לך לשותף הוא יזרוק לך כמה גולגולות לפרוייקט. מה שפעם היה גלאדיאטורים היו זה מפתחים
ככה זה נראה כשמנסים לדחוף פיתרון מלאכותי לבעיה שבכלל לא קיימת/לא מבינים את הבעיה.
שירות חדש: מנהלים כשירות. ניקח מנהלים שלא עושים באמת עבודה רק לצורך פרוייקטים ספציפיים וכשיש פחות עבודה לנהל, נזדכה עליהם אצל ספק המנהלים
זה יכול להיות רעיון לא רע… מנהלים outsource… גם ככה העבודה שלהם גנרית
מישהו יכול לצרף לינק למקור הכתבה באנגלית? תודה
הכתבה מטעה ולא עניינית. אין קשר בין אאוטסורסינג לבין שיטת פיתוח תוכנה אג'ילית. האחד מדבר על הדרך בא אתה משיג את העובדים המפתחים את התוכנה והשני מדבר על הדרך בה אתה מפתח ומדלבר. מה עוד ששיטות אג'יליות מתייחסות להרבה אספקטים מעבר לארגון הפיתוח – זה מדבר על ניהול המוצר, האינטראקציה עם הלקוחות, וכו.
אוטסורסינג במסווה של כתבה מקצועית , עלוב
הדבר שכמעט כל חברה מפספסת בגישת אג'ייל זה שגישת אג'ייל היא לא בעיה! ה"בעיה" היא באנשים/בעובדים! רוב העובדים לא *באמת* מבינים את גישת העבודה של אג'ייל ומה שקורה זה שאתה עובד אג'ייל אבל העובד QA שעובד איתך עדיין בגישת ווטר-פול, וה-PO בגישת "אני אכין ספייק לפיצ'ר ואשנה אותו 100 פעם תוך כדי פיתוח" ובסופו של דבר לא מבינים איך לא מצליחים ליישם את אג'ייל!
בקיצור- גישת העבודה חייבת להיות מותאמת לצוות הפיתוח!
יש אנשים שפשוט לא מסוגלים ליישם אותה (וכנראה שגם באמת היא לא מתאימה להם) ולכן היא לא תתאים לכל חברה!
הבסיס לשיפור הפיתוח האג׳ילי הנו הבנת עקרון ה flow
עלפיו נרצה שהמומר הפיצ׳ר יהיה בזרימה קרי בעבודה בעלת ערך כל הזמן
כאשר אנו ממתינים עושים עבודה חוזרת או מבצעים בדיקות מיותרות הפיצר לא בזרימה לצורך זה שהוא יהיה בזאימה אנו צריכים משאבים מתאימיםנזמינים אנו צריכים שלא יהיו עיכובים והמתנות ומכאן עבודה משותפת בו זמנית של הדיסציפלינות השונות על אותו פיצר הכרחית וקריטית הגמישות בצוות תיקבע לפי התכולות הנדרשות , נשתדל להקצות תכולות דומות בהיבט הטכני / דיסציפלינארי לאותו צוות
עבודה אוטונומית של צוות זו לא החלטה אלא יכולת ארגונית ניהולית וצוותית שצריך לפתח
שי וירט – lean development