דיברתי עם אחד הלקוחות על הנושא של agile software development. הגורם לשיחה זו היה העובדה שבאותו ארגון פרויקטים רבים מסתיימים באיחור ועוד יותר חמור ישנם פרויקטים שפותחו ומסתבר שלא מתאימים לדרישות הלקוחות. מתודולוגיית agile אמורה להקל בצורה משמעותית על שתי בעיות אלו – עד למצב של פיתוח ב- 50% זמן\עלות!
אולם, לאחר שדנו במקצת בעקרונות המתודולוגיה עצר אותי המנהל ושאל- האם מתחלים לפתח קוד "אמיתי" לפני שביצענו אפיון מפורט ואישרנו אותו על ידי כל הגורמים? ובכן התשובה היא – כן. ב- AGILE לא מגיעים לאפיון מפורט לפני תחילת הפיתוח. הלקוח עצר אותי ולא רצה לשמוע יותר. הוא לא מוכן לפתח אם לא ביצע אפיון מפורט וקיבל אישור מכל הגורמים. לא עזרו ההסברים שלי שזאת כל המהות ב- AGILE . שינוי דינאמי של הדרישות והאפיון הספציפי.
ואכן, כפי שאמרתי בכותרת לפוסט – זריזות מתחילה למעלה- בראשו של המנהל. הפחד מסיטואציה שבה "לא קיבל את האישורים מכל הגורמים" עוצר את הלקוח מכניסה לתהליך שעשוי לשפר בצורה משמעותית את תהליך פיתוח התוכנה בארגון.
אולם, לאחר שדנו במקצת בעקרונות המתודולוגיה עצר אותי המנהל ושאל- האם מתחלים לפתח קוד "אמיתי" לפני שביצענו אפיון מפורט ואישרנו אותו על ידי כל הגורמים? ובכן התשובה היא – כן. ב- AGILE לא מגיעים לאפיון מפורט לפני תחילת הפיתוח. הלקוח עצר אותי ולא רצה לשמוע יותר. הוא לא מוכן לפתח אם לא ביצע אפיון מפורט וקיבל אישור מכל הגורמים. לא עזרו ההסברים שלי שזאת כל המהות ב- AGILE . שינוי דינאמי של הדרישות והאפיון הספציפי.
ואכן, כפי שאמרתי בכותרת לפוסט – זריזות מתחילה למעלה- בראשו של המנהל. הפחד מסיטואציה שבה "לא קיבל את האישורים מכל הגורמים" עוצר את הלקוח מכניסה לתהליך שעשוי לשפר בצורה משמעותית את תהליך פיתוח התוכנה בארגון.
תגובה 1:
אולי הזריזות מתחילה מלמעלה, אך נושא של agile development והתאמתו לסביבה ישראלית - זה לגמרי לא פשוט. בהרבה מקרים שנתקלתי בהם, הפכו את agile לדת של "סיבוב מהיר" מבלי לשמור על מספר עקרונות ברזל של השיטה:
1. כולם עושים הכל: עצוב, פיתוח, אינטגרציה, בדיקות - אם בצוות ה-agile יש חלוקה אישית לפי תפקידים - חבל"ז בלשום העם.
2. אין אגו - כל אחד יכול לתקן את ה-bug שלך. דבר כמעט בלתי אפשרי בארץ שבה "למה מי אתה?" הוא הערך העליון.
3. נוכחות של סמכות הלקוח (product owner) - בד"כ אין כזאת, ואז אנשי פיתוח מקבלים החלטות - אוי לנו...
4. בסוף כל איטרציה יש מערכת עובדת - זה אומר שבדיקות רגרסיה הן חובה. אל רק במקרים מעטים זה קורה - "אנחנו פיתוח - לא בדיקות". מוכר?
5. ואחרון אחרון חביב - ארכיטקטורה. זה נושא כואב מאוד. לכאורה ארכיטקטורה צריכה להוולד בתוך האיטרציות, אבל יש לשמור על כך, כולל השקעה בחיזוק qualities של המוצר/פרויקט כנגן פיתוח של עוד feature כזה או אחר. כשלא מתייחסים לתשתיות תיכון כיאות - הכל נועד לכשלון.
הוסף רשומת תגובה