Posts tagged ‘The Agile Manifesto’

המניפסט האג’ילי לארגונים לא אג’ילים

מעולה !!!!

Manifesto for Half-Arsed Agile Software Development

האם הארגון שלכם גם כזה ?

הרצאה בכנס PMI

image

לאחרונה הצגתי בכנס PMI הרצאה שנותנת מבוא לאג’יל (Agile) וסקראם.

אם אתם מוצאים את זה מעניין, אז הנה לינק למצגת.

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

נשארו עוד ארבעה בסה”כ.

Continuous attention to technical excellence and good design enhances agility.

זהו עקרון מעניין, למה? כי הוא כמעט טריוויאלי, למה למישהו להגיד שאם תקדיש תשומת לב ותמיד תשאף למצויינות טכנית אז יהיה לך יותר פשוט בחיים, ובמקרה הנ”ל יהיה לך יותר קל להיות אג’ילי ?
לדעתי הסיבה שהוכנס הערך הזה כאן הוא ע”מ לבטל אמונה קדומה שקיימת לגבי המטודולוגיות קלות המשקל (lightweight methodologies), האמונה טוענת שבאג’יל לא משקיעים בדיזיין, או שבאג’יל פשוט עובדים במוד של פטצ’ים, אמונה זו כמובן לא נכונה (אי אחת מתוך מספר גדול של הנחות שגויות לגבי אג’יל – הפוסט בקרוב) וכניראה שאותם אנשים נאלצו להתמודד עם הטענה הזו כל הזמן, ולכן לדעתי מצאו צורך כותבי האג’יל מניפסטו לציין את העובדה שיש להשקיע במצויינות טכנית, והשקעה כזו תואמת את תפיסת העולם האג’ילית ואף מחזקת אותה. בנוסף הרי ברור שאם הצד הטכני הוא טוב ואפילו מעולה, אז קל יותר להיות גמישים, להכניס שינויים ולשמור על איכות גבוהה.
נושא נוסף שכדאי לדבר עליו בהקשר הזה הוא החוב הטכני (Technical debt), מדובר על כך שכל פעם כשאנחנו מכניסים “תיקון זמני”, או פתרון מהיר ומלוכלך, או דברים בסגנון אנחנו צוברים חוב טכני, לחוב הטכני הזה יש משמעות אדירה לאיכות התוכנה ובפרט ליכולת שלנו לשנות אותה בעתיד. כמעט בכל תוכנה יש חוב טכני ברמה זו או אחרת, אך אסור לנו להזניח אותו אלא “להחזיר את החוב” ע”י תחזוקה שוטפת של הקוד הקיים תוך שימוש בטכניקות כגון refactoring ותיקון בעיות מיד עם הגילוי.

Simplicity–the art of maximizing the amount of work not done–is essential.

