פיתוח (תוכנה) אג׳ילי
פיתוח אג׳ילי, היא מתודולוגיה לתכנון וניהול פרוייקטים, בעיקר בתחומים טכנולוגיים, המבוססת על גישה הרואה את צרכי המשתמשים כהיגיון המוביל בתהליך הפיתוח. הגישה מציגה את עצמה כ״אמפירית״, כלומר כזו הנבחנת במציאות, מול המשתמשים, ולא כגישה ״לוגית״ הבוחנת את הפונציונאליות של התוכנה. הגישה הובילה למהפכה בעולם פיתוח התוכנה ומשפיעה רבות גם על תהליכי ניהל מעבר לעולמות הטכנולוגיים.
גישה זו נוסחה לראשונה בשנת 2001 ע"י קבוצת מפתחי תוכנה מובילים.
רקע: אג׳ייל מול מפלים
אחד השינויים הגדולים שעבר עולם התוכנה בעשור האחרון, הוא ההבנה ששיטת הניהול הפרוייקטאלית הליניארית הקלאסית מובילה לא אחת לכשלים עמוקים בתהליך הפיתוח כאשר מחילים אותה על פרוייקטי תוכנה. הגישה, אשר נהוג לכנותה 'מודל מפל המים' (Waterfall), על שם התכנסות המאמצים עד לנקודת סיום הפרוייקט, הוכחה כבעייתית, בלשון המעטה, בקידום פרוייקטי תוכנה מורכבים, וישנה תאימות בין היקף ומורכבות הפרוייקט לבין הסבירות לכשלונו במתודולוגיה זו. כלומר - הגישה שנועדה להיות תשתית מתודולוגית לניהול של מאמצי פיתוח ארוכים ומורכבים, נתפסת כיום על ידי רבים ככזו המשבשת את היכולת להוציא אותם לפועל באופן מוצלח
הפרוייקטים שהביאו לידי ביטוי את בעיית שיטת המפלים באופן החריף ביותר הם פרוייקטים ממשלתיים, שהושקע בהם מראש סכום כסף נכבד. כך, למשל, סקירה של פרוייקטי תוכנה גדולים שניהלה ממשלת ישראל בשנות ה-2000 הציגה אחוזי כישלון גבוהים מאוד, חוסר הבנה והלימה בין הדרישות לפיתוח, עיכובים בלו"ז וחריגה משמעותית מהעלות המוערכת. ניסיון נוסף לתכנן את 'המערכת של כל המערכות' בפרוייקט המחשוב של הביטוח הלאומי הגיע גם הוא לאחרונה לידי סגירה וסיום כושל, וגם הצבא חווה מספר לא זעום של כשלונות מן הסוג הזה.
הסיבות המרכזיות לכשלונם של תהליכי פיתוח מפליים הם:
- רכיב אי הוודאות - אנחנו לא באמת יודעים בתחילת הדרך את כלל מאפייני המערכת, וכאשר אנחנו מנסים לאפיין באופן חלוט אנו נוטים ליפול לדיסוננס של תכנון יתר שמקדם פיצ'רים שוליים על פני שימושיות ואפקטיביות.
- פיתוח תוכנה הוא מאמץ יקר מאוד, אך פיתוח תוכנה בכיוון שגוי הוא מאמץ יקר עוד יותר. ללא מעגלי משוב קצרים אנו נוטים לממש את יעדי האפיון ולא את יעדי הפיתוח.
- קשה מאוד לדמיין ולתכנן את האינטגרציה בתחילת התהליך, וכשמגיעים לעסוק בה זה כבר מאוחר מדי (כי הרכיבים השונים נבנו באופן שמקשה מאוד על החיבור).
- אנחנו לא באמת יודעים כיצד משתמשים וארגונים יעבדו עם המערכת - קשה מאוד להבין את המיקודים השונים לפני שיש לנו נתוני אמת של שימוש במערכת (ולא הוכחה או תצוגת תכלית למעטפת ביצועים פיזיקלית). נתונים אלו מצויים רק כאשר יש מוצר ממשי המגיע למשתמשי הקצה.
המענה של תפיסת הפיתוח האג'ילית
במידה רבה, הבנות אלו הן הביטוי המיידי של הפער בין פיתוח חומרה לפיתוח תוכנה. על רק מבוכות אלו, החלו להתפתח החל מראשית שנות ה-90' וביתר שאת בעשורים האחרונים שיטות ניהול אחרות וגמישות יותר, שמתבקשות להתמודד עם קריסת מתודולוגיית הפרוייקט המסורתית. גישות אלו, שזכו לתיאור הכולל והמוכר "Agile Software Developement", מבקשות להציב מענה ראוי לבעיות האינהרנטיות שבגישת ה-Waterfall. להלן מספר נדבכים יסודיים מתוך עקרונות הפיתוח האג'ילי, רובם עוסקים במנגנונים למניעה של פערים שיהיה קשה עד בלתי אפשרי לגשר עליהם בשלבים הבאים:
- מיקוד ב-Minimum Viable Product - המוצר החיוני המינימלי (MVP) הוא מושג קריטי שמטרתו הנגשת הפיתוח בשלב מוקדם ככל הניתן למשתמשים לטובת פיתוח בסביבת השימוש ומיצוי פידבק משתמשים. ה-MVP מבקש להגדיר מוצר מצומצם ככל הניתן, שממנו ימשך הפיתוח לשלבים הבאים, באופן שיתמודד עם הנטיה של תהליכי פיתוח מפליים להתמקד בפיתוח כלל מרכיבי האפיון טרם הנגשת המערכת ללקוחות. מושג ה-MVP קיבל משנה חשיבות בפיתוח של חברות הזנק, הנדרשות להעמיק מוצר מתפקד בטווחי זמן קצרים.
- אינטגרציה מתמשכת (CI: Continuous Integration) - על רקע הקושי באינטגרציה בין הרכיבים, גישה ה-CI מבקשת למנוע את יצירת הפערים בין המרכיבים השונים, על ידי ניהול שוטף של האינטגרציה במהלך כל שלבי הפיתוח ולא רק בשלבי הסיום.
- פיתוח בסבבים מהירים (איטרציות) ועדכוני גרסא תכופים - עולם התוכנה מאפשר תנועה מהירה מאוד מגרסה לגרסה, תוך גילום מנגנון למידה מהירה, ותכנון-ביצוע בטווח קצר. באופן זה ניתן לצמצם את המורכבות הרבה של תהליכי הפיתוח הארוכים וכן להביא את מערכות הפיתוח ליעילות רבה יותר. את הפיתוח מבלוק לבלוק מחליף פיתוח מבוסס איטרציות קצרות (ספרינט).
- צוותי פיתוח אחודים - בעוד שהפיתוח בגישת המפלים התבסס לרוב על צוותים נפרדים ומבודלים שכל אחד מהם אחראי על אספקט אחר של המוצר (קשרי לקוח/ניתוח מערכות, פיתוח) או רכיבים נפרדים, פרוייקטים אג'יליים מתבססים על צוותים אחודים המקדמים את המוצר או נדבך שלם במוצר בכל איטרציה.
- פידבק משתמשים ישיר - לנוכח הקשיים הקוגניטיביים לצפות מראש את התנהגות המשתמשים, הגישה מקדמת שיח ישיר ומתמשך עם הלקוח, על גבי המערכת הנבנית, לצורך הבנת הצורך האמיתי. יתרה מכך, גישה זו נובעת גם מכך שקשה יותר ויותר לצפות את הצורך האמיתי של המשתמש, או את התאימות של הפיתרון לשוק ככל שמדובר במוצר היוצר שיבוש שוק.
שיטות אלו, הקשורות במישרין גם להתפתחויות אחרות בתחום התוכנה (קוד פתוח, תשתיות שרתים וענן זמינות ומאפשרות), מאפשרות לפיתוח התוכנה היום להתנהל בצורה שונה לחלוטין מניהול פרוייקטאלי קלאסי, ולהצליח לייצר כמות מרשימה של מוצרים בפרקי זמן קצרים. עם הצטברות השנים והפרוייקטים, נראה ששיטות אלו הולכות וצוברות הצלחות ביחס לשיטות המסורתיות.
גישה אג'ילית מותאמת במיוחד לפיתוח עבור לקוחות ארגוניים מורכבים, מאחר והיא מאפשרת קבלת פידבק משתמשים בזמן קצר ביותר לטובת טיוב המוצר עוד בשלבי הפיתוח. בנוסף, השימוש הנרחב שאנו עושים במוצרי קוד פתוח מאפשרים לייצר MVP בשלבי ההתקשרות הראשונים כך שהדיון האפיוני יתקיים בסביבת אמת ולא כדיון מילולי גרידא.
פיתוח אג'ילי בפרוייקטים גדולים
לאורך השנים נעשו מספר נסיונות ליישם את העקרונות האג'יליים שנבנו מראש עבור צוותי פיתוח קטנים, לטובת שימוש בפרוייקטים או בארגונים גדולים, וביניהם: LSS, SAFe.
חברת ספוטיפיי בולטת באימוץ של עקרונות אלו ברמת החברה.
ביקורת על השימוש שנעשה בפועל באג'ייל
הביקורת המרכזית על השימוש בפועל במתודולוגיה זו, הוא שבמקרים רבים משתמשים בה רק ככותרת "סקסית" ולא משנים בפועל את ההתנהלות הפרוייקטלית. ארגונים וחברות מתהדרים בקורסים ובהסמכות (שמספרן גדל בצורה אקספוננציאלית ולעיתים מגוחכת), אך לא מצליחים לאמץ את עקרונות השיטה
אג'ייל הפך להיות: "מושג שקונים בקילוגרמים, ולא תיאור של אופן פיתוח התוכנה; "גמיש" ולא "גמישות", דייב תומס, מהחתומים על המנשר המקורי:
פרופ׳ דייב סנואדן מנסח ביקורת דומה:
היישום של אג'ייל, ובעיקר בחברות גדולות או/וגם בהתנהלות מכרזית, נתקל בחומות של תרבות ארגונית היררכית וליניארית, שמתקשה להתמודד עם תהליך לא ודאי שניתן בו משקל מהותי לצוותי הפיתוח ולחיכוך המתמשך עם הלקוח, על חשבון גורמי הנהלה.
לעיתים רבות נוצרו תהליכים המכונים "AgileFall" (על משקל: "Waterfall") בהם קיים פער גדול בין ההצהרות של הארגון על היותו אג'ילי, לבין תרבות פרוייקטלית הירארכית וליניארית שלא משתנה.
|
When selecting an agile framework, preference should be given to those that do not perpetuate a waterfall mindset or allow us to fall back on old ways of work. Do not adopt a framework because it seems comfortable and has familiar Waterfall tempos. DevSecOpsfriendly frameworks do not encourage, include, or tolerate extensive requirement generation prior to software development. |
|
| – התוכניתן הראשי של חיל האוויר האמריקאי, דצמבר 2019 | ||
ראו גם
לקריאה נוספת
- To agility and beyond: The history — and legacy — of agile development, מאמר נהדר מתוך TechBeacon.
- סדרת פוסטים מצויינת בנושא בבלוג Software Archiblog - בלוג ארכיטקטורת תוכנה
- יבשה בעידן הדיגיטל – למה זה לא מצליח לנו? פרספקטיבה טכנולוגית לדיון על "יבשה באופק", יותם הכהן ויואל יפה, בין הקטבים.
יש שותפים רבים לכתיבה במאגר הידע. מאמר זה נכתב על ידי מתן רוטמן, יותם הכהן, יואל יפה. ניתן לצטט אותו באופן הבא:
- מתן רוטמן, יותם הכהן, יואל יפה, פיתוח (תוכנה) אג׳ילי, מאגר הידע של דואלוג, 2019.
הטקסטים במאגר הידע מוגשים תחת רישיון CC-BY 4.0 וניתן לעשות בהם שימוש חופשי כל עוד ניתן קרדיט וקישור למקור.