מפל המים מול השיטה הזמישה

Waterfall vs. Agile
מפל המים מול השיטה הזמישה*

מאת שאול שולנסקי **

בסוף שנות ה-90 של המאה הקודמת, התנהל פרויקט גרנדיוזי של שדרוג מערכות המחשוב בבולשת הפדרלית (FBI) בארה”ב.
פרויקט זה כלל הטמעה של שיטות עבודה דיגיטליות שיועדו להחליף את השיטות הידניות, הניירות והראיות הפיזיות שהי נהוגות עד אז בארגון, כך שתיווצר פלטפורמה אחידה ודיגיטלית, נגישה בזמן אמת לכל מחלקות הארגון, תוך הקפדה על ביטחון המידע.
הפרויקט כלל שדרוג של מעל ל-30,000 עמדות קצה, כ-4000 מדפסות ו-500 שרתים, וכל המשתמע מכך בתקציב מקורי של כ- $380,000,000 .

פרויקט זה נכשל, גרם לחריגות עצומות בזמן, תכולה ותקציב, ומשמש היום כ-case study בבתי הספר לניהול, איך לא מיישמים פרויקט תוכנה.
בנוסף לכך, בעיצומו של הפרויקט אירעו אירועי ה-11 בספטמבר, הקונגרס אישר את תוספת התקציב והתקנים שנדרשו ובסופו של דבר הפרויקט הושלם, אחרי החלפת 5 ראשי ארגון, 10  מנהלי פרויקט ו-36 קבלני משנה, בסוף שנת 2004.

מדוע נכשל הפרויקט ?

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

מתודולוגיות יישום:

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

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

1. מפל המים (Waterfall), גם מוכר כשיטה ה”קלאסית”
2. השיטה הזריזה (Agile)

שתי השיטות ותיקות, בדוקות ומקובלות בישום פרויקטים של תוכנה.

מפל המים (Waterfall)

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

בשיטה זו השלבים ביישום פרויקט תוכנה הם לרוב:

1. איסוף ותיעוד דרישות
2. תכן
3. כתיבה ובדיקה של כל יחידה
4. בדיקות אינטגרציה
5. בדיקות קבלה של הלקוח (UAT)
6. תיקונים
7. מסירה ללקוח

יתרונות השיטה

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

חסרונות השיטה

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

השיטה הזריזה (Agile)

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

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

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

יתרונות השיטה

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

חסרונות השיטה

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

סיכום

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

מקורות: Waterfall vs. Agile, by Mary Lotz

* זמישה = זריזה וגמישה

** שאול הנו ראש תחום PLM במטריקס