זה אחד העקרונות האהובים עליי ביותר, ואם זאת אחד הקשים ביותר לאימוץ, בעיקר ע”י מהנדסים מנוסים. פשטות כעיקרון, איזה יופי! הרי כבר נאמר כי לבעיות הכי סבוכות בד”כ הפתרונות הם פשוטים במהותם, ואני נוטה להסכים אם אמרה זו. מה המשמעות של פשטות?
הכי טוב שאתן דוגמא: יוסי מקבל משימה לפתח מכונת מצבים בעלת 5 מצבים שמתארת רמזור (אדום, כתום, ירוק , כתום מהבהב, כבוי) ועל הרמזור לשנות מצב כל 10 שניות למצב הבא ובסדר שהוגדר קודם. מה יעשה יוסי, כמובן שקודם כל יחשוב… ויחשוב עוד קצת, ואז, יעלה על הכתב את הדיזיין המדהים שלו למכונת מצבים אבסטרקטית, את המחלקה הג’נרית TrafficLightState שתמומש אחרת לכל State, ואפילו, אם תרצו תוכלו בעתיד להוסיף עוד מצבים, בנוסף לכך את 10 השניות ניתן יהיה להגדיר מתוך קובץ XML מדהים עם סכמה (Scheme), ויהיה ניתן להרחיב את הסכמה בעתיד, מדהים!
אבל רגע, תעצור, לא הגזמנו? אדם שמאמין בפשטות מה היה עושה עבור מכונת מצבים פשוטה של 5 מצבים? משתמש ב-switch case, את הזמן ניתן או להגדיר בקוד או אפילו להרחיק לכת עד כדי העברתו בתור פרמטר לתוכנית. ונניח מגדיר מחלקה למצב הרמזור (או אולי אפילו אינומרציה). אם בעתיד מישהו ירצה לשכלל את המכונה, נשכלל אותה, אבל כרגע הדרישות הן ברורות!
אז למה לבנות חללית כשאנחנו זקוקים לאופניים? זאת המשמעות של פשטות.
שלא תבינו לא נכון, אם היו עשרים מצבים, והרבה זמנים, ומכונה מסובכת, הייתי ממליץ בחום על מכונת מצבים אבסטרקטית, אבל זה לא המקרה.
עיקרון זה רלוונטי גם באספקט של פונקציונאליות במוצר (רק דברים שחייבים, למזער את כמות ה-“רק ליתר ביטחון”, ואף רלוונטי לאספקט של תהליכים, ניתן להשליך את העיקרון הזה על המון דברים נוספים, ואני בטח עוד אכתוב פוסטים רבים בעניין זה.
תקראו עכשיו שוב את המשפט באנגלית בבקשה, אז זהו אחד העקרונות האהובים עליי.

The best architectures, requirements, and designs emerge
from self-organizing teams.

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

At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

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

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

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

הפעם אין הקדמה, נמשיך.

Build projects around motivated individuals. Give them the
environment and support hey need, and trust them to get the job done.

העיקרון הזה מדבר על האנשים ומתחלק לשלושה חלקים, ואני אף,הייתי מפריד אותו.
1. בבסיס התפיסה האג’ילית קיימת ההנחה שללא אנשים מקצוענים, בעלי יכולת גבוהה לא ניתן בכל מקרה להגיע להישגים בתחום שלנו (פיתוח תוכנה), לכן בין השאר קיים העיקרון הזה, הוא מדגיש את החשיבות בבחירת האנשים המתאימים לפרויקט. עקרון זה הוא איננו טריוויאלי שכן ישנן חברות רבות שהקומפוזיציה של צוותים בד”כ נוטה לכיוון שבצוות יש כ-20% של מובילים ועוד 80% של כאלה שיעשו את ה”עבודה השחורה” (על צוותים והרכבם יש לי הרבה מה לומר).
2. ספקו לאנשים העובדים את כל מה שהם צריכים כדי להצליח במשימה, שוב נשמע טריוויאלי אך בד”כ לא ממומש, אני כמעט בטוח שיצא לכם להיתקל בסיטואציות שלא הסכימו לתת תקציב (או אפילו הסכימו אבל עשו את המוות קודם) לדברים קטנים שיכלו לעשות שינוי גדול כגון: החלפת מסך, הוספת זכרון, קורסים וכו’. ההוצאות התקציביות שהזכרתי הן בד”כ השוליים של הוצאות הפיתוח שרובן הן התקורה והאנשים. רק התסכול שנוצר עקב ה”חיסכון” עולה יותר.
3. החלק השלישי והכי לא טריוויאלי הוא לבטוח באנשים, זה לא פשוט אני מודה, אבל זה כדאי. המשמעות של לבטוח באנשים היא לתת להם את החופש לעשות את העבודה כמו שהם חושבים שצריך, לא להתערב להם בהחלטות (אפילו טכניות), אנחנו נדבר עוד הרבה על הנושאים הללו.

The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.

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

Working software is the primary measure of progress.

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

Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.

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

נשארו עוד שלושה עקרונות… בפוסט הבא.

העקרונות האג’ילים – חלק 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.

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

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

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

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