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

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

מקור: 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 תגובות על "האם הדור הבא של פיתוח התוכנה הוא פיתוח גמיש?"

התחבר עם:

Photo and Image Files

Audio and Video Files

Other File Types

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

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

Guest

מה החידוש