האם שיטת המפל היא אג’ילית ?

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

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

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

הערך הראשון: Individuals and interactions over processes and tools – בשיטת המפל, כפי שאתם יודעים הדרך לפיתוח תוכנה מוגדרת היטב בתהליך הבא: דרישות (Requirements), עיצוב (Design), פיתוח (Implementation), בדיקות (Verification). כבר כאן נשאלת שאלה, האם כל תוכנה יכולה להיות מפותחת בצורה כזאת, למה אי אפשר למשל לבצע Design תוך כדי פיתוח ? או למה אי אפשר לפתח קצת, ואז לבדוק, ועוד קצת פיתוח ואז לבדוק, או חס ושלום לבדוק ממש תוך כדי פיתוח (עיין ערך TDD) ?
בשיטת המפל החלוקה לצוותים היא לפי התמחות, צוות פיתוח, צוות בודקים וכו’, חשבתם פעם כמה אנרגיה מתבזבזת בהעברת הידע בין הצוותים השונים וכמה מידע הולך לאיבוד בתהליך כזה ? כמה פעמים קרה שהבודקים לא בדקו נכון או שהמפתחים לא פיתחו את מה שצריך ? אחת הסיבות היא התהליך. אם יש תהליך ברור ומסמכים ברורים וכך הלאה, אין צורך להשקיע אנרגיה בתקשורת. חבל. בשיטת המפל יש צוות פיתוח, הצוות כפוף לסט של חוקים וכללים שמישהו פעם חשב שמתאים לכולם, האם הוא באמת מתאים לכולם? אני חושב (ויש סטטיסטיקות) שאם יינתן לצוות מידת חופש מסוימת אז אולי הפרודוקטיביות תשתפר.
בשיטת המפל מכינים תוכנית לפני שמתחילים לפתח שמכילה את כל הפרויקט מתחילתו ועד סופו, ניסיתם פעם לשכנע מנהל פרויקט שיש בעיה בתוכנית ואולי הסדר של הפיתוח לא נכון ? השיטה שבה מי שמנהל את הפרויקט אינו מעורב בפיתוח בעייתית. מה הסיכוי של תוכנית כזאת לשקף מציאות ? אפס!
מה שאני אומר שבשיטת המפל האנשים שמפתחים את התוכנה הם בעלי ההשפעה הנמוכה ביותר על ההתנהלות של הפרויקט, בין השאר עקב חוסר “קווי תקשורת ראויים” (ישיבה היא לא תקשורת!), ולכן הרכיב שהוא בעל השפעה קריטית על הצלחת הפרויקט זה התהליך והכלים. כאן הסתירה.

הערך השני: Working software over comprehensive documentation – בהמשך ישיר לערך הקודם, שיטת המפל מכתיבה סוגי מסמכים רבים, אם תסתכלו בהגדרה הרשמית של שיטת המפל תראו שהדבר הראשון שיש להגדיר עבור פרויקט חדש הוא קונספט של המסמכים (Document System Concept), למה ? למה אי אפשר לסכם קווים מנחים למינימום ההכרחי מול הלקוח ולגבי כל השאר לתת חופש לפיתוח להחליט מה הוא צריך ומה לא? אני יודע מה תגידו, שימור ידע. שמעתי על זה.
שאלה: מתי פעם אחרונה פתחתם מסמך שמישהו אחר כתב וממש הבנתם למה הוא התכוון? או אולי כמה זמן השקעתם במסמכים שאף אחד לא קרא? אל תטעו, אני לא טוען שאין צורך במסמכים בכלל, אני טוען שיש להחליט לפי הצורך.התפיסה האג’ילית טוענת שבשביל להצליח בפרויקט תוכנה יש לעשות את המינימום ההכרחי ולא פיפס מעבר. כל מסמך מיותר אינו מקדם את הפרויקט ולהפך.
בשביל למדוד התקדמות של פרויקט אין שום ערך במסמכים, תוכניות וכו’.
הדרך היחידה להבין האם פרויקט מתקדם היא ע”פ מצב התוכנה. בשיטת המפל אומרים שפרויקט הוא 50% כאשר 50% מהתוכנית גמורה, באג’יל טוענים, שפרויקט הוא 50% גמור רק כאשר 50% מהתכולה הם 100% גמורים. ההבדל הוא קריטי. באג’יל אם יש משהו ש-50% מהפיתוח שלו נגמר הוא פשוט לא נחשב. אין ערך באג’יל ל-90% פיתוח או 90% בדיקות, רק 100% נחשב. וזו הסתירה.

