אני לא נגד אג'ייל. באמת. אבל אני גם לא מאלה שמקבלים דברים כדוגמות מבלי לנסות להבין, והכי חשוב: מבלי להתאים לסביבה שבה הם מיושמים (כבר כתבתי על Context Driven Testing). כשאני רואה שאנשים בלינקדאין קוראים לעצמם Agile Avangelist נהיה לי רע. באמת - האג'ייל כאמונה? מה עם החופש לחשוב?
אני מביא את הדברים השליליים באג'ייל לא בכדי לומר שעלינו להפסיק את השיטה או לחזור לווטרפול. אני חושב שהאג'ייל נתן לנו הרבה, אבל בעיקר את הרעיון שאפשר לנסות דברים שיש בהם היגיון גם אם הם רחוקים ממה שגדלנו לתוכו וממה שנראה כביכול הגיוני.
צוות של גיבורים
כשמתארים אג'ייל מתארים צוות של אנשים חדורי מוטיבציה, חדורי ידע, מקצוענים מהמעלה הראשונה שבאים לעבוד. הכל טוב ויפה, אבל בחיים זה לא עובד ככה. למשל, ירון הבודק בא לעשות את העבודה שלו וללכת הביתה. הוא בודק טוב מהרבה בחינות, אבל הוא לא זה שיחשוב על שיפורים בתהליך, על כלים וכד'. דנה המפתחת היא היחידה שמפתחת ב-C++ בצוות. היא טובה ואכפתית, אבל לא טובה בשינויים ולכן לא תאמץ את הפלטפורמה החדשה והטובה יותר בקרוב. שון המפתח של הפרונטאנד לא אוהב בדיקות, לזה יש בודקים, לא? וליאור הבקאנד רוצה רק לסיים את הפרוייקט ולא חשוב כמה "חוב טכני" (technical debt) הוא ישאיר. אלה מדהימה, אבל ביישנית. היא לא אוהבת לאתגר את מנהל המוצר.
חשוב לציין שהם לא גרועים במה שהם עושים ובסוף הם מדלברים. אבל כצוות הם מקרטעים. מישהו יכול לקפוץ ולומר: נחליף אותם. זה רעיון. אבל נחליף אותם באנשים, ורוב האנשים שונים מהאידאה המושלמת של האג'ייל. ישנה תורה אחרת שסמכה על המוסר של האנשים, וגם בימי הזהר של הקומוניזם ברוסיה היו כאלה שהיו שווים הרבה יותר.
אין ר"צ, יש רטרוספקטיב, אבל אף אחד לא רוצה לומר לירון, בחור חמוד ופגיע, שאפשר טוב יותר. כשאין ר"צ באופן כללי, הטיפול בחוליה החלשה קשה הרבה יותר (וכידוע חוזק השרשרת הוא כחוזק החוליה החלשה שלה). מי בכלל לוקח את האנשים לשיחות הערכה או שיחות שבועיות שמטרתן שיפור? מי קובע שאי-אפשר להמשיך עם עובד מסוים? מי מתגמל עובד טוב?
פתרונות אפשריים
ראש צוות שמבין שהוא "ראשון בין שווים", כלומר נותן לצוות להתנהל ומתערב לא כשלא עושים מה שהוא היה עושה, אלא כשעושים פשוט לא טוב. כמובן שהוא או היא צריכים להדריך ולעזור מתוקף היותם בעלי ניסיון וכד'.
בניית צוות בצורה מאוד מושכלת שס"כ הכישורים שלהם יגרמו לצוות לנוע יפה קדימה תוך עזרה הדדית.
מה קורה כשהבודק לא בא
ואם יש רק אחד מכל דיסציפלינה בצוות, מה קורה כשהוא חולה? העניין הזה מאוד בעייתי כי לא תמיד אפשר להחזיק שניים מכל תחום כי לא תמיד יש עבודה לשניים כאלה. אולי אפשר לעשות העברות של מומחים בין צוותים כך שיהיה לכולם ידע על הכל, ואז אפשר לפחות חלקית "לשאול" מישהו מקביל מצוות דומה שפחות עסוק.
מה קורה כשהבודק לא אוטומטי
לא תמיד מחוסר רצון. לפעמים הוא לא יודע. בנוסף, קשה להתפתח כשיומיים או אפילו ארבעה ימים בספרינט מוקדשים לאוטומציה והשאר לתכנון, אקספלורטורי וכד'.
פתרונות אפשריים
האיכות היא של כולם וגם המפתחים יכולים לעזור.
צוות של מפתחי על
כשבצוות יש רק איש C++ אחד, למשל, לא תמיד יש לו עם מי להתייעץ (כן, גם גוגל לא תמיד צודק/עוזר). אז הוא עושה כמיטב יכולתו. אפילו אם יש ארכיטקט פיתוח וארכיטקט בדיקות - לא תמיד יש כח לקום ולשאול אותם. אז נעבוד ככה ויהיה בסדר. רמז: לא זה לא.
פתרונות אפשריים
שיהיו ארכיטקטים, שיסתובבו בצוותים, יקימו פורומים בחברה וכד'. ראו איך ספוטיפי עובדים.
כשהאג'ייל הופך לתירוץ
Andy Hunt, אחד מאבות המניפסטו, אחד מה-17 המקוריים, טוען כאן שהאג'ייל שממומש כעת אינו מה שהיה להם בראש בעת ניסוח המניפסטו.
אנדי מזכיר שהאג'ייל אמור לקבל את השינוי באהבה תוך שימת לב ללקוח ולשינויים אחרים. אבל הוא מבין שלאנשים חדשים בתחום קשה להבין עקרונות מופשטים, ולכן נותנים להם חוקים שאינם תלויי הקשר. כמו: כשזה קורה, עשה כך וכך. הרבה נתקעים בשלב הזה, כלומר שלב החוקים הקשיחים וזה לא אג'ייל.
אפשר לראות בפועל שהוא צודק כשלפעמים צריך איזו בדיקה קטנה מהצוות בכדי לענות ללקוח וכד', ואז התשובה היא: "תפתח טאסק, נעשה לו גרומינג…". זה לא אג'ייל, אבל זה לפי ה"חוקים".
אנדי ממשיך: האג'ייל נועד להיות משהו שגורם לאנשים לחשוב, אבל יותר קל ללכת לפי החוקים: לא יתפלאו עליך, לא יצחקו ולא יפטרו אותך על זה. קל להישאר באזור הנוחות, אבל האגייל אינו על נוחות. קל לקחת חלק נוח מהחוקים ולומר "אנו עושים אג'ייל". כולם חשים טוב יותר עד שמפספסים את הדליברי.
אפשר לראות בטוויטר יציאות כמ "אבל זה לא לפי חוקי האג'ייל". אבל מה קרה ל"לבדוק ולאמץ"?
אני שואל את עצמי: אבל אם מפשיטים מהאג'ייל את החוקים, מה שנישאר הוא "קונטקס דריבן", לא?
פתרון אפשרי
שמישהו בחברה יקח אחריות על היישום, ישב עם הצוותים ויעזור להם להבין מה שחשוב.
פיתוחים ארוכים ומורכבים
Matthew Kern חושב שזו בכלל קונספירציה של יועצים שהאג'ייל עדיין כאן. יש כאן מלא לינקים, אם אתם רוצים.
במקום אחר הוא נותן סיבות:
האג'ייל מתכוונן ל-GUI ולא למשל לפיתוח של בק-אנד. יש הרבה פיתוחים שאינם מערבים משתמשי קצה.
קל להדביק פתקים ולעבוד על פיהם באפליקציה קטנה, הרבה יותר קשה במערכת מורכבת.
Hayim Makabee מדבר על המיתוסים של האג'ייל ומפשטות-היתר של יישומה. הוא מונה בין היתר את המיתוס שהיכולת לשינוי טמונה רק בצוות, כשלפעמים מראש המערכת אמורה להיות בעלת יכולות של שינוי. גם התקווה שהפיתוחים הקטנים יולידו מוצר מגובש אינה ריאלית ויש לתכנן ארכיטקטורה כללית.
פתרונות אפשריים
אפשר לפתח דברים ארוכים אבל להכניס מיילסטונס, אופס סליחה, לפרק לגורמים קטנים שיכנסו לספרינט.
מלכודת היועצים
Dave Thomas, גם אחד מה-13, חושב שהאג'ייל מת ושרק האינטרסנטים - יועצים - משאירים אותה חיה. המילה "אג'ייל" הפכה לריקה מתוכן. היועצים הם מקור הרעה כי הם חשים שמחובתם להכניס כלים "מתאימים" וכד'. האשמת היועצים הנה מוטיב חוזר בהרבה מאמרים שקראתי. אבל לפעמים פשוט לא מקשיבים להם אם כי מאשימים אותם בסוף.
פתרונות אפשריים
כמו שמתייעצים עם כל בעל מקצוע, בין אם זה השיפוצניק או רופא בכיר או עו"ד, תמיד, אבל תמיד, אנחנו צריכים להחליט מה טוב לנו ומה לא. הם רק יכולים לתת את האספקט המקצועי.
הערכות זמנים וישיבות
אהרון גריי כותב שהסקראם מבוסס על הערכות זמנים, למרות שבלתי אפשרי לחזות זמן פיתוח. בנוסף, לא הגיוני שמפתח יעריך בודק שמעריך מעצב גראפי (או מפתח) וכד'. הוא גם מזכיר את המספר הרב של הישיבות. וכשיש צוות גדול, עניין הישיבות מועצם עוד יותר.
אני חושב שחשוב שכל הצוות יהיה "קומיטד", וגם רטרוספקטיב חשוב. עדיין אולי לא כל הישיבות חשובות ואולי ניתן לצמצם נוכחים.
במאמרה על Mapping Biases to Testing, מאייקה ברינגהוף אומרת שצריך להיזהר מהערכות שמכניסות בכח פיתוחים לתוך ספרינט רק בשביל שיראה טוב.
פתרונות אפשריים
לא להתייחס לספרינט כ"מלך". אם משהו לא הסתיים, נתפח טאסק המשך לספרינט הבא.
מדידות
לדעת אהרון גריי המדידות של האג'ייל, הוא מוסיף בהקשר של ה-burn down charts, לא נותנות כלום מלבד תשובה לשאלה האם צדקנו בהערכות שנתנו. הוא לא מודד את שביעות רצון הלקוח, האם סיפקנו לו את מה שהוא רצה, האם צמצמנו את "החוב הטכני" למינימום וכד'.
סיכום
האג'ייל הוא נקודת פתיחה טובה. אבל לפני היישום, כדאי לקרוא, לראות איך זה עובד בחברות אחרות, להתייעץ, אבל מאוד חשוב לראות איך זה משתלב בארגון שלכם. מהי התרבות הארגונית? איך העובדים יקדמו את השינוי? מה כדאי לקחת "כלשונו" ומה כדאי להתאים / לשפר? ועוד (אני לא מתעכב כי מטרת המאמר אינה פרישת היישום של הרג'ייל אלא נקודות למחשבה. יש מספיק חומר מאנשים שמכירים את הנושא טוב ממני ברשת).
אבל הכי חשוב, כשמתחיל היישום, להיות עם עיניים פתוחות ולשפר כל הזמן. לא לפחד לטעות, ולא לפחד להודות בטעות. גם לא לפחד מפתרונות לא קונבנציונלים.
אין תגובות:
הוסף רשומת תגובה