פברואר 2011 שיטת פיתוח Agile – הכרות ראשונית
"הם שוב שינו את התעדוף", "אתה מכיר את המשתמש שלנו- מזגזג ללא הפסקה", "עד שהם לא יידעו מה הם רוצים מעצמם, נתקשה להתקדם" , אלה הן חלק מהטענות שנשמעות במחלקות ה- IT, וממחישות את תסכול המפתחים.
מפתיע עד כמה קל לפספס את מטרות הפרוייקט, להתרחק בצורה משמעותית מהערכות התקציב, ולגלות שלא משנה כמה נקפיד על עיצוב המערכת, עדיין יצוצו דרישות חדשות. היינו מעדיפים לבצע תהליך מסודר של הגדרת דרישות מושלמת ומוסכמת על המשתמש, ורק לאחריה לעבור לפיתוח ללא הפרעות של המשתמש. בפועל דינמיות החיים לא מאפשרת "פריבילגיה" זו.
בשנים האחרונות עובר עולם ניהול הפרויקטים מהפך תפישתי, שלוקח בחשבון שדרישות עלולות להשתנות תוך כדי התקדמות בתהליך האיפיון והפיתוח. התפישה החדשה מבינה ש"ההשתנות" היא חלק בלתי נמנע מהפרויקט, ודואגת לכך שהצוות עובד על הדברים החשובים באמת. התפישה מעודדת שינוי של המשימות בפרוייקט, טיפול מיידי במשברים, ואדפטציה לערך העדכני ללקוח (אפקטיביות מקסימאלית), מבלי לוותר על איכות התוצר. מעורבות הלקוח הינה חלק בלתי נפרד מפרויקט אג'ילי טיפוסי. הצוות מתרכז בייצור ערך ללקוח, ועל הלקוח לוודא באופן שוטף, שעדיפויות הפיתוח מוגדרות היטב, ושהתוצרים שפותחו תואמים לדרישותיו.
הלקוח יצפה בתוצרים בתדירות גבוהה, ולכן יוכל, להגיב ולהדגיש מה באמת חשוב לו, מבלי שהושקעה עבודה רבה. ארגונים שירצו להוביל יהיו חייבים לשנות את התנהלותם , ולהיהפך לזריזים וגמישים- להסתגל לקבלת שינויים ולהיות מודעים לסביבה, ולהגיב מהר לשינויים. אגב אין הכרח שהארגון כולו יעבור לעבוד בשיטה אג'ילית- בהחלט יתכן מצב, שבסוגים מסויימים של פרויקטים וסביבות, לא יהיה זה נכון לעבור לשיטה זו.
ההשתנות חייבת להתמקד בשלושה מישורים: • המישור התפישתי- אנו חייבים לשנות את גישתנו לשינויים. עלינו ללמוד לקבל את השינויים בצורה חיובית, ולא לייצר נוקשות פונקציונאלית בדיונים שלנו עם הלקוחות. יש לנצל את יכולת השפעתנו להוביל את השינוי לכיוונים מתאימים בשלבים מוקדמים. עצם העובדה שנרתמנו לשינוי מורידה את עוצמת התנגדותנו אליו , ויוצרת אוירה חיובית בפרויקט. • המישור המתודולוגי- יש לאמץ שיטת פיתוח אג'ילית (זריזה), שכוללת מחזורי פיתוח קצרים. כאשר תכולת גרסת כל סבב תיגזר מכמות הפיתוח אותה ניתן לבצע באותה מסגרת זמן קצרה. בשיטה זו, תהליכי האיפיון יבוצעו בשילוב הדוק עם המשתמש בכל אחד מהסבבים, ויתבססו על משובים שוטפים ואינטנסיביים מהשטח. המתודולוגיה כוללת סט של כלים שיפורטו בהמשך. בלא מעט ארגונים, נוהגים להסתייע בתחילת הדרך ביועץ חיצוני מוסמך ומיומן. • המישור הטכנולוגי - נדרש לאמץ טכנולוגיות, המאפשרות שינויי קוד מהיר, לשלב את מערכות הליבה עם היישומים החדשים, להרחיב יישום של ארכיטקטורה מונחת שירותים (SOA ), להרחיב את השימוש בביצוע unites אוטומטיות, לממש טכניקות של clean code וכיוצ"ב.
אימוץ תפישות פיתוח אלו הוא תנאי הכרחי ליכולת לקדם את הפרוייקט בסבבי פיתוח מהירים. לעבור לעבוד אג'ילית, זו משימה מורכבת. העובדים והמנהלים חייבים להיות משוכנעים בתחלואות ניהול הפרויקטים הקיימים, ולצאת מאזור הנוחות וההתניות המיותרות, אל סביבה ששמה דגש על עבודת צוות , וגיבושו לצוות מיומן ומוכוון משימות. הטמעת השיטה יכולה להיתקל בלא מעט קשיים ומתנגדים. קשיים אמיתיים שעלולים להתעורר ומחייבים התייחסות– • יחידות ה- IT מאורגנות לפי אחריות לנושא, ולא מוכוונות פרוייקט. במצב זה אנו עלולים להיקלע לקונפליקט בין משימות תחזוקה בנושא, להשקעה בפרוייקט. • תהליכי העברה ליצור מסורבלים. • משתמשים שאינם מבינים די, את חשיבות התעדוף בסביבה מרובת אילוצים. • אין משתמשים, הצרכים המדוייקים נהירים עד תום ללקוחות החברה. • הנהלה שאיננה מאמינה ו/או מחויבת לתהליך השינוי. • חשש משינוי. התנגדויות- להלן מספר אמירות שגורות של מתנגדים: • "בתיאוריה זה מצוין, אך פרקטית זה לא עובד" • " בעולם אין סיכוי שנצליח להוציא גרסה תוך שבועיים". • "אנחנו חברה ענקית ואג'ייל מתאים בעיקר לארגונים קטנים". • "אין אצלנו אפשרות לתעדף- כאן הכל חשוב".
כלי מימוש המתודולוגיה -מעבר להשתנות במישור התפישתי, והטכנולוגי, ישנם מספר כלים המאפשרים את מימוש המתודולוגיה: • ברמה האסטרטגית- חשוב שתהיה מחויבות הנהלה מלאה הכוללת אמנה, חזון, ומימון. • תכנון אופרטיבי – בתחילת הפרוייקט יבוצע מיפוי של הצרכים, המשמעות שלהם, והערכות למימוש הסבבים (תוך קביעת מספר הסבבים, ומשך כל סבב). תוצר הכלי נקרא "תוכנית שחרורים" (release plan ). התוכנית לוקחת בחשבון את עלות כל רכיב, ואת תעדוף המשתמש. הדרישות לשינויים יצטברו, ואחת לתקופה, מתקיים דיון לעדכון תוכנית השחרורים. • מימוש הסבבים (sprint) - משך הסבב המקובל הוא בין שבוע לחודש. למימוש הסבב אנו נעזרים בשלושה כלים: o תכנון החזרה הבאה - בחינה ותכנון פרטניים של החזרה הבאה- הכולל אילו רכיבים כוללת החזרה, מי מהצוות אחראי לכל אחד מהתוצרים, מה הם תתי השלבים למימוש בכל אחד מהרכיבים בסבב. o סקירת תוצרי הסבב (review )שהסתיים – מעבר עם המשתמש על תוצר הסבב, וקבלת משוב מיידי לתוצר. o הפקת לקחים (retrospective ) – דיון במגמה ללמוד מהדברים החיוביים בסבב, ולהימנע מהטעויות שנעשו. • בקרה יומית-(daily meeting ) בכל יום בשעה קבועה, מתקיימת פגישת בקרה יומית קצרה (אגב ע"מ שהפגישה לא תמשך מעבר למספר דקות היא מתקיימת בעמידה...). בישיבה כל אחד מחברי הצוות (כולל המאפיינים והבודקים) מדווח על מצב המשימות שבאחריותו, כיצד כל אחת מהמשימות מתקדמת, האם משהו מונע מלהתקדם בהתאם לתכנון, ואם כן, אילו פעילויות נדרש לעשות ע"מ להתקדם.
תפקידים בתפישת האג'ייל : • משתמש עסקי – מגדיר את תכונות המוצר, ואחראי לתכולתו (הוא יודע מה לשלב בגרסה הבאה, ולא פחות חשוב – מה לא). הוא חייב להבין את המוצר לעומק, ואת רצון השוק, וע"י כיוונון ותעדוף הפיצ'רים בסבב, לייצר גרסה אופטימאלית (באילוצי תקציב ולו"ז), רווחית, ובמינימום סיכונים. מנהל המוצר יהיה מודע בכל רגע נתון מה יושם, ויאשר את הוצאת הגרסה בהתאם לאיכותה, והתזמון הנכון להעברה לייצור. יתכן ויוגדרו מספר מנהלי מוצר בפרוייקט, אך חשוב, שידברו ב"קול אחד", ועדיף שתהיה חלוקת גבולות ברורה בינם. • צוות עבודה- מומלץ שהצוות יורכב, מ- 4-9 חברים מדיסציפלינות שונות המסוגלות יחד לייצר את תוצרי הסבב. חברי הצוות יגדירו את מטרת הסבב, ובעלי זכות לקבוע מה נדרש לעשות בכדי להשיג מטרה זו. בתום הסבב הם ידגימו את תוצריו, ויתייחסו למשוב המשתמש. חברי הצוות משתתפים בפגישה היומית. • Scrum Master – תפקידו לדאוג שהתהליך עובד בצורה חלקה, שהבעיות נפתרות מהר, בנוסף עליו לדאוג שהגדרת הדרישות מהצוות ברורה, ושהצוות מכסה בפעילויותיו את כל הדרישות.
הטמעה והמשכיות -הסיטואציה איתה מתמודדים חלק מהארגונים, היא הצלחה נקודתית במימוש אג'ייל בארגון, ובמקביל קושי להרחיב את הטמעת הגישה, ולדאוג להמשכיותה. המתודולוגיה כוללת סדרה של כלים לבחינת הקשיים בארגון, ולהתמודדות איתם, ולהמשכיות קיום השיטה בפרויקטים הבאים. שביעות רצון מסקרים שבוצעו, שביעות הרצון של המשתמשים מהמעבר לעבודה אג'ילית הוא גבוה באופן משמעותי ומובהק מהשיטה המסורתית לניהול פרויקטים. המאמר החל באמירות תסכול של עובדי - IT , ובחרתי לסיים בציטוט של עובד IT שהיטיב לתאר את ההבדל בתחושותיו לאחר שעבר לעבוד בשיטה האג'ילית: "בעבר חשתי שיושבים לי על הוריד, ובכל זאת חייתי בתחושה שאינני מביא ערך משמעותי, וכעת אני אחראי להשיג את אותו ערך בכוחות עצמי".
ערך וכתב: ויקטור רוקח' תואר שני בניהול מערכות מידע. תפקיד נוכחי: מנהל יחידת מהנדסים ומנתחי מערכות בבנק הפועלים יצירת קשר: rockah.victor@gmail.com
Victor Rockah Msc IT Mangment
