כל מי שעבד בבדיקות או בפיתוח אי פעם שמע את המושג לפחות פעם אחת. בפוסט ננסה להסביר לא רק מה זה agile אלא גם מה האלטרנטיבה הנפוצה שלו (שיטת המפל - Waterfall) ואיך זה משפיע על הלך העבודה של הבודק בחברה בה הוא עובד.
הנחת היסוד של השיטה שכל דרישה של הלקוח תתגלה לפני ששלב הקידוד החל - אין לה אחיזה במציאות. ובפועל, עד שהפיתוח והבדיקות מסיימים את תפקידם, בהרבה פעמים קורה שהמוצר כבר לא רלוונטי ללקוח ויש צורך לקודד שוב, או במקרים מסויימים לעשות re-design למוצר מה שבעצם מחזיר את צוות הפרויקט לאיטרציה חוזרת, בדומה ל- Agile, רק בדרך הקשה.
מתוך הסיבות שמנינו לעיל ומעוד הרבה אחרות, צמח הצורך לאלטרנטיבה לשיטת המפל. שיטת ה- Agile היא רק אחת מהן וגם לה יש מימושים שונים.
העיקרון במימושים השונים של Agile הוא דומה - פירוק המשימה לחלקים קטנים והתקדמות באיטרציות קטנות כך שכל חלק יתוכנן, יפותח וייבדק בפני עצמו. כשל בפיתוח של חלק קטן מהמוצר, לא יסכן את כל הפרוייקט וההתקדמות לשלב הבא בפרוייקט תהיה תלויה בסיומו המוצלח של פיתוח החלקים הקודמים של המוצר.
שיטת ה- Agile מתאימה את ניהול הפרוייקט למחזור החיים של הפיתוח. השיטה עובדת באיטרציות שנקראות גם Sprints והיא אינקרימנטלית - כלומר, מתקדמת בהדרגה, כל פעם קצת.
לכל שיטת ביצוע של Agile (כמו Scrum), יש מן הסתם חסרונות והיא מאלצת אנשים בצוות לפעול לפי נהלים מסויימים, לאו דווקא לרוחם או כאלה שהם חושבים כנכונים או נוחים לעבודה. נהלי עבודה באופן טבעי, מייצרים מלאכותיות וככל שהנהלים יותר מפורטים ומשנים סדרי עולם, כך הם עלולים לגרום להתנגדות.
כל ארגון בוחר לממש את ה- Agile בדרכים משלו ויש ארגונים שדבקים באדיקות יתר בנהלים, מה שגורם לצוות לעבוד יותר בשביל השיטה מאשר שהשיטה תעבוד בשבילם.
בנוסף, יש עניין של פרשנויות לשיטה ולדרכים ליישומה. לעיתים חלק מהתפקידים בצוות לא מוגדרים נכון, מה שגורם לבעל התפקיד שלא לבצע את תפקידו כהלכה והתוצאות הסופיות אינן מה שהתכוון המשורר.
כמו כן, התלות בשיתוף הפעולה בצוות הוא קריטי והעניין עלול להסתבך עם סוגים שונים של עובדים ומנהלים. מה גם שככל שהצוות גדל, מספר הקונפליקטים בין האנשים מתרבה, דבר שתורם למתח ולחוסר שיתוף פעולה מצד הצוות, מה שעלול גם להגביר את הלחץ מצד המנהלים לגרום לצוות ליישר קו עם נהלי ה-Agile, דבר שעלול להוסיף אנטגוניזם למצב הבעייתי ממילא.
אני חושב שהסרטון הבא (שעוסק במבוא ל- Scrum) מתמצת את העניין היטב:
שיטת המפל היא המתודולוגיה הוותיקה (וחלק יאמרו הטובה) של ניהול פרוייקטים בפיתוח תוכנה.
העיקרון הבסיסי בשיטה זו הוא שתהליך לא מתחיל עד שזה שלפניו הסתיים, מה שמשאיר את הבדיקות לאחרונות בתור.
על פניו, שיטה זו ניראית טבעית יותר - מעין פס ייצור: כל חוליה ממתינה לקודמתה שתסיים עד מלאכתה עד תום.
במציאות, יש לכך מספר השלכות שיש להתמודד איתן:
- כאשר כל חלק "החליט" שהוא סיים, תרומתו לתוצר הסופי הסתיימה ואין לו השפעה יותר.
- המרחק בין התכנון והתוצר הסופי גדל, מה שעלול לגרום לכך שהמוצר או חלקים ממנו כבר לא רלוונטים.
- הגמישות לשינויים מוגבלת מאד. אם לאחר סיום שלב התכנון אירעו שינויים בלתי צפויים, המענה עליהם יהיה חלקי אם בכלל.
- מחלקת הבדיקות מהווה "צוואר בקבוק" ל-delivery, מה שעלול להגביר עליהם את הלחץ לסיים - לאו דווקא באופן מתודולוגי מסודר.
- הבדיקות יתבצעו על הגירסה הסופית של המוצר. אם (או כאשר, יש לומר) יתגלו באגים, התיקונים עלולים להיגרר על מספר מודולים בקוד ותהליך ה-debugging יהיה ארוך ומורכב משמעותית.
- מחלקת הבדיקות עלולה לשבת בבטלה עד שתורה יגיע והיא תקבל את הגירסה המיוחלת לבדיקה. עם כל הרצון הטוב לייעל את השיטה ולהתחיל לבדוק לפני התאריך המיועד - לא יהיה לפיתוח מה לתת לבדיקות כיון שהמוצר עדיין בעבודה.
הנחת היסוד של השיטה שכל דרישה של הלקוח תתגלה לפני ששלב הקידוד החל - אין לה אחיזה במציאות. ובפועל, עד שהפיתוח והבדיקות מסיימים את תפקידם, בהרבה פעמים קורה שהמוצר כבר לא רלוונטי ללקוח ויש צורך לקודד שוב, או במקרים מסויימים לעשות re-design למוצר מה שבעצם מחזיר את צוות הפרויקט לאיטרציה חוזרת, בדומה ל- Agile, רק בדרך הקשה.
ד"ר ווינסטון (Winston W. Royce) שהמציא את שיטת המפל, אמר בעצמו שלמרות חיבתו לשיטה, היא מסוכנת ומזמינה כשלים.
לא פלא, אם כן, שיש המכנים את השיטה הזו - Water-Fail.
העיקרון במימושים השונים של Agile הוא דומה - פירוק המשימה לחלקים קטנים והתקדמות באיטרציות קטנות כך שכל חלק יתוכנן, יפותח וייבדק בפני עצמו. כשל בפיתוח של חלק קטן מהמוצר, לא יסכן את כל הפרוייקט וההתקדמות לשלב הבא בפרוייקט תהיה תלויה בסיומו המוצלח של פיתוח החלקים הקודמים של המוצר.
שיטת ה- Agile מתאימה את ניהול הפרוייקט למחזור החיים של הפיתוח. השיטה עובדת באיטרציות שנקראות גם Sprints והיא אינקרימנטלית - כלומר, מתקדמת בהדרגה, כל פעם קצת.
בשיטה זו, האפיון מוגדר בכל שלב בנפרד, מה שמונע מצב בו החברה מעצבת מוצר על הנייר בשלבים בהם עדיין שום פיסת קוד לא נרשמה ולכשהמוצר ייצא אל הפועל יסתבר שחלק מהדרישות לא ניתנות ליישום כלל או אינן בר ביצוע בזמנים הדרושים, עקב אתגרים שלא נצפו בהתחלה. כאשר מדובר בפרוייקט עם deadlines קשיחים כגון מעבר לפס ייצור חומרתי או תאריך ליציאה לתערוכה, ההשלכות יכולות להיות כישלון הפרוייקט כולו.
השיטה שומרת גם על רלווטיות המוצר ומחייבת בדיקה ואפיון מחדש בכל שלב בחיי הפרוייקט כך שבמידה והתנאים השתנו מתחילת הפרוייקט, ניתן לבצע התאמות לכל אורכו כדי להגיע אל סופו קרוב ככל הניתן עם מה שהובטח על הנייר בתחילתו.
השיטה מאפשרת בנוסף למחלקת הבדיקות לקבל חלקי קוד לבדיקה ולדווח על באגים בשלבים בהם תהליך ה- debugging פשוט יחסית ומחיר תיקון הבאג יחסית קטן לתיקון שנעשה בשלב הסופי של המוצר.
ומה זה Scrum ?
Agile היא המתווה הכללי והפילוסופי של הדרך לפיתוח המוצר. אין שם הוראות מדוייקות כיצד לפעול, אלא אפיונים. Scrum היא שיטה עם הוראות לביצוע כיצד ליישם את Agile. היא לא היחידה, אך היא נחשבת לפופולרית ביותר ולכן נדבר עליה.אז למה לא כולם עובדים ב-Agile ?
לצד המצדדים בשיטה יש עליה לא מעט מבקרים, בעיקר מאלה שהתנסו בה. על הנייר, גם ה- Agile נשמעת נפלא. הבעיה מתחילה שמתחילים לממש אותה לפי השיטות וההמלצות השונות.לכל שיטת ביצוע של Agile (כמו Scrum), יש מן הסתם חסרונות והיא מאלצת אנשים בצוות לפעול לפי נהלים מסויימים, לאו דווקא לרוחם או כאלה שהם חושבים כנכונים או נוחים לעבודה. נהלי עבודה באופן טבעי, מייצרים מלאכותיות וככל שהנהלים יותר מפורטים ומשנים סדרי עולם, כך הם עלולים לגרום להתנגדות.
כל ארגון בוחר לממש את ה- Agile בדרכים משלו ויש ארגונים שדבקים באדיקות יתר בנהלים, מה שגורם לצוות לעבוד יותר בשביל השיטה מאשר שהשיטה תעבוד בשבילם.
בנוסף, יש עניין של פרשנויות לשיטה ולדרכים ליישומה. לעיתים חלק מהתפקידים בצוות לא מוגדרים נכון, מה שגורם לבעל התפקיד שלא לבצע את תפקידו כהלכה והתוצאות הסופיות אינן מה שהתכוון המשורר.
כמו כן, התלות בשיתוף הפעולה בצוות הוא קריטי והעניין עלול להסתבך עם סוגים שונים של עובדים ומנהלים. מה גם שככל שהצוות גדל, מספר הקונפליקטים בין האנשים מתרבה, דבר שתורם למתח ולחוסר שיתוף פעולה מצד הצוות, מה שעלול גם להגביר את הלחץ מצד המנהלים לגרום לצוות ליישר קו עם נהלי ה-Agile, דבר שעלול להוסיף אנטגוניזם למצב הבעייתי ממילא.
אני חושב שהסרטון הבא (שעוסק במבוא ל- Scrum) מתמצת את העניין היטב:
אין תגובות:
הוסף רשומת תגובה