בהנחה מטעה זאת נתקלתי בהרבה מקומות בהם מתוארים עקרונות הבסיס של פיתוח תוכנה בשיטת Agile.

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

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

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

המספר ההולך וגדל של פרוטוטייפים הביא לפיתוח מודלים ספירליים של פיתוח מוצרי תוכנה באיטרציות (סבבים), כמו:

התוצר של כל איטרציה היה prototype משופר, יחסית לזה של האיטרציה הקודמת.

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

שימו לב שבמודל המופיע בדיאגרמה לעיל הדרישות הוגדרו רק אחרי ה-prototype השני ותכנון המוצר הראשוני (high level design) רק אחרי השלישי. בהמשך עברו בחלק מהפרויקטים להגדיר את הדרישות ולתכנן את המוצר לכל איטרציה בנפרד והאיטרציות התחילו להקרא sprint-ים. בחלק מן המקרים גם מארגנים מחדש את מבנה המטריצה, כך שכל צוות יכיל כמה שיותר מאנשי המקצוע הנדרשים לשלב הפיתוח המרכזי, החל ממאפיינים ועד לבודקים.

למרות ההתלהבות הראשונית מגישת ה-Agile הגמישה, חלק מן ההנחות המקלות המקוריות שלו כמו: "כל עובד יכול לבצע כל משימה" ו"אין תלויות בין הצוותים" התגלו כמוטעות. לכן מתפתחות עוד ועוד שיטות על מנת לפתור את הכשלים בשיטה. ישנם ארגונים שנטשו את התכנון והביצוע העצמאיים לכל צוות וחזרו לתכנון משותף (כמו Scrum of Scrums) שבו מתכננים מראש כמה איטרציות יחד (PI = Program Increment). הועלתה אף הטענה שעד שאחרון האנשים בארגון לא יהיה מחויב לשיטה, היא לא תעבוד (רחוק מאד מהצוותים העצמאיים שבבסיס ה-Agile).
המהדרין גם מקפיאים את הדרישות בתחילת כל sprint, כי הסתבר שככל שהדרישות מוקפאות יותר ולטווח ארוך יותר, יכולת החיזוי מבחינת לוחות הזמנים עולה, ושזה חיוני מבחינה עסקית.
מזכיר למישהו את ה-Waterfall? חוזרים לשם?
לי מזכירים השינויים האלה במודל הפיתוח את תנועת המטוטלת: אחרי שמרחיקים מדי לכיוון אחד, מתחילים לחזור; וכך הלוך וחזור, עד לנקודת האיזון.

כך הגענו לשלל מודלים שבהם משלבים אלמנטים של Waterfall עם אלו של Agile. שיטות עבודה אלו זכו לשמות חיבה כמו Water-Scrum-Fall,י Agifall,י Scrummerfall ו- Wagile.

לסיכום: יש הרבה יותר משתי שיטות לפיתוח תוכנה. ישנם הרבה גוונים של פיתוח בין לגמרי-Waterfall לבין לגמרי-Agile. לא ממליצה על אף אחד מהקצוות.


נכתב ע"י רונית סנה
IntelliManage

שאלות ותגובות למיתוס זה ניתן להעלות כאן