ביקורת Agile – Buzzword או העתיד?
מבוא
אנו נמצאים בשיאו של עידן המאופיין בקצב שינויים אקספוננציאלי ומהיר המשפיע על כלל התחומים בארגונים, החל מטכנולוגיה ועד אסטרטגיה ושיווק. הביקורת פועלת מול כלל הארגון, ונדרשת לעשות התאמות על מנת להישאר רלוונטית ומשיאת ערך. לכן עולה הצורך בחשיבה מחדש על אופן ניהול פרויקט הביקורת וחוויית המבוקר (Audit Experience) תוך התאמתם למציאות העדכנית.
במאמר הנוכחי נסקור את מתודולוגיית Agile בניהול פרויקט ביקורת, תוך בחינת היתרונות, החסרונות וההתאמות הנדרשות, על בסיס הניסיון שהצטבר במימוש השיטה בחטיבת הביקורת הפנימית בבנק דיסקונט.
מה זה Agile?
שיטת ניהול הפרויקטים המסורתית Waterfall היא שיטת ניהול טורית, המתייחסת לפרויקט כאל סדרה של שלבים ארוכים, קשיחים יחסית, המתבצעים בזה אחר זה, בדרך כלל ללא אפשרות חזרה אחורה, ובסיומם מוגש ללקוח תוצר סופי.
פרק זמן ארוך למדי עובר מהרגע שבו הלקוח מגדיר את צרכיו וציפיותיו ועד הרגע שבו הוא פוגש בתוצר הסופי, וכאשר מדובר בפרויקטים בעלי מורכבות ודינמיות לא ניתן לאתר שינויים ולהגיב אליהם בצורה טובה. אפשר להסתכל על פרויקט Waterfall כעל ספינת משא ענקית שבה כל שינוי או עצירה מצריכים תכנון רב מראש, ולכן היא אינה מתאימה לתמרונים מהירים בזמן אמת.
החיסרון הזה עשוי להוביל לכשלים מהותיים בביצוע הפרויקט, כגון חריגות זמן ותקציב, ואספקת תוצרים לא מתאימים או שגויים שיכולים להוביל לחוסר שביעות רצון מצד הלקוח, ובמקרי קצה לסירוב להשתמש בתוצר.
בעולם פיתוח התוכנה, המאופיין בפרויקטים משמעותיים, מורכבים ודינמיים, פיתחה בתחילת שנות האלפיים קבוצת אנשים המכונה "The Agile Alliance" שיטת ניהול חדשנית בשם Agile (זמיש=זריז וגמיש). שיטה זאת מבוססת על תהליך ביצוע המתחלק למספר מאוצים (sprints) המוגדרים כ-timebox של מספר שבועות, ובסיומם הלקוח מקבל מוצר אמיתי עובד (demo) למשוב. במסגרת ספרינט, מתבצעים כל שלבי הפרויקט, לרבות איסוף דרישות, אפיון, פיתוח, בדיקות ועלייה לייצור. בבסיס השיטה עומד ה-Agile Manifesto שמציג את הערכים מעולם ה-Waterfall מול ערכים חדשים, נוספים ועדיפים בשיטת ה-Agile:
אנשים ואינטראקציות על פני תהליכים וכלים
תוכנה עובדת על פני תיעוד מקיף
שיתוף (Collaboration) הלקוח על פני התנהלות ומשא ומתן חוזי
תגובה לשינוי על פני עבודה על פי תוכנית
למניפסטו מצטרפים 12 עקרונות ובהם התמקדות בשביעות רצון הלקוח, נכונות וגמישות לשינויים, תוכנה עובדת כמדד מרכזי ועוד.
היתרון העיקרי של השיטה טמון בטווחי הזמן הקצרים בין הגדרת הצרכים והדרישות על ידי המשתמשים לקבלת תוצר אמיתי. לכך מצטרפת מעורבות משתמשים גבוהה לאורך כל תהליך הפרויקט, המתבטאת בין השאר בהיזון חוזר על התוצר, תוך שיתוף פעולה בלתי אמצעי וישיר המאפשר למידע ולידע הנכונים לזרום בזמן ולשמש לתיקון ולפיתוח התוצר המתאים והרלוונטי ביותר.
מה זה ביקורת Agile?
בפרויקט ביקורת המבוצע בשיטת Waterfall, המבוקרים בדרך כלל פוגשים בפעם הראשונה את תוצר הביקורת כפי שייראה בדוח הסופי, בשלב הטיוטה. אם מסיבה כלשהי מתגלים פערי הבנה, מידע או ידע, הם יתבטאו בפערים ואי הסכמות לגבי נוסח הדוח. בנוסף, פורום הגורמים השותף לטיוטת הדוח הוא רחב יחסית וכולל בדרך כלל גורמים בכירים, דבר שלעיתים משפיע על חופשיות וגמישות השיח. מצב זה עשוי לעכב את לוחות הזמנים, לפגוע באיכות ובאפקטיביות הדוח, ולחוסר שביעות רצון מהתהליך מצד המבוקרים.
שיטת הניהול Agile מגיעה מעולם התוכנה ומהווה פתרון לאתגר המתואר לעיל, אך מצריכה התאמות לאופי פרויקט הביקורת השונה מפיתוח תוכנה.
ראשית, הגדרנו כי הלקוח המרכזי (לעניין ה-Agile) הוא המבוקר, מאחר שעימו מתקיימת עיקר האינטראקציה לגבי דוח הביקורת.
את דוח הביקורת ניתן לבנות בצורה איטרטיבית על ידי חלוקה לספרינטים, למשל לפי פרקים, עד להשלמת דוח ביקורת שלם. פרקים שונים יכולים להתבצע מול גורמים שונים, ולעיתים כתיבת פרק כרוכה בעיכובים הנובעים מזמינות חומרים או גורמים. מכאן עולה שבניגוד לגישה האג'ילית הקלאסית, נוכל לבצע ספרינטים במקביל ולאו דווקא אחד אחרי השני.
נסתכל על שלושה שלבים מרכזיים בדוח הביקורת שעליהם נסמכת תוכנית הספרינטים האג'ילית הבסיסית:
- Pre-game – היערכות לדוח הכוללת סקר מקדים, הכנת מפרט (שווה ערך ל-Backlog מעולם הAgile-), חלוקת המפרט לספרינטים לשלב ה-Game, שיחת פתיחה והכנת בסיס מסמך הביקורת – ספרינט בפני עצמו.
- Game – ביצוע הדוח עצמו. שלב זה מחולק לשניים:
- ביצוע כלל הספרינטים שהוגדרו על בסיס המפרט, כאשר בכל ספרינט יבוצע תהליך תכנון, למידה, ניתוח וכתיבת החלק/הפרק, הצגה למבוקרים (demo), קבלת היזון חוזר שלהם ועדכון החלק בהתאמה. חשוב לציין כי את ההצגה של התוצר בשלב זה עושים במסגרת פורום מצומצם של המבוקרים על מנת לאפשר שיח חופשי ואפקטיבי – n ספרינטים.
- טיוטה – סגירת מסמך הטיוטה, תיקוף, פרסום למבוקרים, קבלת היזון חוזר שלהם ועדכון המסמך בהתאמה – ספרינט בפני עצמו.
- Post-game – תהליך פרסום התוצר הסופי של הדוח, לרבות שיחת סיכום – ספרינט בפני עצמו.
כלומר בכל ביקורת יש n+3 ספרינטים.
בכל ספרינט אנו מקיימים מפגשים תכופים (daily) לבקרה על ביצוע הספרינט ותוכנית העבודה. את ה-daily מבצעים בדרך כלל צוות המבקרים, כאשר אחד מהם מוגדר כמוביל המפגש. בגלל האופי המיוחד של תחום הביקורת, את ה-daily לא חייבים לקיים בתדירות יומית, אך כדאי לבחון את הצורך בהתאם לאופי ותחום הביקורת המבוצע. לדוגמה, בביקורת אינטנסיבית מאוד בזמן אמת, ייתכן שנמצא ערך במפגשים יומיים. מומלץ להוסיף מפגש שבועי עם מנהל היחידה לבקרה נוספת.
בסיום כל אחד מהשלבים חשוב לקיים Sprint Review לבחינת הספרינט שהסתיים במסגרת צוות הביקורת, ו-Sprint Retrospective בשיתוף עם המבוקרים, תוך הסתכלות אחורה על התהליך והתוצר, במטרה להפיק לקחים ולהשתפר. בשלבים אלה ניתן לעדכן את תוכנית ההמשך לפי הצורך.
כאשר ספרינטים מתבצעים במקביל, חשוב לסנכרן את לוחות הזמנים כך שתוצרי הספרינטים לא יוצגו בבת אחת למבוקרים אלא באופן הדרגתי שיאפשר להם לתת תשומת לב מיטבית לכל תוצר.
למה זה טוב?
ביקורת Agile מאפשרת למבוקרים לפגוש תוצרי ביקורת כפי שייראו בדוח הסופי, ולהגיב עליהם באופן שוטף במהלך זמן הביקורת הן מבחינת דיוק התוכן והן מבחינת ביצוע פעולות תיקון באופן מיידי לפי הצורך. ההיזון החוזר מאפשר למבקרים לזהות בזמן מוקדם וקרוב יותר לשיח עם המבוקרים: טעויות, פערים, נושאים חשובים או לא חשובים, ופעולות המשך נדרשות. בשיטת ה-Waterfall כל זה היה קורה בדרך כלל בשלב הטיוטה ולאחריו.
המבוקרים מקבלים סמוך לזמן השיח עימם תוצר קצר יחסית ובפורום מצומצם. כך הם יכולים להקדיש לכך תשומת לב רבה יותר, ולהרגיש בנוח להוסיף חומרים חסרים ולגשר על פערים.
המעורבות השוטפת של המבוקרים בתהליך בניית הדוח, תוך מפגש בלתי אמצעי עם התוצר האמיתי, מגבירה את השקיפות ומייצרת מחויבות גבוהה יותר אצל המבוקרים.
ביצוע בקרה על כל ספרינט בנפרד, תוך טיפול בזמן אמת בצווארי בקבוק, מאפשרים מיצוי אופטימלי של זמן הביקורת, כך שבאופן כולל השיטה צפויה לצמצם את לוחות הזמנים ולהפוך את הביקורות ליעילות יותר.
חשוב לציין כי בשל אופייה המתגלגל, ביקורת Agile מתאימה מאוד לביקורות זמן אמת המבקשות להציף פערים במקום.
אתגרים, טיפים וסיכום
מעבר לשיטת ביצוע, ביקורת Agile היא אתגר גם למבקרים וגם למבוקרים. המבקרים נדרשים לניהול ברזולוציה מדויקת יותר תוך ביצוע פעולות במקביל. המבוקרים נדרשים למעורבות גבוהה יותר לאורך כל שלבי הביקורת ולא רק בשלבי הטיוטה הסופית, תוך הבנה שבשלבי הספרינט יש אפשרות לדייק ולגשר על פערים הנובעים למשל מחוסר במסמכים או מפערי הבנה. חשוב לקיים למידה והיכרות עם תהליך ה-Agile עוד לפני ביצוע הדוח, לתאם ציפיות ולאפשר לשני הצדדים להעלות את הקשיים והחששות ממנו, תוך צמצום התנגדויות והגברת שיתוף הפעולה.
מודלי בגרות כגון ה-[1] AMM (Agile Maturity Model) מחדדים כי הטמעת Agile היא תהליך מדורג, ארוך ובעל מורכבות. לכן חשוב לשים לב ל:
- תיאום ציפיות לגבי המועד שבו יחל להתקבל ערך מהשיטה (לפי הספרות הגעה לשלב הבגרות השלישי– – Defined צפויה לקחת שנתיים-שלוש).
- מניעת תפיסה מוטעית כי את פרויקט הטמעת ה-Agile מנהלים ב-Waterfall.
על מנת לאפשר הטמעה אפקטיבית תוך התאמה לסביבה הארגונית, קיימת חשיבות לבצע את תהליך המעבר לAgile- בצורה אג'ילית, תוך הוספת נדבכים באופן מצטבר עד לתהליך שלם ובוגר.
ל-Agile יש שיטות רבות למימוש (גם בעולם התוכנה), חלקן רשמיות וחלקן בהתאמה אישית של הארגון. מאחר שה-Agile מגיע במקור מעולם פיתוח התוכנה, ייתכנו פרקטיקות שעלולות ליצור דיסוננס עם המהלך הטבעי של תהליך הביקורת. על מנת לבצע התאמה מיטבית לעולם הביקורת, חשוב במהלך ההטמעה האג'ילי של השיטה לקיים רטרוספקטיבה בכל שלב, ולעדכן את שיטת הביצוע תוך התייחסות למאפיינים הייחודיים של הארגון, לקחים שנלמדו ואופי הפעילות.
לסיכום, שימוש בשיטה האג'ילית יכול להיות כלי רב עוצמה ביכולת לבצע ביקורות אפקטיביות ומשמעותיות, תוך חיסכון בזמן, מיקוד יעיל בנושאים החשובים ביותר, ופרסום תוצרים רלוונטיים ואפקטיביים, וכל זה תוך חוויית מבוקר חיובית ובעלת ערך.
[1] Patel, C., & Ramachandran, M. (2009). Agile maturity model (AMM): a software process improvement framework for agile software development practices. International Journal of Software Engineering, IJSE, 2(1), 3-28.
