העקרונות האג’ילים – חלק 1.

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

Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.

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

Welcome changing requirements, even late in development
Agile processes harness change for the customer’s competitive advantage.

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

Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.

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

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

Business people and developers must work together daily throughout the project.

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

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

6 Responses to “העקרונות האג’ילים – חלק 1.”

  1. Johny K says:

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

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

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

  2. agileman says:

    ידידי היקר, זאת נקודה מאוד מענינת.
    אין לי ספק שיש צדק חלקי בדבריך ואכן יש הבדלים בין התנהלות של חברות צעירות לחברות גדולות, וכניראה שסטארט אפים הם יותר גמישים ופחות בירוקרטים אבל, וזה אבל גדול, רוב חברות הסטארט אפ לא עובדות לפי שיטת המפל, או לפי איזושהיא שיטה, ולכן נדמה כי זה ההבדל, אבל רוב הפיתוח בעולם מתבצע בחברות גדולות, וגם לצערי (וזה הולך ומשתנה) הרוב עובדים בשיטת המפל.
    ובשיטת המפל ידידי – “ימבה” בירוקרטיה, וזאת אחת הבעיות בא (ראה ערך אג’ילי שני) כך שלמעזה אם אתה טוען שבירוקרטיה היא מכשול אתה מדגיש חיסרון בשיטת המפל.
    בנוסף, אם קראת בתשומת לב ראית מספר דברים שלטעמי ומנסיוני לא תמצא גם בחברות קטנות, כגון (ציטוטים מהפוסטים):
    “אנשי פיתוח לא אוהבים שינויים במהלך הפרויקט” – מנסיוני גם בסטארט אפ
    “תוכנה עובדת היא המדד הנכון ביותר להתקדמותו של הפרויקט, וכמובן הלקוח מקבל שקיפות מלאה למדד הזה” – מנסיוני זה לא עובד ככה גם בסטארט אפ.
    “בשיטת המפל האנשים שמפתחים את התוכנה הם בעלי ההשפעה הנמוכה ביותר על ההתנהלות של הפרויקט” – מנסיוני זה ככה גם בסטארט אפ
    ואולי השוני הכי מהותי שהוזכר עד עתה: “בשיטת המפל אומרים שפרויקט הוא 50% כאשר 50% מהתוכנית גמורה, באג’יל טוענים, שפרויקט הוא 50% גמור רק כאשר 50% מהתכולה הם 100% גמור”
    נקודה נוספת : “תיקח את עצמך (מתכנת אג’ילי) שים עליך חמישה מנהלים” – אין מתכנת אג’ילי עם חמישה מנהלים שדורשים דוחות, הוא פשוט לא אג’ילי! התפיסה האג’ילית לא עוצרת בפיתוח, היא רלוונטית לכל האירגון.
    אבל נסחפתי גם ככה עם התגובה (אולי אני אכתוב פוסט בנושא – אתה טוב אתה!)

  3. גיא says:

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

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

  4. agileman says:

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

  5. מידע מדהים, הרבה תודות לכותב המאמר. זה מובן לי עכשיו, את היעילות ואת החשיבות היא מזעזעת את הנפש. תודה שוב ובהצלחה!

  6. לא רלוונטי says:

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