האם הדור הבא של פיתוח התוכנה הוא פיתוח גמיש?

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

מקור: Pixabay

מאת רוברט דן ינוביץ’

גישת פיתוח התוכנה האג’ילי נמצאת בשימוש נרחב בפרויקטי פיתוח מזה שנים רבות, אך בשנים האחרונות קיים ויכוח בנוגע לרלוונטיות שלה. על פי 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 תגובות על "האם הדור הבא של פיתוח התוכנה הוא פיתוח גמיש?"

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

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

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

אז פשוט הצעתם outsource? זה החידוש הגדול בשיטה?

מישהו
Guest

כן. תהפכו את כולנו לעובדי קבלן.

דג ברשת
Guest
אם מישהו יודה באמת (אבל אסור כי חייבים לומר שהכל נפלא וכמה אנו מתקדמים בשיטות עבודה)- גם האאוטסורסינג הזה לא יצליח. לספק השרות תמידי יהיו בסטוק אנשים מוכשרים ובעלי ידע? האם הם תמיד זמינים לניוד? (כלומר אינם עסוקים ומישהו משלם להם על בטלה) או שיתנהלו כמו היום, קולטים מי שרק אפשר ומוכן לעבוד בזול, ומציגים אותו ביועץ מומחה ורב ניסיון. אפיל שלפחות חצי מהזמן אין כיסוי להצהרות אלו והלקוח משלפם זמן וכסף עבור חניכה, לימוד והתנסות של אותו יועץ, כמו גם תיקון נזקים ובעיות במה שעשה. אבל מנהלים חייבים מילים יפות להתהדר בהן, באזזורד שהוא עדכני, ומה איכפת שהחברה משלמת… Read more »
רון
Guest

התוכן המקודם הכי משעמם שהיה כאן, אבר.

לירן
Guest

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

איציק
Guest

קרה לכם שסיפרו לכם בהתלהבות על רעיון חדש ומהפכני ולא הבנתם מה חדש בזה?
זה מה שאני חווה עכשיו

Tal
Guest

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

תגידו לי גיקטיים, אין מקום שאתם מסננים את התוכן שאת מקבלים?

עצוב שכך
Guest

במילים אחרות. לך לשותף הוא יזרוק לך כמה גולגולות לפרוייקט. מה שפעם היה גלאדיאטורים היו זה מפתחים

L.S
Guest

ככה זה נראה כשמנסים לדחוף פיתרון מלאכותי לבעיה שבכלל לא קיימת/לא מבינים את הבעיה.

Developer
Guest

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

Liran elisha
Guest

זה יכול להיות רעיון לא רע… מנהלים outsource… גם ככה העבודה שלהם גנרית

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

מישהו יכול לצרף לינק למקור הכתבה באנגלית? תודה

ארז
Guest

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

בנגלור
Guest

אוטסורסינג במסווה של כתבה מקצועית , עלוב

ScrumMaster
Guest

הדבר שכמעט כל חברה מפספסת בגישת אג’ייל זה שגישת אג’ייל היא לא בעיה! ה”בעיה” היא באנשים/בעובדים! רוב העובדים לא *באמת* מבינים את גישת העבודה של אג’ייל ומה שקורה זה שאתה עובד אג’ייל אבל העובד QA שעובד איתך עדיין בגישת ווטר-פול, וה-PO בגישת “אני אכין ספייק לפיצ’ר ואשנה אותו 100 פעם תוך כדי פיתוח” ובסופו של דבר לא מבינים איך לא מצליחים ליישם את אג’ייל!
בקיצור- גישת העבודה חייבת להיות מותאמת לצוות הפיתוח!
יש אנשים שפשוט לא מסוגלים ליישם אותה (וכנראה שגם באמת היא לא מתאימה להם) ולכן היא לא תתאים לכל חברה!

שי וירט
Guest

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

wpDiscuz

תגיות לכתבה: