יותר ויותר חברות עוברות משיטת ניהול פרויקטים רגילה (WATERFALL) לשיטות חדשניות כמו AGILE-SCRUM, AGILE-XP וכדומה. כתבה זו מתארת בקצרה את הסיבות לתופעה זו כולל הסבר למי שטרם שמע על שיטות ה-AGILE.
פרויקטים גדולים ובינוניים במאה ה-20 היו מתנהלים אם לא כולם, אז רבם לפי שיטת Waterfall, ז"א מראש קבעו את התקציב, את הלו"ז, את הצוותים לביצוע וכו'. מאז שכל החלטות הנ"ל התקבלו, הפרויקט רץ עד הסוף, כאשר לקוח וספק בדרך כלל נפגשים רק בסוף כאשר הפרויקט מוכן לביצוע. אבל מה, אז מתבר שמה שבוצע בפועל לא בדיוק מתאים למציאות החדשה או לא לכך התכוון המשורר. יתרה מכך, אם התקציב מסיבות כאלו ואחרות נגמר באמצע, הפרויקט היה עוצר והלקוח לא היה מקבל שום תוצר. רב המחקרים הציגו מספרים בין 60% ל-80% לפרויקטים שנכשלו באחד או יותר מהפרמטרים הבאים: לו"ז, תקציב, תכולה. ז"א או שהפרויקט יצא מהתקציב המתוכנן, או שנמשך יותר מהמתוכנן, או שהתכולה הייתה קטנה יותר ממה שתוכנן בתחילת הפרויקט. אפשר לדבר על הרבה סיבות לכישלון, אך מספיק להסתכל על החיים שלנו כדי להבין שלא כך אנחנו עושים פרוקיטים בחיים האישיים. ולמה? כי אנחנו מתאימים את עצמינו, את המטרות ואת הדרך להשגת מטרות בחיים על פי המציאות המשתנה. אנחנו עושים זאת ברב המקרים לפעמים בלי לשים לב ולפעמים במודע. להלן כמה דוגמאות לכך:
מתכננים טיול משפחתי לחו"ל. זה כולל אותם מרכיבים כמו במקרה של פרויקט תעשיה: לו"ז חופשה, תקציב, לאן נוסעים ולמה (מטרות), מה נדרש לעשות בשביל הטיול המוצלח, מי יעשה מה בין המטלות הנדרשות. הכל הולך טוב ויפה עד שמגלים סיבה או סיבות המפריעות לטיול: עבודה דחופה שלא מאפשרת חופש בלו"ז המתוכנן, מחלה של מישהו מהנוסעים, הכסף הלך למטרה יותר חשובה, אין כרטיסים\מקומות לאותה התקופה בנקודת היעד... אז מה עושים? עושים תיקונים נדרשים על פי המציאות החדשה: דוחים טיול, נוסעים למקום אחר, לא נוסעים כלל ובמקום זה עושים פעילות אחרת. כל זה מחליטים באותו זמן בדיוק כשנודע על הבעיה. לא כך בשיטת ה-waterfall שבה לקוח לא ידע על בעיות אצל ספק וספק לא ידע על בעיות של לקוח , וכאשר הבעיות התגלו לא ניתן היה לתקן זאת מבלי לגרום נזק כבד לפרויקט.
אז מה מציעות השיטות החדשות מבוססות AGILE בשביל למנוע את המצב הלא נעים שכזה? נתחיל בלינק פשוט שמתאר את השיטה, את היוצרים ואת ההתפתחות של שיטת ה-AGILE:
http://en.wikipedia.org/wiki/Agile_software_development
ובעברית:
http://he.wikipedia.org/wiki/%D7%A4%D7%99%D7%AA%D7%95%D7%97_%D7%AA%D7%95%D7%9B%D7%A0%D7%94_%D7%96%D7%A8%D7%99%D7%96
למי שאין לו כוח לקרוא את הכתבות, להלן ארבע נקודות עיקריות שמאפיינות את שיטת ה-AGILE:
- ביצוע פרויקט באיטרציות קצרות טווח (בין שבוע לחודש מקסימום).
- סוף כל איטרציה - מוצר מוכן! - גם אם יש בו תכונה אחת או חלק קטן מהתכולה הכוללת.
- לקוח משתתף ופעיל בכל שלבי הביצוע, יודע על בעיות ומשתתף במתן פיתרון לבעיות.
- מותר(!) לשנות תכולה, עדיפויות, תקציב ולו"ז לכל איטרציה הבאה, ז"א רק האיטרציה הנוכחית היא "קדושה" (וגם זה יחסית), כל השאר איטרמיות מותר לשנות.
כמובן, הדגשים שעשיתי הם רק חלק מהמאפיינים לשיטת ה-AGILE, ובפועל יש מה ללמוד לפני שמתחילים ליישם את השיטות החדשות לניהול פרויקטים. ובכל זאת, יותר ויותר חברות היי-טק (ולא רק הן!) עוברות לשיטות ה-AGILE גם בארץ וגם בחו"ל על מנת לחסות בעלויות, לחוש את השינויים ולהגיב בזמן לשוק המשתנה כל כך מהר בעידן המודרני.