Posts in מה זה בכלל Agile

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

בתגובה לפוסט הקודם, שאל ג’וני, ובצדק רב ” מה היא הסתירה בין העקרונות של אג’יל (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: הפתעה, ערך זה גם בהמשך לערך הקודם (וזו פעם ראשונה שאני שם לב לכך – תודה שוב ג’וני). אני חושב שלמעשה ערך זה משתקף בכל אחד מהערכים הקודמים ומסכם אותם, ובכל זאת, יש להדגיש כי זאת המשמעות.
להיות מוכן לשינויים, לאהוב אותם! למה? כי הם מוסיפים ערך לקוח (שבשבילו אנחנו עובדים). בשיטת המפל, כפי שאתם כבר יודעים, אין כמעט מקום לשינויים, וכשכבר יש (ובמודל המקורי אין!), אז הם כואבים, ארוכים ויקרים. בעולם האג’ילי שינויים הם חלק מהיום-יום, מי שעובד אג’ילי מברך שינויים, מקבל אותם באהבה, וד”א – מקבל אותם פחות עקב העובדה שלא נכפה על אף אחד להגדיר את הכל מראש. התגובה המהירה לשינוי היא מפתח חשוב להצלחה, בטח בעולם מהיר כמו שלנו. דמיינו לכם פרויקט של חברה סלולארית (ללא ספק תחום דינאמי) שבאמצע הפיתוח מספר דרישות נהיות לא רלוונטיות, מה קורה בשיטת המפל? מפתחים כרגיל, יש תוכנית. הגיוני? לא ממש. באג’יל זה לא קורה, יש שינוי, משנים! הפיתוח לא רלוונטי, מפסיקים ועוברים הלאה.
קיימת טענה נפוצה שבאג’יל לא מתכננים, חד משמעית לא נכון, מתכננים, ואף יותר מבשיטת המפל, התוכניות משתנות ללא כל מאמץ ומספקות תמונה נכונה מאוד של התקדמות הפרויקט. וזו הסתירה. בתכנון אג’ילי עוד נדון רבות בבלוג הזה.

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

מה זה אג’יל – Agile?

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

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

אז מה זה Agile ? נתחיל בהגדרה המילונית :

ag·ile – adj
1. Characterized by quickness, lightness, and ease of movement; nimble.
2. Mentally quick or alert: an agile mind

מדובר במילה שמתארת גמישות וזריזות, המילה מוזכרת בעיקר בהקשרים לכלי רכב ובעלי חיים.
מתי המילה הזאת הפכה להיות רלוונטית לעולם התוכנה ?
מעשה שהיה כך היה: בפברואר 2001 התכנסו 17 אנשים שנחשבו מובילי דעת בעולם התוכנה באתר סקי ביוטה (יוטה ? כן, יש מקום כזה), כדי לדון בנושא מתודולוגיות של פיתוח תוכנה. האנשים שנפגשו היו מובילים בתחום של תפיסות פיתוח מודרניות (XP,Scrum,FDD,XBreed,DSDM ועוד) וניסו למצוא מכנה משותף כדי לקדם את הרעיונות שלהם. אני עוד אזכיר חלק מהם בבלוג באופן ספציפי.
כמובן, שאין כמעט שום סיכוי ש-17 אנשים יסכימו על מתודולוגיה אחת, בעיקר בהתחשב בעובדה שרובם נחשבו לממציאים של מתודולוגיות. אז הם התווכחו והתווכחו, והתווכחו עוד קצת, ואז, תאמינו או לא, הם הצליחו להסכים (גם הם לא האמינו) על משהו משמעותי ובעל תוכן לעולם התוכנה.
לדבר הזה קוראים – The Agile Manifesto, המניפסט הזה הוא למעשה הפעם הראשונה הגדירו מהו תהליך נכון לפיתוח תוכנה ע”י ערכים(Values) ועקרונות(Principles), ולא ע”י תהליך.
העקרונות הללו למעשה היו מקובלים על כל 17 הנציגים שחתומים על המניפסט, ושמייצגים שיטות שונות לפיתוח תוכנה.
ההבנה המשותפת הייתה, בין השאר, כי בעולם התוכנה כיום, אין מקום למתודולוגיה “כבדה” כי אם רק למתודולוגיות “קלות” אשר משאירות המון מקום לגמישות.

העקרונות עליהם הם הסכימו הם כלליים אך מעבירים מסרים חדים וברורים.

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

  • Individuals and interactions over processes and tools – זה הערך הראשון שטוען שבמקום למצוא כלים טובים ותהליכים מורכבים, צריך אנשים טובים ותשתית נכונה לתקשורת בין אותם אנשים. לדוגמא – סקרים מראים כי הבדלי התפוקה בין מתכנתים שונים יכול להיות פי 20 ואף יותר, אז נגיד שג’ון עושה עשירית מדני, האם המשכורת של ג’ון היא 10% מדני? האם לא כדאי להביא עוד דני במקום 2 ג’ון ? או לחילופין להשקיע בג’ון כך שיצטמצמו הפערים? אני יודע שאני מושך אש אך עוד נדון בעניין זה לעומקו (כמו בכל האחרים).
  • Working software over comprehensive documentation – הערך הזה לא אומר שאין צורך במסמכים, מה שהוא כן אומר זה שאין צורך במסמכים שאין בהם צורך! “יעני” במקום לתכנן הכל ולנסות להבין את הכל מראש, בואו נתכנן רק מה שצריך, נתחיל לעבוד (וללמוד תוך כדי), בואו נראה תוצאות ומהר, רק כך נדע מה מצבנו.
  • Customer collaboration over contract negotiation – ערך זה מדגיש את הצורך בשיתוף פעולה הדוק עם הלקוח, שיש לייצר מערכת יחסים עם הלקוח שמבוססת על אמון הדדי, לייצר מצבי win-win ולא משחקי סכום אפס. אני לא אומר שזה פשוט, אני אומר שזה חשוב!
  • Responding to change over following a plan – הערך הזה בא להדגיש את החשיבות בגמישות בפיתוח תוכנה, את אי היכולת לחזות את העתיד (גם לספק וגם ללקוח), את הערך הגדול במתן אפשרות לשינויים בזמן אמת – שינויים בדרישות, בסביבה, בפיצ’רים וכו’. הוא מדגשי את החשיבות בעדכון התוכניות באופן רציף ובהבנה אמיתית של התקדמות הפרויקט, זה דווקא פשוט יחסית למימוש!
  • לסיום כתוב שם :
    That is, while there is value in the items on
    the right, we value the items on the left more.

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

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

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