זהו החלק השני של המאמר, הראשון נמצא כאן.
הבטחתי שהפעם נדבר על מדידת ו-ROI של אוטומציה, מקווה שלא לקחתם אותי ברצינות. תתגברו נמשיך הלאה באסטרטגיה של פרויקט אוטומציה.
נתחיל בכך שחשוב שכל אם עברייה תדע: פיתוח תשתיות אוטומציה זה פיתוח לכל דבר ועניין. וצריך להתייחס לזה ככזה. לא משנה באיזו שיטה אתם מפתחים, כדאי לשקול ששיטת פיתוח תשתיות האוטומציה תהיה אג'ייל כלשהו, קנבן אם אפשר. מעבר לשלל היתרונות של השיטה, כאן הלקוח (כלומר אנחנו) מעורב לאורך כל הפרוייקט. היתרון ברור אל מול פיתוח ארוך של תשתיות: בדמו/review נראה מה פותח, ונקבל עוד יכולות ותוכנה עובדת באופן אינקרימנטלי כך שטעות אם תהיה תהיה קטנה והפידבק יהיה מיידי.
לפיתוח תשתיות האוטומציה יש scrum master וגם product owner (אם הם מבקשים יפה אפילו לוח קאנבן :) ).
--------------------------------------------------------------------------------------------------------------- סיפור מהחיים: כשהייתי בחברת קומברס קיבלתי לידי ניהול של צוות אוטומציה. ידעתי שיהיה קשה כיוון שכבר ארבעה מנהלים עזבו את ניהול הצוות. מנהלת הצוות הייתה אחת שיודעת, כלומר שלא צריכה שום עצה מאף אחד, ומפתחות האוטומציה די חששו ממנה. המנהלת לא הייתה מוכנה בשום פנים ואופן ללמוד דבר על המערכת, קטן ככל שיהיה. זו היתה גישה מודעת ואורח חיים. בשביל לשנות קונפיגורציה פשוטה, דבר שכל בודק אחרי חודש בחברה הכיר, הן היו מתקשרות לבודקים ומבקשות מהם שישנו. התחלתי את תפקידי בזה שנתתי להן אפשרות להכיר את המערכת, לפחות טכנית. זה לא עבד, והמנהל שלי, שהביא אותן ופרש עליהן את חסותו, הפך אותי לסטטיסטיקה - המנהל החמישי שעזב את הצוות. מה היו הבעיות?
זן ואומנות המלחמה בפיתוח אוטומציהזן ואומנות המלחמה בפיתוח אוטומציה
ברגע שיש החלטה כל הפיתוח בחברה (במובן הרחב - מתכנתים, בודקים, מנהלי מוצר, מנהלי פרויקטים וכד') צריכים להבין שהם מחוייבים לא משנה כמה זה פחות מעניין או לא מבטיח.
זה אומר שמתכנתים יושבים עם אנשי האוטומציה, לפעמים ימים, מסבירים להם על המוצר מבחינה טכנולוגית (מודלים, תהליכים, הצצה בקוד), עושים refactor לקוד בכדי שיתמוך באוטומציה (ומשנים גישה מאותו רגע לכיוון של תמיכה באוטומציה) ויהיה טסטבילי.
מעבר למידע הייתי מצרף מפתחים לפרוייקט, גם כדי שהפרויקט יתקדם מהר יותר, גם כגיבוי לעת הצורך, גם כי מתכנתים בודקים ואחראים על האיכות לא פחות מאיתנו וגם שיבינו יותר טוב את צרכי האוטומציה כשיחזרו לקודד את המוצר.
זה אומר שמנהלי פרויקטים מקבלים הוראה חד משמעית (מצטער, אני לא סומך עליהם שיבינו לבד את הצרכים בטווח הבינוני של החברה) להכניס ללוחות הזמנים את פיתוח האוטומציה (מפתחים, בודקים וכד').
זה אומר שבבק-לוג יש משימות אוטומציה שעוברות גרומינג והערכות זמן, ונכנסות לספרינט כמו כל טאסק.
וזה אומר שבודקים צריכים לקבל ידע בסיסי (או יותר) בקידוד. זה לא יבוא מהאוויר - כדאי לארגן קורסים.
גם קידוד למי שאינו תכניתן, של פעם בשבוע, לא יהיה יעיל כיוון שהבודק יסבול מרגרסיות (הייתי חייב). צריך לפחות שעתיים ביום בכדי שהכישורים ישמרו ויתפתחו.
זה כמובן לא מסיר את האחריות מהבודקים לפעול אקטיבית בכדי ללמוד את היכולת הזו.
גם אומר לשבת עם אנשי התשתיות ולעזור להם.
--------------------------------------------------------------------------------------------------------------- סיפור מהחיים: בסניף הישראלי של חברת AVG במחלקה של האפליקציות הסלולריות היה צוות תשתיות אוטומציה. אמנם הצוות ישב בנפרד, אבל הכיר היטב את האפליקציה (שהיתה די מורכבת) ואת הפן הטכנולוגי. גם כאן היו שינויי תשתיות אבל לא מבחירה לא נכונה, אלא טכנולוגיה שהשתנתה כאשר הבחירה המקורית לא ענתה עליהם (Robotium הוחלף ובמקומו הובא Appium). אני רואה את השינוי הזה דוקא כדבר טוב שמראה שלא נשארים עם משהו רק בגלל אינרציה. נבנו building blocks שדי כיסו את המוצר. בנוסף הצוות ארגן קורס פייתון לבודקים. המפתחים בצוות עודדו שתו"פ והבינו שהם נותני שירות. יחד עם זאת, לא כל צוותי הסקראם רצו לקבל אוטומציה או לפחות לעשות את המאמץ שיש בזה. לכן חלק מהצוותים התקדמו וחלק - פחות.
---------------------------------------------------------------------------------------------------------------
מהם הצעדים ליצירת פרוייקט אוטומציה מוצלח?
תלוי בארגון ובהיקף (כי הכל הוא תלוי הקשר), אבל הנה דרך אחת:
עוד נקודות מאוד מעניינות של ג'יימס באך ומייקל בולטון ניתן לקרוא כאן (שקלו לקרוא את המאמר המקורי).
בחלק השלישי נדבר על מדידות של אוטומציה ו-Return of Investment.
--------------------------------------------------------------------------------------------------------------- סיפור מהחיים: כשהייתי בחברת קומברס קיבלתי לידי ניהול של צוות אוטומציה. ידעתי שיהיה קשה כיוון שכבר ארבעה מנהלים עזבו את ניהול הצוות. מנהלת הצוות הייתה אחת שיודעת, כלומר שלא צריכה שום עצה מאף אחד, ומפתחות האוטומציה די חששו ממנה. המנהלת לא הייתה מוכנה בשום פנים ואופן ללמוד דבר על המערכת, קטן ככל שיהיה. זו היתה גישה מודעת ואורח חיים. בשביל לשנות קונפיגורציה פשוטה, דבר שכל בודק אחרי חודש בחברה הכיר, הן היו מתקשרות לבודקים ומבקשות מהם שישנו. התחלתי את תפקידי בזה שנתתי להן אפשרות להכיר את המערכת, לפחות טכנית. זה לא עבד, והמנהל שלי, שהביא אותן ופרש עליהן את חסותו, הפך אותי לסטטיסטיקה - המנהל החמישי שעזב את הצוות. מה היו הבעיות?
- בגלל שלא הכירו את המערכת הן פיתחו תשתיות לא מתאימות לתקשורת, ולאחר שנה של כתיבת קוד הכל נזרק והתחיל מחדש.
- שנה אחרי הזריקה כשהגעתי לא היה שום דבר שאפשר להראות.
- היותן מנותקות מסביבת הפיתוח-בדיקות פיזית וחברותית.
- בעיקר חוסר ההכרה של המערכת.
- הן היו מקובעות וחסרות רצון להתפתח.
- וכמובן הגיבוי המוחלט מהמנהל.
גיבוי של החברה
בגלל שחברות רבות מתעלמות ממה שכתבתי כאן למעלה ובחלק הראשון, כנראה שרוב פרויקטי האוטומציה נכשלים (ראיתם סטטיסטיקה בכתבה הקודמת על כמות הבדיקות האוטומטיות שעובדות). דבר זה גורם (ובמידה מסוימת אפשר להבין) לחוסר אמון באוטומציה. כמו מנהלים (ואחרים) שחושבים שתוך חודשים ספורים הכל יהיה אוטומטי, כך גם אלה שחושבים שאין שום מצב שאוטומציה תעבוד טועים (אלא אם מדובר במצב מאוד מסוים).
לכן אם מחליטים להתחיל תהליך של כתיבת תשתיות ואוטומציה, ההנהלה צריכה להבין (ומתפקידנו ליידע אותה) שזה תהליך שיקח זמן, שיעלה כסף, ומה הוא יכול לעשות (לאמת) ומה לא (לבדוק) ותוך המגבלות הללו הוא יכול לעשות הרבה. תיאום ציפיות.
ההנהלה צריכה להיות אקטיבית ולדחוף לכך, גם בקרב צוותים שלא מאמינים בזה (מצד שני כאמור כשבונים את זה נכון ומתחילים בסמוק טסטס - זה יחסוך לפיתוח עבודה. אני בטוח שברוב המקרים כשיש הוכחה בשטח של משהו שמוריד לך עבודה האמון יעלה).
זן ואומנות המלחמה בפיתוח אוטומציהזן ואומנות המלחמה בפיתוח אוטומציה
ברגע שיש החלטה כל הפיתוח בחברה (במובן הרחב - מתכנתים, בודקים, מנהלי מוצר, מנהלי פרויקטים וכד') צריכים להבין שהם מחוייבים לא משנה כמה זה פחות מעניין או לא מבטיח.
זה אומר שמתכנתים יושבים עם אנשי האוטומציה, לפעמים ימים, מסבירים להם על המוצר מבחינה טכנולוגית (מודלים, תהליכים, הצצה בקוד), עושים refactor לקוד בכדי שיתמוך באוטומציה (ומשנים גישה מאותו רגע לכיוון של תמיכה באוטומציה) ויהיה טסטבילי.
מעבר למידע הייתי מצרף מפתחים לפרוייקט, גם כדי שהפרויקט יתקדם מהר יותר, גם כגיבוי לעת הצורך, גם כי מתכנתים בודקים ואחראים על האיכות לא פחות מאיתנו וגם שיבינו יותר טוב את צרכי האוטומציה כשיחזרו לקודד את המוצר.
זה אומר שמנהלי פרויקטים מקבלים הוראה חד משמעית (מצטער, אני לא סומך עליהם שיבינו לבד את הצרכים בטווח הבינוני של החברה) להכניס ללוחות הזמנים את פיתוח האוטומציה (מפתחים, בודקים וכד').
זה אומר שבבק-לוג יש משימות אוטומציה שעוברות גרומינג והערכות זמן, ונכנסות לספרינט כמו כל טאסק.
וזה אומר שבודקים צריכים לקבל ידע בסיסי (או יותר) בקידוד. זה לא יבוא מהאוויר - כדאי לארגן קורסים.
גם קידוד למי שאינו תכניתן, של פעם בשבוע, לא יהיה יעיל כיוון שהבודק יסבול מרגרסיות (הייתי חייב). צריך לפחות שעתיים ביום בכדי שהכישורים ישמרו ויתפתחו.
זה כמובן לא מסיר את האחריות מהבודקים לפעול אקטיבית בכדי ללמוד את היכולת הזו.
גם אומר לשבת עם אנשי התשתיות ולעזור להם.--------------------------------------------------------------------------------------------------------------- סיפור מהחיים: בסניף הישראלי של חברת AVG במחלקה של האפליקציות הסלולריות היה צוות תשתיות אוטומציה. אמנם הצוות ישב בנפרד, אבל הכיר היטב את האפליקציה (שהיתה די מורכבת) ואת הפן הטכנולוגי. גם כאן היו שינויי תשתיות אבל לא מבחירה לא נכונה, אלא טכנולוגיה שהשתנתה כאשר הבחירה המקורית לא ענתה עליהם (Robotium הוחלף ובמקומו הובא Appium). אני רואה את השינוי הזה דוקא כדבר טוב שמראה שלא נשארים עם משהו רק בגלל אינרציה. נבנו building blocks שדי כיסו את המוצר. בנוסף הצוות ארגן קורס פייתון לבודקים. המפתחים בצוות עודדו שתו"פ והבינו שהם נותני שירות. יחד עם זאת, לא כל צוותי הסקראם רצו לקבל אוטומציה או לפחות לעשות את המאמץ שיש בזה. לכן חלק מהצוותים התקדמו וחלק - פחות.
---------------------------------------------------------------------------------------------------------------
- אם אין לכם מומחים קחו חברה חיצונית, וביחד תנסו להבין האם יש סיכוי ותמורה לפרוייקט אוטומציה (מבחינת המוצר עצנו, מורכבותו, כלים שיעבדו איתו, הרכב הבודקים בחברה - יודעים לכתוב סקריטפים או לא, מספרם וכד').
- עם ההערכה הזו לכו להנהלה והיו כמה שיותר ברורים ואמיתיים.
- גייסו או פנו ליועץ חיצוני שמבין בתחום. שקלו להחזיק ארכיטקט אוטומציה שיעזור בבחירת הכלי הנכון, שתהיה לו אסטרטגיה ברורה של אוטומציה, יתמוך בפיתוח ויהיה בעל חזון (עם רגליים בקרקע).
- בחרו בכלים ובשפות הנכונות.
- אם יש הפרדה של תשתיות ובודקים שגם כותבים קוד, תתחילו להדריך את הבודקים (קוד, תפקיד האוטומציה, כלים וכד').
- יצירת פריימוורק מתאים. במיטאפ של מטריקס שבו השתתפתי כצופה למדתי שככל שהבודקים פחות שולטים בקוד כך הפריימוורק צריך להיות "עבה" יותר, וגם להיפך תופס.
- בחירת שיטת ניהול תהליך הפיתוח (רמז: אג'ייל כאמור).
- תוכנית פיתוח.
- כתיבת קוד.
אין תגובות:
הוסף רשומת תגובה