פיתוח (תוכנה) אג׳ילי

מאגר הידע של דואלוג: מאגר הידע המקיף בעברית בתחומי האסטרטגיה והחשיבה המערכתית
גרסה מ־13:19, 26 בינואר 2020 מאת Office (שיחה | תרומות) (יצירת דף עם התוכן "'''פיתוח אג׳ילי''', היא מתודולוגיה לניהול פיתוח טכנולוגי המבוססת על גישה הרואה את צרכי המש...")
(הבדל) → הגרסה הקודמת | הגרסה האחרונה (הבדל) | הגרסה הבאה ← (הבדל)
קפיצה לניווט קפיצה לחיפוש

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

רקע: אג׳ייל מול מפלים

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

גאנט ״מפלים״ קלאסי

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

הסיבות המרכזיות לכשלונם של תהליכי פיתוח מפליים הם:

  1. רכיב אי הוודאות - אנחנו לא באמת יודעים בתחילת הדרך את כלל מאפייני המערכת, וכאשר אנחנו מנסים לאפיין באופן חלוט אנו נוטים ליפול לדיסוננס של תכנון יתר שמקדם פיצ'רים שוליים על פני שימושיות ואפקטיביות.
  2. פיתוח תוכנה הוא מאמץ יקר מאוד, אך פיתוח תוכנה בכיוון שגוי הוא מאמץ יקר עוד יותר. ללא מעגלי משוב קצרים אנו נוטים לממש את יעדי האפיון ולא את יעדי הפיתוח.
  3. קשה מאוד לדמיין ולתכנן את האינטגרציה בתחילת התהליך, וכשמגיעים לעסוק בה זה כבר מאוחר מדי (כי הרכיבים השונים נבנו באופן שמקשה מאוד על החיבור).
  4. אנחנו לא באמת יודעים כיצד משתמשים וארגונים יעבדו עם המערכת - קשה מאוד להבין את המיקודים השונים לפני שיש לנו נתוני אמת של שימוש במערכת (ולא הוכחה או תצוגת תכלית למעטפת ביצועים פיזיקלית). נתונים אלו מצויים רק כאשר יש מוצר ממשי המגיע למשתמשי הקצה.

המענה של תפיסת הפיתוח האג'ילית

במידה רבה, הבנות אלו הן הביטוי המיידי של הפער בין פיתוח חומרה לפיתוח תוכנה. על רק מבוכות אלו, החלו להתפתח החל מראשית שנות ה-90' וביתר שאת בעשורים האחרונים שיטות ניהול אחרות וגמישות יותר, שמתבקשות להתמודד עם קריסת מתודולוגיית הפרוייקט המסורתית. גישות אלו, שזכו לתיאור הכולל והמוכר "Agile Software Developement", מבקשות להציב מענה ראוי לבעיות האינהרנטיות שבגישת ה-Waterfall. להלן מספר נדבכים יסודיים מתוך עקרונות הפיתוח האג'ילי, רובם עוסקים במנגנונים למניעה של פערים שיהיה קשה עד בלתי אפשרי לגשר עליהם בשלבים הבאים:

  • מיקוד ב-Minimal Viable Product - המוצר החיוני המינימלי (MVP) הוא מושג קריטי שמטרתו הנגשת הפיתוח בשלב מוקדם ככל הניתן למשתמשים לטובת פיתוח בסביבת השימוש ומיצוי פידבק משתמשים. ה-MVP מבקש להגדיר מוצר מצומצם ככל הניתן, שממנו ימשך הפיתוח לשלבים הבאים, באופן שיתמודד עם הנטיה של תהליכי פיתוח מפליים להתמקד בפיתוח כלל מרכיבי האפיון טרם הנגשת המערכת ללקוחות. מושג ה-MVP קיבל משנה חשיבות בפיתוח של חברות הזנק, הנדרשות להעמיק מוצר מתפקד בטווחי זמן קצרים.
  • אינטגרציה מתמשכת (Continuous Integration) - על רקע הקושי באינטגרציה בין הרכיבים, גישה ה-CI מבקשת למנוע את יצירת הפערים בין המרכיבים השונים, על ידי ניהול שוטף של האינטגרציה במהלך כל שלבי הפיתוח ולא רק בשלבי הסיום.
  • פיתוח בסבבים מהירים (איטרציות) ועדכוני גרסא תכופים - עולם התוכנה מאפשר תנועה מהירה מאוד מגרסה לגרסה, תוך גילום מנגנון למידה מהירה, ותכנון-ביצוע בטווח קצר. באופן זה ניתן לצמצם את המורכבות הרבה של תהליכי הפיתוח הארוכים וכן להביא את מערכות הפיתוח ליעילות רבה יותר. את הפיתוח מבלוק לבלוק מחליף פיתוח מבוסס איטרציות קצרות (ספרינט).
  • צוותי פיתוח אחודים - בעוד שהפיתוח בגישת המפלים התבסס לרוב על צוותים המבוססים על טכנולוגיות (בסיס נתונים, צד לקוח וכיוב') או רכיבים נפרדים, פרוייקטים אג'יליים מתבססים על צוותים אחודים המקדמים את המוצר או נדבך שלם במוצר בכל איטרציה.
  • פידבק משתמשים ישיר - לנוכח הקשיים הקוגניטיביים לצפות מראש את התנהגות המשתמשים, הגישה מקדמת שיח ישיר ומתמשך עם הלקוח, על גבי המערכת הנבנית, לצורך הבנת הצורך האמיתי.

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

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

ראו גם

לקריאה נוספת

הודפס מתוך מאגר הידע של דואלוג בכתובת: "https://doalogue.co.il/wiki/index.php?title=פיתוח_(תוכנה)_אג׳ילי&oldid=9009"

משותף תחת רישיון CC-BY 4.0. ניתן להפיץ באופן חופשי תוך מתן קרדיט לדואלוג וקישור למקור.