דפים

יום שבת, 19 בדצמבר 2015

שבעת המפתחות להצלחה בהטמעת אג'ייל בארגון

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

רקע
כבר כתבתי בעבר על כך שמתודולוגיית האג'ייל, על אף שפותחה במקור עבור תעשיית התכנה, כבר חצתה מזמן גבולות אל תעשיות נוספות. הסיבה העיקרית לכך הינה שהמתודולוגיה נותנת מענה לדרישות שוק משתנות אשר מאפיינות את כלל התעשייה ולא רק את תעשיית התכנה.
תהליך ההטמעה של המתודולוגיה בארגון אינו דבר של מה בכך. הוא מצריך הבנה והכנה נכונה (ראה מאמר –מה אתם חייביםלדעת לפני הטמעת אג'ייל בארגון), וכמו כן שינוי בדפוסי חשיבה (ניתן למצוא בהרחבה כאן – The Agile Mindset)
המאמר הפעם יתמקד ב 7 מפתחות אשר עליהם מתבססת הטמעה מוצלחת של אג'ייל בארגון.

מפתח #1 – מבנה צוותים פונקציונאליים
לא בכדי המפתח הראשון קשור באנשי הצוות, הלא הם הנכס החשוב ביותר של הארגון.
במרבית הארגונים מבנה הצוותים מחולק ע"ב התחום המקצועי אליו הם משתייכים (לדוגמא – אלגוריתמאים, צד לקוח, צד שרת, וכיו"ב) חלוקה זו שרתה נאמנה מתודולוגיות וותיקות יותר (כגון waterfall). במתודולוגיית אג'ייל מבנה צוותי ה Scrum הוא שונה.
צוותי הסקראם נבנים ע"ב פונקציונאלי (ולא מקצועי), העיקרון המנחה כאן הוא שלצוות יהיה את כל מה שהוא צריך בכדי לייצר ערך (value), בתוך הצוות עצמו ללא שיצטרך להמתין (בתור) לעזרה מבחוץ.
בניית נכונה של צוותים ע"ב פונקציונאליות נדרשת תבטיח עצמאות של הצוות, התמקדות במטרות הנכונות, ויצירת ערך מרבי עבור הארגון.

