עדה על מיתוסים על Agile

בתעשיית התוכנה יש התעניינות רבה בשיטות Agile, אך רבים חוששים לנסות את השיטה למרות מפח הנפש המלווה לעיתים קרובות פרויקטים המנוהלים במתודולוגיות קלאסיות ● החשש קשור בין היתר למיתוסים מוטעים בהקשרי Agile

בתעשיית התוכנה יש התעניינות רבה בשיטות Agile, אך רבים חוששים לנסות את השיטה למרות מפח הנפש המלווה לעיתים קרובות פרויקטים המנוהלים במתודולוגיות קלאסיות. החשש קשור בין היתר למיתוסים מוטעים בהקשרי Agile. במאמר שלפנינו נתייחס בקצרה ל-5 מיתוסים, ובמאמרים הבאים נסקור עוד.

המיתוס הראשון: "שיטות Agile מתאימות לצוותים שאינם יכולים ואינם רוצים לקבל על עצמם נהלי עבודה וסדר אלא מעדיפים להתנהל בצורה אינטואיטיבית וחופשית".

ב-Scrum, שהיא אחת מהשיטות ה-Agile-יות היותר נפוצות, מוגדרים למשל השלבים הבאים:

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

האם זוהי צורת התנהלות אינטואיטיבית וחופשית או שמדובר בשיטה סדורה ו-"ממושמעת"?

המיתוס השני: "צוותים המנהלים את עצמם הם אנרכיה". המיתוס השלישי: "חייבים לקבל מסמכים מפורטים לכל הדרישות מיד עם תחילת העבודה, אחרת לא נוכל לדעת מה המטרות ולהעריך את המאמץ הנדרש". המיתוס הרביעי: "חייבים להקצות את כל המשימות באופן פרטני לכל אדם בצוות, אחרת אין לנו תכנון". המיתוס החמישי: "חייבים להשלים ארכיטקטורה לפני התחלת הקידוד, אחרת אנחנו לא מתכננים ולא תהיה לנו ארכיטקטורה טובה". ובכן, המיתוסים האלה יסודם בטעות.

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

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

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

ולכן העמקה בדרישות, באפיון, בתכנון ובהקצאת משאבים, חשובה מאוד ומועילה, אם היא מתבצעת קרוב ככל האפשר לזמן הוצאת ה-Feature או המערכת לעבודה. באופן זה מצמצמים את הבזבוז הנובע משינויים מהירים המאפיינים את הסביבה הטכנולוגית והעסקית.

לסיכום: המיתוסים המתוארים הם אכן מוטעים. ולכן גם מי שנמנע מאימוץ שיטות Agile מחשש לאובדן שליטה בפרויקטים מורכבים, בסביבה מפוקחת רגולציה וכדומה, מוזמן לבדוק ולבחון את השיטה ולהיווכח שהיא מאפשרת שליטה טובה יותר, שקיפות ויעילות, תוצרים איכותיים ובתוספת גם שביעות רצון גבוהה של הצוותים ושל הלקוחות.

עדה מרקמן היא מנכ"לית BDA – שותפה עסקית של HP בישראל, המספקת פתרונות ניהול פרויקטים במודל Agile לרבות יישום פתרון HP-PPM

תגובות

(1)

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

אין לשלוח תגובות הכוללות דברי הסתה, דיבה, וסגנון החורג מהטעם הטוב

אירועים קרובים