יונתן, מנהל פרויקטים בכיר בחברת תוכנה גדולה, אחז את ראשו בין ידיו.
"כיצד אתמודד עם רמת חוסר וודאות שכזו? אינני מבין כיצד אוכל לתזמן את תאריך המסירה הצפוי בפרויקט הזה?" שאל אותי, עת תפקדתי כ-PMO המבצע תכנון, בקרה ומעקב על תוכנית העבודה הפרויקטלית.
יונתן, כמו מנהלי פרויקטים רבים אחרים "שהזיזו להם את הגבינה", נאלץ להסתגל ולעבוד על פי מתודולוגיית פיתוח חדשה עבורו, לאחר שהחברה בה הוא עובד ביצעה מעבר משיטת פיתוח המבוססת על מתודולוגיית מפל המים (Waterfall) לפיתוח מבוסס Agile.
הבה נסקור את מתודולוגיות בניהול הפרויקטים הללו, יתרונותיהן, חסרונותיהן וההבדלים ביניהן:
מתודולוגיית מפל המים – Waterfall
מתודולוגיית פיתוח "מסורתית" אשר הוגדרה לראשונה במאמר של ווינסטון רויס ב- 1970, ולפיה שלבי הפרויקט העיקריים מתוזמנים אחד אחרי השני, כל שלב בתורו. ע"פ שיטה זו, אין מתחילים את השלב הבא לפני שהסתיים לו השלב הקודם, כלומר עובדים באופן טורי.
בפרויקט פיתוח תוכנה למשל, יבוצעו התהליכים הבאים באופן עוקב:
כך לדוגמה, על פי המתודולוגיה, בדיקות המסירה לא יתחילו לפני שהסתיים שלב הפיתוח.
הייצוג הגרפי של תיאור תהליך הפיתוח לעיל ממחיש את שם המתודולוגיה – "מפל המים".
שימוש במתודולוגיה זו נעשה בפרויקטים קטנים יחסית, בעלי רמת מורכבות סבירה, כאשר התוצרים מתועדים וברורים כבר בתחילת הפרויקט וכשמדובר בטכנולוגיה מוכרת ובשלה.
במתודולוגיית Waterfall, ניתן משנה תוקף לנתיב הקריטי בפרויקט.
הנתיב הקריטי הינו סט הפעילויות בפרויקט שדחייה של אחת מהן תגרום לדחיית תאריך הסיום של הפרויקט (כלומר הן חסרות גמישות). קביעת הנתיב הקריטי הינה תוצאת חישוב מתמטי המבוצע במערכות ניהול פרויקטים בהתבסס על התלויות בין הפעילויות והאילוצים שנקבעו.
על מנהל הפרויקט לנהל את הפעילויות בנתיב הקריטי בקשב רב תוך וידוא ביצוען על פי התכנון.
בנוסף עליו לנתחו באופן שוטף ולהתייחס גם לפעילויות "כמעט קריטיות" – בעלות גמישות מעטה, העלולות להפוך בעצמן לקריטיות אם ידחו וימצו את גמישותן עד תום.
ולסיכום:
יתרונות בולטים | חסרונות בולטים |
· אינטואיטיבית, קלה להבנה · תכנון ותזמון השלבים בפרויקט פשוטים יחסית, תוך חיזוי מועד סיום הפרויקט · חיזוי עלות הפרויקט ותכנון התקציב פשוטים יחסית | · חוסר גמישות לשינויים בלתי צפויים בדרישות הפרויקט · אינה מתאימה לפרויקט העוסק בטכנולוגיה חדישה/בשלה חלקית |
גישת פיתוח Agile
גישת פיתוח תוכנה הדוגלת בתכנון משתנה על פי תעדוף מתמיד ובגמישות גבוהה לקבלת שינויים ועדכונים לדרישות. כמו כן בבסיסה:
- תהליך פיתוח המתפתח לאורך זמן (החל ממוצר מינימלי חיוני (MVP) וכלה בתוכנה מלאה) תוך ביצוע הדגמות (Demos) לבעלי עניין וקבלת משובים באופן שוטף
- שיפור מתמיד (עקרון חשוב המודגש במתודולוגיית Lean)
גישה זו על 4 ערכיה ו-12 עקרונותיה הנגזרים מהם, הוגדרה לראשונה בשנת 2001 על ידי מפתחי תוכנה מובילים במסמך שנקרא "המניפסט לפיתוח תוכנה ב-Agile" ואשר התבסס על מספר מתודולוגיות פיתוח תוכנה וביניהן כמה מובילות כגון Scrum ו-Kanban.
בבסיס השיטה מס' כלים וטכניקות עבודה:
1. עבודה בצוותים אינטגרטיביים-
צוותי עבודה הכוללים מאפיינים, מפתחים ובודקים. כך למשל, הבודקים שבשיטת Waterfall היו ממתינים לתורם לאחר ביצוע שלב הפיתוח, מעורבים כבר בשלבים מוקדמים בפרויקט תוך היכרות עם המוצר המפותח, כתיבת תכניות ואוטומציות לבדיקה עוד לפני הפיתוח (Test Driven Development).
בכך יש מספר יתרונות בולטים:
- בעבודה על פי Waterfall הבודקים היו סופגים פעמים רבות את איחור אנשי הפיתוח, מאחר ותאריך המסירה ללקוח נותר קשיח. הדבר השפיע ישירות על איכות הבדיקה ועל שחיקת הבודקים
- באג שהתגלה בפרויקט המנוהל על פי Waterfall חוזר למפתח אשר "נגע" בו לפני מספר חודשים. הצורך להיזכר בפרטי הפיתוח הספציפי מביאים לבזבוז זמן רב
2. "שבירת" הדרישות לסיפורי משתמש (User Stories)-
שבירת הדרישות לתכונות (Features) ולסיפורי משתמש (User Stories), כאשר כל סיפור שכזה ניתן לפיתוח ובדיקה באופן עצמאי.
ניתן ונהוג להעריך את משקלו של כל סיפור בימי אדם ולנקד בהתאם (Story Points) – דבר המסייע בחישוב והערכת קצב ההתקדמות לאורך חיי הפרויקט (Burn Down).
שלל הסיפורים נאספים יחד ל- Backlog מרכז ומתועדפים באופן מתמיד. בהתאם מתוזמן מועד יישומם.
3. חתירה למוצר מינימלי חיוני – (MVP (Minimal Viable Product-
עליו ניתן לקבל משוב בונה ובהתאם ניתן להמשיך לפתח ולשפר.
4. עבודה איטרטיבית-
- במתודולוגיית Kanban – ניהול זרם ההתקדמות השוטף כך שקצב ההעברה של סיפור משתמש מה-Backlog ועד סיומו יארך מספר שבועות קבוע (2-4).
- במתודולוגיית Scrum – עבודה בקבועי זמן הקרויים ספרינטים בעלי יעדים ברורים שאורכים אף הם מס' שבועות קבוע (בדרך כלל 2).
· הפחתת הסיכון בפרויקט כתוצאה מתיקוף תוצרים מוקדמים באופן שוטף במהלך הפיתוח · הגדלת הערך ללקוח – o מתן ערך ללקוח משלב מוקדם (MVP) ובאופן שוטף (עבודה איטרטיבית, הצגת Demos) o מעורבות גבוהה של הלקוח וקבלת משוב במהלך הפרויקט · גמישות גבוהה לשינויים תוך כדי הפרויקט · צוותים מעורבים, אינטגרטיביים, עבודה בשיתוף · העבודה מוצגת באופן ויזואלי – · ברור יותר מה נדרש לעשות ומהו סדר העדיפויות לכך | · נדרשת הכשרת הצוותים לעבודה ע"פ שיטה זו, תוך חניכה ושיפור במהלך הפרויקטים הראשונים · יכולת חיזוי פחותה למוצר שיימסר בסופו של דבר · יכולת חיזוי פחותה לגובה העלויות וללוחות זמנים |
ולסיכום.
ובחזרה ליונתן מנהל הפרויקט…
לאחר שסקרנו את 2 השיטות, ניכר כי מנקודת מבטו של מנהל הפרויקט, מעבר ממתודולוגיית Waterfall למתודולוגיה בגישת Agile כרוך בפגיעה ברמת הוודאות של הפרויקט בהיבטי ניצול המשאבים, תזמון המשימות והשלבים העיקריים ובסופו של דבר בתאריך מסירת הפרויקט ללקוח.
בנוסף עליו היה להסתגל, להבין את המתודולוגיה החדשה, לבנות מחדש את הצוותים ולהכשירם.
את יונתן הטרידה במיוחד העובדה כי לא יהיה באפשרותו לתכנן מראש באופן מוחלט וברור, את תאריך מסירת התוכנה ללקוח, כפי שעשה תמיד עד כה.
"האם שכחת בכמה פרויקטים נדרשנו לתכנן מחדש את תוכנית העבודה?" עניתי ליונתן,
"עקב:
- חשיפת תקלות פיתוח משמעותיות שהתגלו בשלב הבדיקות (Showstoppers) או
- כאשר הלקוח התעקש להוסיף או לשנות את אחת מהתכונות שפותחו או
- כשצוות הפיתוח לא עמד בזמנים והתחננו לקבל מהלקוח עוד מספר ימי חסד לדחיית המסירה?"
יונתן, מנהל הפרויקט הבין כי בפרויקטים רבים שניהל, נדרש להגיב לשינויים רבים מסיבות שונות ומגוונות, שינויים שאילצו אותו לעדכן את תוכנית העבודה ולהתאים אותה על פי הצורך.
הוא הבין כי "המשבר" העומד בפניו הוא בעצם הזדמנות.
הזדמנות להטמעת שיטת עבודה המאפשרת להתמודד עם השינויים התכופים המהווים חלק בלתי נפרד מתחום פיתוח התוכנה בפרט ומעולם ניהול הפרויקטים וחיינו בכלל.
מלבד שינוי שיטת הפיתוח, החברה אימצה שיטות עבודה ממתודולוגיית ה- Lean כגון ניהול פגישות רטרוספקטיבה (Retrospective Meetings) שאחד מעקרונותיה הינו "שיפור מתמיד". אחת למספר שבועות נפגש צוות הפרויקט לפעילות הפקת לקחים, שכן מדוע להמתין לסיום הפרויקט אם ניתן לשפר נקודות מסוימות כבר במהלך הביצוע ?
כיום מספר הולך ועולה של חברות, מאמצות את גישת ה- Agile המאפשרת להן לשמור על גמישות וקשב ללקוחותיהן בזמני תגובה קצרים יותר, להציג ללקוחות Demos ומוצרים מינימליים חיוניים בשלבים מוקדמים ולקבל עליהם פידבקים המשוקללים לפעילויות האפיון והפיתוח כמעט בזמן אמת.
כתב: שי צוקר PMP®
