מתודולוגיות ALM, ניהול מחזור חיי מערכת – מהיכן ולאן?

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

במרוצת 50 השנים האחרונות אנו עדים לעלייתן ונפילתן של מתודולוגיות פיתוח תוכנה וניהול פרויקטים:
● תחילת שנות ה-70' – מתודולוגיות קוויות, כגון: מודל מפל המים.
● אמצע שנות ה-80' – מתודולוגיות איטרטיביות, כגון: המודל הספיראלי.
● אמצע שנות ה-90' – מתודולוגיות איטרטיביות, כגון: מודל Unified Process.
● תחילת שנות ה-2000 – מתודולוגיות זריזות (אג'ייל), כגון: XP (ר"ת Extreme Programming), Scrum.
● תחילת שנות 2010 – מתודולוגיות זריזות, כגון: Continuous Development.
● אמצע שנות 2010 – מתודולוגיה היברידית, כגון: Adaptive Blend.

בנוסף, קיימות בשטח מתודולוגיות מוכרות נוספות: CMMI, מפת"ח, PMBOK, TOC ועוד.

למה כל 10 שנים בממוצע, עולה ופורחת מתודולוגיה חדשה?

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

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

הלב והמוח של טכנולוגיית התקשוב

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

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

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

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

השוואה בין המשפחות. מתוך ויקיפדיה

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

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

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

לא מתחרים – השלמה

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

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

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

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