הערך השלישי Customer collaboration over contract negotiation: שוב, ולא במקרה בהמשך לסעף הקודם, בשיטת המפל מגדיר הלקוח מראש את התכולה שהוא רוצה, אומרים (מנחשים) כמה זה יעלה לו, ויוצאים לדרך. בסוף מישהו מפסיד (בד”כ כולם). התפיסה האג’ילית אומרת שעקב העובדה שפיתוח תוכנה הוא עסק מורכב ובלתי צפוי יש לערב את הלקוח בכל שלבי הפרויקט, ולתת אפשרות לשנות, ולעדכן את ההערכות (לטובה ולרעה). למה שהוא יסכים? שאלה טובה, אם נסביר לו את מה שהוא כבר יודע (שפרויקטים של תוכנה הם עסק בעייתי) ונציע לו בתמורה גמישות, אפשרות לשנות את התכולה ללא עלות נוספת מעבר למשאבי הפיתוח, בנוסף נציע לו שקיפות מלאה ואמיתית למצבו והתקדמותו של הפרויקט, יכול להיות שזה ימצא חן בעיניו. ניתן לו לאורך כל הפרויקט אפשרות לראות את התוכנה ממש ולתת ביקורת ובקשות לשינוי מבלי לחייב אותו להיצמדות לתכולה המוגדרת בחוזה. וזו הסתירה.
קוריוז: יש היום חברות שלא מוכנות לעבוד עם חברות שאינן Agile ואף יש קרנות הון סיכון שמשקיעות רק בחברות שאימצו את תפיסת העולם האג’ילית.
הנושא הנ”ל מורכב מאוד, ולכן ההסבר כאן הוא שטחי בלבד. אז אני אכתוב פוסט ארוך ומלא רק על עניין הלקוחות בעולם אג’ילי בעתיד.

הערך הרביעי Responding to change over following a plan: הפתעה, ערך זה גם בהמשך לערך הקודם (וזו פעם ראשונה שאני שם לב לכך – תודה שוב ג’וני). אני חושב שלמעשה ערך זה משתקף בכל אחד מהערכים הקודמים ומסכם אותם, ובכל זאת, יש להדגיש כי זאת המשמעות.
להיות מוכן לשינויים, לאהוב אותם! למה? כי הם מוסיפים ערך לקוח (שבשבילו אנחנו עובדים). בשיטת המפל, כפי שאתם כבר יודעים, אין כמעט מקום לשינויים, וכשכבר יש (ובמודל המקורי אין!), אז הם כואבים, ארוכים ויקרים. בעולם האג’ילי שינויים הם חלק מהיום-יום, מי שעובד אג’ילי מברך שינויים, מקבל אותם באהבה, וד”א – מקבל אותם פחות עקב העובדה שלא נכפה על אף אחד להגדיר את הכל מראש. התגובה המהירה לשינוי היא מפתח חשוב להצלחה, בטח בעולם מהיר כמו שלנו. דמיינו לכם פרויקט של חברה סלולארית (ללא ספק תחום דינאמי) שבאמצע הפיתוח מספר דרישות נהיות לא רלוונטיות, מה קורה בשיטת המפל? מפתחים כרגיל, יש תוכנית. הגיוני? לא ממש. באג’יל זה לא קורה, יש שינוי, משנים! הפיתוח לא רלוונטי, מפסיקים ועוברים הלאה.
קיימת טענה נפוצה שבאג’יל לא מתכננים, חד משמעית לא נכון, מתכננים, ואף יותר מבשיטת המפל, התוכניות משתנות ללא כל מאמץ ומספקות תמונה נכונה מאוד של התקדמות הפרויקט. וזו הסתירה. בתכנון אג’ילי עוד נדון רבות בבלוג הזה.

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