מפתח #2 – העצמה ניהולית
גם מפתח מספר 2 קשור לאנשים, אך הפעם מתמקד באנשי הנהלה.
על מנת שצוותי הסקראם יתפקדו בצורה מרבית, עליהם לקבל את האמון המלא של ההנהלה.
הדבר יבוא לידי ביטוי בכך שההנהלה תתמקד בערך העסקי (כגון - תעדוף תכולות, בנייה נכונה של הצוותים, ניהול סיכונים, וכיו"ב) ולא בניהול פרטני של אנשי הצוות.
באנגלית ישנה הפרדה נכונה במושג אחריות בין Responsibility  לבין Accountability
בעוד שצוותי הסקראם לוקחים אחריות (Responsibility) על התכולה עליה התחייבו, צוותי ההנהלה צריכים לקחת אחריות (Accountability) על פעילות הצוותים.

מפתח #3 – Definition Of Done
על מנת שתהליך ייצור יתפקד נכון, ה"שפה" אשר בה יתקשרו האנשים ביניהם חייבת להיות מוגדרת היטב. מפתח #3 מתייחס ל"בטן הרכה" של כל תהליך אינטגרטיבי – נקודת המעבר בין שלבים. בכל הקשר שניקח תחום זה בתהליך ייצור כלשהו, תמיד נקודת המעבר בין שלב אחד לשלב שני, בה האחריות על המוצר עוברת צד (כגון משלב פיתוח לבדיקות) יתקיים "אזור אפור" בו הכללים פחות ברורים מאשר בשלבים עצמם. ההסבר לכך הוא פשוט למדי – בהינתן אנשיי צוות מקצועיים כל אחד בתחומו, לביצוע השלב עצמו (בתהליך הייצור) הכללים הם ברורים. הם פחות ברורים בהעברת המקל.
המושג Definition Of Done (DOD) – מתייחס בדיוק לנקודה זו.
הגדרה נכונה של DOD  עבור כל מעבר שלב, כגון - דרישות לפיתוח, פיתוח לבדיקות, סגירת PBI, סגירת ספרינט, סגירת דרישות, וכיו"ב, הינה הכרחית עבור הצלחת ההטמעה.

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

מפתח #5 – מצוינות טכנולוגית
בהמשך לנקודה #4 – בה המטרה היא ניהול ממוקד ערך, עתה המיקוד הוא בקבלת ערך גבוה מצד אנשי הצוות דרך הפן המקצועי.
במילים אחרות – ככל שנעלה את המצוינות הטכנולוגית של אנשי הצוות בארגון, כך נעלה את ערך התוצר אשר יתקבל בארגון.
כיצד נזהה מצוינות טכנולוגית? האם זהו ידע רחב בפיתוח או שמא מהירות כתיבת קוד \ ייצור?
אחת השיטות הנפוצות בהקשר זה, נקראת First Time Right (FTR) – השקעה בתוצר כלשהו פעם אחת בלבד, ללא צורך בחזרה נוספת ללא שינוי בדרישות.
מספר דוגמאות –
- ייצור נכון בפעם הראשונה של התוצר, ברמת הכיסוי הפונקציונאלי הנדרש
- ייצור נכון בפעם הראשונה של התוצר, ברמת איכות קוד (ללא באגים)
ייצור נכון בפעם הראשונה של התוצר, ברמת Infrastructure ready: חשיבה נכונה ברמת התשתית הנדרשת בהסתכלות קדימה לעתיד הנראה לעין
- עמידה בתנאי DOD שהוגדרו מראש
- אי השארת "חובות טכנולוגיים" במעבר מספרינט לספרינט
וכיו"ב

מפתח #6 – Early Feedback
כפי שצוין בפתיח – ייעוד מתודולוגיית האג'ייל הינה היכולת לתת מענה מהיר לדרישות השוק. ה"מענה המהיר" במרבית המקרים אינו מתמקד ביצירת מוצר חדש, כי אם בביצוע ההתאמות הנדרשות במוצר הקיים, על מנת שייתן מענה נכון יותר לדרישות השוק החדשות. למעשה על מנת שארגון יוכל לעמוד בתנאי זה עליו לוודא קיום מנגנון "התאמות מהירות" בכל שלבי תהליך הייצור. זוהי הגדרת מפתח #6.
ככל שנוכל לתת פידבק (היזון חוזר) בשלב מוקדם יותר על התוצר בתהליך, כך גודל הסטייה שלו מהכיוון הרצוי הינה קטנה, משמע עלות קטנה לתיקון.
היכן בשלבי הייצור ניתן לתת פידבק? בכל שלב: פידבק מוקדם מצד הפיתוח על דרישות מנהל המוצר, פידבק מוקדם מצד צוותי הבדיקות על תכנון הפיתוח, וכיו"ב.
הערה – חשוב לציין כי על מנת שפידבק מהיר יהיה אפקטיבי, חייב להתקיים גם אימוץ יעיל של הפידבק  מהצד השני (המקבל).

מפתח #7 – שיפור מתמיד
המפתח האחרון - #7, מתמקד ביכולת הבסיסית הנדרשת מכל ארגון – יכולת למידה, התקדמות, או במילים אחרות "שיפור מתמיד" (Continues Improvement).
גם אם הטמענו את כל ששת המפתחות הקודמים בהצלחה בארגון, ההצלחה אינה מובטחת לנו לאורך זמן. 
הדרך הנכונה להמשיך ולהצליח בהטמעה הינה לממש את המפתחות על תהליך ההטמעה עצמו.
כיצד?
- עלינו לוודא מנגנון המספק "פידבק מהיר" על התהליך עצמו (מפתח #6)
עלינו לוודא מצוינות טכנולוגית אשר תעלה רעיונות לשיפור התהליך עצמו (מפתח #5)
עלינו לוודא ביצוע התאמות הנדרשות בתהליך עצמו להעלאת ערך התוצר בחברה (מפתח #4)
עלינו לוודא חידוד הגדרות DOD ברמת התהליך עצמו (מפתח #3)
עלינו לוודא העברת האחריות על שיפור התהליך לצוותים, תוך התמקדות בערך העסקי (מפתח #2)
עלינו לוודא חשיבה מחודשת על מבנה הצוותים הנדרש למיצוי נכון של אתגרי החברה (מפתח #1)

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



יוגב טל, PMP
Program Manager, Agile/Lean Coach
PMI Israel E-Magazine Editor




בחזרה לעמוד הבית - מרעננים את הפיתוח


מאמרים נוספים שיכולים לעניין אותך - 



תגובה 1:

  1. יפה רשמת, אחלה כלל אצבע.
    אהבתי את השימוש במודל השיפור המתמיד,
    יש הרבה אנשים בימינו ששוכחים לחזור לבסיס, לדברים שעובדים
    כי הם נוטים לסבך ולהסתבך, חבל.

    השבמחק