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

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

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

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

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

  1. micha says:

    i read your description of agile methods principals
    and it seems ive been agile my entire career without even knowing this :)
    which makes me wonder if this description is like a horoscope no matter which sign you decide to read it fits because its so general it has no real meaning, how many nasty evil waterfall followers will disagree with one of those principals?

  2. agileman says:

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

  3. micha says:

    i think you misunderstood me :)
    i dont like the waterfall system ,as a whole i think the development methodology greatly depends on the product and the personal involved

    my point was:
    i can write a manifest that say
    1)write good code
    2)build products that sell
    etc
    every1 will agree that this are good principals but they are meaningless because they are too wide

    as for your questions:
    a team that runs itself – most of my teams run themselves except the team i had in japan

    generic code – there is a hidden assumption that generic code is harder to write then specific code i do not agree with this assumption
    the example of the street light showed me that i don’t agree with you on what is generic code.

    minimalistic processes – the question is not fully defined

    release dates -not every month, some products we built had to have a larger initial development time since the core activity was not composed of a series of small beneficial activities
    on projects where there are a lot of customers releasing a version every month can cause unnecessary mayhem and make versioning harder then it should be
    this is why on those products you use the version/service pack/hot fix scheme

    team self examining- depends on the size of the team

    documentation – i hate documentation and try to write as little as possible

    team composition – on small teams yes every1 should be experts on big teams no

    requests -depends who is requesting if its a customer i evaluate the request before answering if its a product manager i say no 3 times and if he keeps asking i evaluate the request

    can you find one waterfall follower that wouldn’t agree with one of the above principals?

  4. agileman says:

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

  5. micha says:

    regarding clients,there are products that are developed to a specific client or a small group of clients and there are products that are ment for a higher volume of clients
    in the first case the client is king what he say goes
    in the second case the client is just one out of many what he says might not fit every1 so you need to consider it first for example if i send microsoft a request that the deafult screen saver will be “none” it doesnt mean they have to listen to me.

    regarding interfacing with marketing thats a complex issue it mainly depends on the personal involved, if you say ok to every feature p.m request you end up with a big mess – try to think of it in game theory tools,it costs a lot less to request a feature then to implement it. in theory you and the p.m have the same “economy” but in practice it is not the case

    as for agreeing with the concepts its all a matter of phrasing
    the concepts have been phrased in a way every1 can accept them

    and last agreeing does not mean implementing
    implementing is the art of managing :)

    dont get me wrong i think agile methods have the right concept
    but they usually come with strict patterns that i strongly object too like 5 minute standing meetings or fixed time frames for evaluation
    when you start discussing the dirty details of actually managing a team we can go into that :)

  6. דודו says:

    Any software development task can be approached with a host of methods. In an agile project, it’s particularly important to use simple approaches, because they’re easier to change. It’s easier to add something to a process that’s too simple than it is to take something away from a process that’s too complicated. Hence, there’s a strong taste of minimalism in all the agile methods. Include only what everybody needs rather than what anybody needs, to make it easier for teams to add something that addresses their own particular needs.

    “Simple, clear purpose and principles give rise to complex, intelligent behavior,” says Dee Hock, former CEO of Visa International. “Complex rules and regulations give rise to simple, stupid behavior.” No methodology can ever address all the complexity of a modern software project. Giving people a simple set of rules and encouraging their creativity will produce far better outcomes than imposing complex, rigid regulations.