6 Responses to “האם שיטת המפל היא אג’ילית ?”

  1. woow says:

    איזה כייף היה לי לקרוא את מה שכתבת, פשוט הזדהתי עם המתודולוגיה האג’ילית עד כדי כך שאני שוקל לקרוא לבת שלי (שתוולד בקרוב ב”ה) – אג’יל.

    תודה חבר יקר.

  2. agileman says:

    קודם כל כיף לשמוע! תודה.,
    אני מחויב לתקן אותך – אג’יל זוהי אינה מתודולוגיה זו דרך חשיבה, ישנן מתודולוגיות שונות שנחשבות אג’יליות – על אחת מהן – סקראם, הבלוג הזה ידבר ממש בקרוב.

  3. woow says:

    קיבלתי והנה התיקון:
    איזה כייף היה לי לקרוא את מה שכתבת, פשוט הזדהתי עם דרך החשיבה האג’ילית עד כדי כך שאני שוקל לקרוא לבת שלי (שתוולד בקרוב ב”ה) – אג’יל, ואי”ה ויגיע גם בן זכר – אקרא לו אג’יל-מן 😀

  4. agileman says:

    אתה טוב אתה 😆

  5. Asi says:

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

    אשמח לתשובתך

  6. agileman says:

    אסי שלום,
    לפי התוכן של השאלה אני מבין שקראת לפחות חלק מהפוסטים האחרים ובמקרה השאלה שלך היא בהקשר של הפוסט הזה, בכל מקרה אני אנסה לענות לשאלתך בקצרה, ובשביל לקבל תשובה “רחבה” יותר אני אכתוב פוסט על תכנון פרויקט בסקראם בעתיד הקרוב.
    כל דרישת לקוח הופכת לפריט ברשימת הדרישות (product backlog), עבור כל פריט כזה ישנם לפחות שני פרמטרים, הערכת מאמצים וערך. באמצעות שני הפרמטרים הללו ניתן לתעדף את המשימות בטכניקות שונות שבד”כ מתבססות על קבלת מקסימום החזר על ההשקעה בשיתוף עם הלקוח (גם על כך אכתוב פוסט), בכל תחילת ספרינט הצוות מתכנס ומתחייב על כמות הפריטים שהוא חושב שהוא מסוגל, אם הפריטים בראש הרשימה גדולים מידי בשביל ספרינט אחד אז מקובל לפצל אותם, המלצתי היא לפצל בצורה כזו שיהיו בין 3-4 פריטים בכל ספרינט (גם על כך צריך פוסט). זה באופן כללי.
    לגבי וידוא שלא פספסנו תכולה, בבסיס הדברים ניצבת ההנחה שמכיון שלא ניתן להגדיר מראש את התכולה המבוקשת, אין דבר כזה למעשה לפספס תכולה, הרשימה של היא דינאמית ואנחנו לא מוחקים ממנה פריטים אלא רק משנים סטטוס ועדיפות, בנוסף היא גלויה ואף בבעלות חלקית של הלקוח אשר מודע לפריטים שפותחו ושעדיין לא פותחו, וכל מה שלא ברשימה, “פוספס”.
    אני מקווה שזה נותן לך תמונה טובה יותר למרות שאני מבין שזה שטחי. ותודה רבה שסיפקת לי רעיוונות לפוסטים חדשים :P.
    אלעד.

    נ.ב. : עם איזה מהפוסטים אתה רוצה שאני אתחיל ?