Posts tagged ‘מצוינות’

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

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

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

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