גישות מובילות וערכים של מתודולוגית Agile
את המאמר הקודם בנושא מתודולוגית Agile – "מתודולוגית Agile, על מה מדברים?" סיימנו בכך שציינו כי מתודולוגית Agile בשונה ממתודולוגיות אחרות מספקת הנחיות כלליות ולא כללים ברורים. במאמר זה נתמקד בגישות המובילות ובערכים של מתודולוגית Agile.
תשתית הטמעת מתודולוגיות ניהול פרויקטים Agile מבוססת על שתי גישות מובילות:
הגישה של www.spmn.com) SPMN) – מספקת קוים מנחים למנהלי פרויקטים תוך שימוש בהצעות פרקטיות ליישום יום יומי.
Agile Modeling של Scott Ambler – מספקת שלד רחב ליצירת תהליכי Agile המותאמים לפרויקטי תוכנה.
לפני שמגדירים את העקרונות של לניהול פרויקט בשיטת Agile, צריך להכיר מספר ערכים שחשיבותם היא מתחת לפני השטח:
תקשורת – פנימית וחיצונית בפרויקט agile חייבת להיות רצופה. תקשורת זו הינה באחריות מנהל הפרויקט בכדי להבטיח שהתקשורת שמתרחשת היא אפקטיבית, ברורה ובין הגורמים הרלוונטיים. מאחר שהשינויים הם המרכיב הקבוע בפרויקט agile, תקשורת רצופה היא הדרך היחידה לשמר את הקשרים בין כל הגורמים.
פשטות – מגדירה את הגישה לזהות את הגורמים הקריטיים של הפרויקט במונחים של פתרונות הפשוטים ביותר האפשריים. כל הפעילויות צריכות לתרום ערך מדיד בתהליך ניהול הפרויקט.
משוב – אופטימיות זה סיכון מקצועי בפיתוח תוכנה, משוב הוא התרופה. משוב קבוע הוא הכלי להגדרה וקיום הזריזות של Agile.
אומץ לב – כל ההחלטות החשובות והשינויים בכיווני הפרויקט צריכים להיעשות באומץ. שינוי הוא חלק מציאותי בפרויקט IT. התמודדות עם התוצאה של שינוי כאשר ההמלטה מוכחת כלקויה דורשת אומץ.
צניעות – מנהלי הפרויקטים הטובים ביותר מכירים בכך שהם לא יודעים הכול. גישה יעילה היא להניח שלכל המעורבים בפרויקט יש ערך זהה ולכן יש להתייחס להם בכבוד.
יישום העקרונות הבאים יוצר בסיס לניהול פרויקטי IT על פי agile:
הנחה של פשטות – כשהפרויקט מתקדם יש להניח שהפתרון הפשוט ביותר הוא הטוב ביותר. למנהל הפרויקט צריך להיות האומץ לא לבצע משימה שאינה מפורטת באופן ברור בדרישות כצורך למידי לתועלת הארגון.
ביצוע שינוי – מאחר והדרישות מתפתחות עם הזמן, הבנת הדרישות ע"י המשתמשים ישתנו גם הם עם הזמן. לקוחות הפרויקט עצמם עשויים להתחלף עם התקדמות הפרויקט ואף לשנות את דעתם וכך לגרום לשינוי במטרות ובפרמטרים של הצלחת הפרויקט.
השלב הבא גם הוא מטרה - פרויקט יכול להיחשב ככישלון כאשר הצוות מספק את המערכת הלא נכונה למשתמש. חלק ממענה לצרכים של המשתמש הוא להבטיח שהמערכת מסוגלת לתמוך בהרחבות ושינויים לאורך זמן. שימוש בקונספט של אליסטר קוברן – "כשאתה משחק במשחק פיתוח תוכנה המטרה המשנית שלך היא לתכנן את המשחק הבא". השלב הבא עשוי להיות פיתוח של גרסה ראשית של המערכת או תפעול ותמיכה של הגרסה הנוכחית.
שינוי הדרגתי – הלחץ לבצע נכון בפעם ראשונה יכול להכשיל את מנהל הפרויקט הטוב ביותר. בתוך ניסיונות השווא לפתח תוכנית פרויקט מקיפה מהשלב הראשון, קבע עוגן באמצעות פיתוח חלקים קטנים של המערכת, או אפילו מודל על של חלק גדול מהמערכת, והרחב את החלק זה לאורך הזמן. או פשוט תזרוק אותו כאשר אתה לא צריך אותו יותר במשך ההתפתחות ההדרגתית של המערכת.
מקסום ערך המשתמש – משתמשי הפרויקט משקיעים משאבים- זמן, כסף, אמצעים ועוד – בכדי להטמיע מערכת שתואמת את הצרכים שלהם. המשתמשים מצפים שההשקעה שלהם תהפוך למעשית.
ניהול עם מטרה – יצירת כלים למדידת תהליך ניהול הפרויקט שיש בהם ערך עבור המשתמש. יש לזהות למה ועבור מי מדדים אלו נוצרו. זהו את המטרה ליצירת המדדים ומי קהל היעד שלהם. עיקרון זה מתייחס גם לשינוי של מדדים קיימים.
ריבוי היבטים של פרויקט – ספקו מצגות שונות של אותו תהליך לקהלים שונים. השיקול של המורכבות בכל מערכת מידע מודרנית, מביא לצורך במגוון רחב של מצגות במטרה לתקשר באופן אפקטיבי עם המשתמשים, המשתתפים והספקים.
משוב מהיר – הזמן בין פעולה ומשוב על עליה צריך להיות מינימאלי. עבודה בצמוד למשתמשים בכדי להבין את הדרישות, לנתח אותם ולפתח תוכנית פעולה שמספקת הזדמנויות רבות למשוב.
אספקת מערכת פועלת זה המטרה העיקרית של הפרויקט – המטרה של כל פרויקט תוכנה היא לייצר תוכנה שעונה על הדרישות של המשתמשים. המטרה היא לא לספק תיעוד מיותר, מדדי ניהול או אפילו מודלים של מדדים אלו. כל פעילות שאינה תורמת ישירות למטרה של יצירת מערכת עובדת צריכה להבחן היטב.
צמצום מורכבות – כל מדד שנוצר ונישמר צריך לתחזק לאורך הזמן. המאמץ הנדרש לתחזק מדדים אלו צריך להיות מאוזן עם הערך שלהם. צריך לשקול בנוסף למאמץ גם את הסיכון שהמדד ייצור עם הזמן אם הוא לא יתוחזק כראוי.
המלצות למיישם
עשו שינויים הדרגתיים בדרישות, בתוכנית הפרויקט ובמדדי התוצאות בכדי לאפשר את הגמישות של agile.
שאפו כל הזמן למשוב מהיר בכדי להבטיח שהפרויקט תואם את הדרישות של כל הגורמים המשתתפים.
ניהול מכוון מטרה, מתמקד בביצוע רק של המשימות שמוסיפות ערך לתהליכים העסקיים הנתמכים ע"י המערכת.
וויתור על תהליכים ומדדים שאינם מוסיפים ערך מתמיד למערכת יבוא לכך שנשיג מערכת תוכנה פועלת.
רונן שמחון
- היומן של רונן שמחון
- חברי האתר יכולים לשלוח תגובה - כניסה , הצטרפות