אמנם נראה שהאג'ייל נמצא בתנופה (למרות שאינו בדיוק דבר חדש) במימוש כזה או אחר (סקראם למשל), וזה אכן דבר טוב. אבל לא בכל מקום הוא בהכרח מתאים (תעשיות שדורשות תשתית גדולה מאוד), לא בכל מקום קל להטמיע אותו (חברות גדולות עם הרבה צוותים מבוזרים) ולא בכל מקום מוכנים לקראתו (עניין של שמרנות למשל). לפעמים אלו כמה דברים ביחד.
גם במקומות שכן מוכנים לקראתו ומקבלים אותו, לא תמיד הוא מיושם "כהלכתו".
למשל במדריך הסקראם בעברית (כן, תרגמו אותו משום מה), תמצאו את המשפט: "צוותי ה-Scrum הם צוותים המנהלים את עצמם וחוצי-תפקידים. צוותים המנהלים את עצמם בוחרים את הדרך האופטימלית לביצוע עבודתם ולא מנוהלים על ידי אחרים מחוץ לצוות." בפועל אנו רואים (אני אישית כאחד שמעורה בתעשיה) שבארגונים רבים העובדים באג'ייל עדיין משאירים את גוף הבדיקות כעצמאי והיררכי, למרות שהבודקים עצמם נמצאים בצוותים. אגב גם בגוגל, לפחות לפי הספר How Google test software משנת 2011, רואים שארגון הבדיקות עובד שם בשיטה הנ"ל. יש בזה היגיון, כיוון שזה נותן עצמאות לבודקים והגוף הניהולי יכול לחדש וגם לוודא שהעבודה בצוות נעשית בצורה הטובה ביותר.
כלומר הארגונים לקחו את עקרונות האג'ייל והסקראם (למשל, או כל שיטה) ובנו את מה שהם חושבים שיתאים לחברה ולתרבות הארגונית שלה, לתעשייה ולאופי העבודה. אבל במקרה הזה, עדיין חלק נכבד מרוח הדברים של האג'ייל קיים.
השאלה היא מה קורה בארגונים אחרים שלא מוכנים לקבל את רוח הדברים של האג'ייל?
אני חושב שגם כאן יש דברים שאפשר לעשות. אני חושב שבסופו-של-דבר כולם מבינים שהזמנים משתנים, ואם נשכנע את האנשים בחברה שניקח דברים בזהירות ובשום שכל, שזה יראה שאנחנו והארגון מחדשים, ונוכל לומר שעדיין חידשנו ובאמת נביא ערך לארגון.
אז אילו מאפיינים אג'יליים ניתן להביא לארגון ווטרפולי?
Continuous Integration:
בדיקת יחידה - Unit Test, ואוטומציה. UT זה חובה באג'ייל - ראו מאמר של גיל זילברפלד, ולדעתי גם אוטומציה. אז מבלי להצהיר על כוונת אוטומציה מקצה לקצה, בואו נדבר על Continuous Integration שמכיל את האלמנטים האלה.
בגדול זה אומר שמלבד הקידוד של הפיצ'ר והכנת UT, תהליך הפיתוח הוא אוטומטי. ע"י לחיצה על כפתור, המפתח בודק את הקוד החדש שלו, אם הבדיקה עברה יש אופציה (לא חובה) לבילד מקומי שם יריצו smoke tests אוטומטי, אח"כ העברה לרפוזיטורי של כל קוד המוצר, בניית גרסה מלאה והרצת בדיקות קצת יותר רחבות. בכל נקודת כשל עוצר את התהליך וחוזר לאחריות המפתח. כל התהליך, למרות שנשמע מורכב, צריך להיות מהיר, ולהיעשות כמה פעמים ביום. הבודק מקבל את המוצר תכלס באותה נקודה שהוא קיבל בעבר, אולי יותר מהר ובטוח יותר יציב.
היתרונות:
גם במקומות שכן מוכנים לקראתו ומקבלים אותו, לא תמיד הוא מיושם "כהלכתו".
למשל במדריך הסקראם בעברית (כן, תרגמו אותו משום מה), תמצאו את המשפט: "צוותי ה-Scrum הם צוותים המנהלים את עצמם וחוצי-תפקידים. צוותים המנהלים את עצמם בוחרים את הדרך האופטימלית לביצוע עבודתם ולא מנוהלים על ידי אחרים מחוץ לצוות." בפועל אנו רואים (אני אישית כאחד שמעורה בתעשיה) שבארגונים רבים העובדים באג'ייל עדיין משאירים את גוף הבדיקות כעצמאי והיררכי, למרות שהבודקים עצמם נמצאים בצוותים. אגב גם בגוגל, לפחות לפי הספר How Google test software משנת 2011, רואים שארגון הבדיקות עובד שם בשיטה הנ"ל. יש בזה היגיון, כיוון שזה נותן עצמאות לבודקים והגוף הניהולי יכול לחדש וגם לוודא שהעבודה בצוות נעשית בצורה הטובה ביותר.
כלומר הארגונים לקחו את עקרונות האג'ייל והסקראם (למשל, או כל שיטה) ובנו את מה שהם חושבים שיתאים לחברה ולתרבות הארגונית שלה, לתעשייה ולאופי העבודה. אבל במקרה הזה, עדיין חלק נכבד מרוח הדברים של האג'ייל קיים.
השאלה היא מה קורה בארגונים אחרים שלא מוכנים לקבל את רוח הדברים של האג'ייל?
אני חושב שגם כאן יש דברים שאפשר לעשות. אני חושב שבסופו-של-דבר כולם מבינים שהזמנים משתנים, ואם נשכנע את האנשים בחברה שניקח דברים בזהירות ובשום שכל, שזה יראה שאנחנו והארגון מחדשים, ונוכל לומר שעדיין חידשנו ובאמת נביא ערך לארגון.
אז אילו מאפיינים אג'יליים ניתן להביא לארגון ווטרפולי?
Continuous Integration:
בדיקת יחידה - Unit Test, ואוטומציה. UT זה חובה באג'ייל - ראו מאמר של גיל זילברפלד, ולדעתי גם אוטומציה. אז מבלי להצהיר על כוונת אוטומציה מקצה לקצה, בואו נדבר על Continuous Integration שמכיל את האלמנטים האלה.
בגדול זה אומר שמלבד הקידוד של הפיצ'ר והכנת UT, תהליך הפיתוח הוא אוטומטי. ע"י לחיצה על כפתור, המפתח בודק את הקוד החדש שלו, אם הבדיקה עברה יש אופציה (לא חובה) לבילד מקומי שם יריצו smoke tests אוטומטי, אח"כ העברה לרפוזיטורי של כל קוד המוצר, בניית גרסה מלאה והרצת בדיקות קצת יותר רחבות. בכל נקודת כשל עוצר את התהליך וחוזר לאחריות המפתח. כל התהליך, למרות שנשמע מורכב, צריך להיות מהיר, ולהיעשות כמה פעמים ביום. הבודק מקבל את המוצר תכלס באותה נקודה שהוא קיבל בעבר, אולי יותר מהר ובטוח יותר יציב.
- התהליך מהיר.
- פיבדק מהיר על בעיות.
- פחות תסכולים של אנשי בדיקות ומפתחים.
- חוסך זמן בדיקות.
- במיוחד כשיש הרבה קוד חדש כל הזמן, ביצוע התהליך כמה פעמים ביום יגלה בעיות בעדכונים קטנים, כך שקל יהיה למצוא את הבעיות מהר.
מה צריך לשקול?
במערכת גדולה כדאי לוודא שאין יותר מידי תלויות בין חלקים של המוצר שיקשו על יישום CI.
ההתקנה של המוצר צריכה להיות אוטומטית.
המטרות של ה-CI ברורות.
הגדרת אחריות בין בודקים, אנשי אינטגרציה אם יש ומפתחים.
סורס קונטרול ותשתית CI.
תוצאות ברורות לאוטומציה. אקספלורטורי טסטינג דיברתי על זה לא מעט ולא כאן המקום להזכיר זאת שוב. כדאי לזכור שבתנאים המתאימים שיטה זו חוסכת זמן, בעיקר בכתיבת הבדיקות.
בודק שהוא חלק מצוות הפיתוח לא סקראם, אבל דבר שיחסית קל לממש ולהביא לתוצאות מאוד טובות:
ההתקנה של המוצר צריכה להיות אוטומטית.
המטרות של ה-CI ברורות.
הגדרת אחריות בין בודקים, אנשי אינטגרציה אם יש ומפתחים.
סורס קונטרול ותשתית CI.
תוצאות ברורות לאוטומציה. אקספלורטורי טסטינג דיברתי על זה לא מעט ולא כאן המקום להזכיר זאת שוב. כדאי לזכור שבתנאים המתאימים שיטה זו חוסכת זמן, בעיקר בכתיבת הבדיקות.
בודק שהוא חלק מצוות הפיתוח לא סקראם, אבל דבר שיחסית קל לממש ולהביא לתוצאות מאוד טובות:
- הבודק ישתפשף במוצר,
- יכניס את האיכות בשלב מוקדם - בכך שיבדוק בנקודה מוקדמת, יספר למפתחים על סנריו שהוא חושב עלייהם אפילו לפני הקידוד,
- יסייע למפתחים לבדוק חלקים מהמוצר מוקדם,
- יהיה מקצועי יותר - יכיר מה הפיתוח עושה, אולי ילמד לקודד,
- יחסוך זמן אח"כ בבדיקות המערכת - ילמד את שאר הבודקים על החלקים הטכניים והמוצריים, יהיו חלקים שכבר יהיו בדוקים ואיכותיים וכד'. גם המעבר פיתוח - בדיקות של המוצר יהיה מהיר יותר.
דורש הדרכה של הבודק והמפתח לגבי הרעיון של עבודה משותפת, דורש ניטור, אבל שווה.
צוותים מולטידיסציפלינריים
מוקדם לדבר על אג'ייל, אבל אפשר בנקודות קריטיות במהלך חיי המוצר שכל הבודקים, המתכנתים, מנהלי המוצר, UX, DBA וכד' ישבו ביחד. זה חוסך, זה יעיל, וזה ממקצע.
במקרה אחד כזה שאני מכיר זה חסך (ואני זהיר ) 15% מצפי של 200 ימי בדיקה. אבל זה חסך גם הכנסת דיווחי באגים שאינם נכונים, הביא למצב בו באגים מטופלים במידי.
באילו נקודות אפשר לעשות זאת? למשל תחילת הבדיקות או סוף הפיתוח.
מוכנים לקצת יותר?
מה דעתכם על מודל של Water-scrum-fall?
כן, יש חייה כזו וניתן לקרוא עליה למשל כאן: https://reqtest.com/agile-blog/agile-waterfall-hybrid-methodology-2
מוכנים לאג'ייל אבל אתם ארגון גדול ובעל לו"ז צפוף?
אפשרות אחת לזה זה ה-SAFe. זה אג'ייל בסקייל גדול. אני לא מומחה לנושא, אבל זה עובד למשל ב-Nice Actimize.
כמו במקרה הקודם יש דברים אג'יליים, כמו הצוותים, ספרינטים וכד'. אבל יש רבדים אחרים שקובעים חלק מהדברים כמו הלו"ז.
לסיכום:
כמו שראיתם, לא חובה לאמץ אג'ייל כמקשה אחת כשלא מתאים לאירגון מסיבות כאלה ואחרות. אבל כן אפשר והייתי אומר שזה כמעט חובה לאמץ מאפיינים של אג'ייל. אפשר לאמץ חלק כזה או אחר ממה שהמלצתי, לאט ובצורה מנוטרת, לתקן קצת ולהמשיך עד שיהלום את הארגון לגמרי.
מוכנים לאג'ייל אבל אתם ארגון גדול ובעל לו"ז צפוף?
אפשרות אחת לזה זה ה-SAFe. זה אג'ייל בסקייל גדול. אני לא מומחה לנושא, אבל זה עובד למשל ב-Nice Actimize.
כמו במקרה הקודם יש דברים אג'יליים, כמו הצוותים, ספרינטים וכד'. אבל יש רבדים אחרים שקובעים חלק מהדברים כמו הלו"ז.
לסיכום:
כמו שראיתם, לא חובה לאמץ אג'ייל כמקשה אחת כשלא מתאים לאירגון מסיבות כאלה ואחרות. אבל כן אפשר והייתי אומר שזה כמעט חובה לאמץ מאפיינים של אג'ייל. אפשר לאמץ חלק כזה או אחר ממה שהמלצתי, לאט ובצורה מנוטרת, לתקן קצת ולהמשיך עד שיהלום את הארגון לגמרי.
אין תגובות:
הוסף רשומת תגובה