דפים

יום שני, 20 באוגוסט 2012

Agile, Scrum - על מה כל המהומה


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

Agile (ניהול 'זריז') הוא אחד מה buzzwords החמים המסתובבים כיום בתעשיית ההייטק. ראשיתו הוא במפגש של 17 מומחים וחוקרים בתחום התכנה באתר סקי במדינת יוטה שבארצות הברית בשנת 2001.  במפגש זה הביעו המשתתפים את אכזבתם ממתודולוגיות הפיתוח המסורתיות אשר נכשלות לעתים קרובות מדי, וביקשו למצוא דרך טובה יותר.
ממה הם בדיוק התאכזבו? סטטיסטיקות שבוצעו באותה תקופה אשר מדדו את הצלחות הפרויקטים חשפו כי מעל ל 70% מהפרויקטים נכשלים !!
נתון מדהים לכשלעצמו ...

התוצאה של מפגש זה הוא מסמך הידוע בשם Agile manifesto המתאר את עקרונות המתודולוגיה הבאים -

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

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

Scrum - היא מסגרת לפיתוח מוצרים (להבדיל מתהליך או טכנולוגיה כפי שרבים נוטים לחשוב בטעות)
בתוך מסגרת זו ניתן להטמיע תהליכים וטכנולוגיות שונים.

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

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

קיצור לוחות הזמנים וחבילות העבודה

בוודאי נתקלתם לא פעם בפרויקטים ארוכי טווח בעלי כמות גדולה של דרישות. בשיטה המקובלת עד כה (waterfall) מושם דגש רב על ניתוח מדויק וכולל של הדרישות כשלב מקדים לתחילת הפיתוח, וזאת מתוך הכרה בפרדיגמה - 'שככל שהתכנון יהיה מקיף ומדויק יותר כך התוצר יהיה מוצלח יותר והתהליך קצר יותר' . בפועל – שלב ניתוח הדרישות אורך זמן רב, ללא ערך ללקוח (התוצר = מסמך דרישות מפורט) , וכל שינוי דרישות היווה סיכון ברמה גבוהה ביותר לעמידה בייעדי הפרויקט המקובע ב Gant.
מתודולוגית הScrum  מגדירה עבודה בלוחות זמנים קצרים יותר, בכל פעם על תכולת דרישות מתעדפת וקטנה יותר, כאשר ההתקדמות נמדדת בתוצר ממשי ללקוח.
(התהליך נקרא Sprint)

בקרה ואופטימיזציה
באותו האופן בדיוק – אם נהפוך את פגישת הסטטוס השבועית (האורכת שעה) לפגישת סטטוס יומית בת עשר דק', יוכל הצוות להתעדכן, לזהות מכשולים מראש, ולהתגבר עליהם במהלך הפעילות השוטפת. למעשה בשיטה זו נקבל את ההחזר המרבי (ROI) על הזמן שהושקע.
( התהליך נקרא Daily meeting)
נושא ההתייעלות מקבל כאן מקום של כבוד. והכוונה היא לבדוק בכל פעם מחדש את התהליך שהגדרנו, להציב בפניו אתגרים, לזהות מכשולים, להבין הצלחות, ולהגדיר את השינויים הנדרשים.
מתי נטמיע את השינויים הבאים? לא בגרסת המוצר הבאה, אלא ממש ב Sprint הקרוב. 

התמקדות בערך ללקוח
בהמשך לדוגמה הקודמת, בפרויקטים ארוכי טווח ותכולה, אחת הפרדיגמות הנפוצות הייתה 'שהלקוח נתפס כ-אישיות מטרידה, אשר אינה מבינה, ומספקת רק קשיים לארגון הפיתוח. על כן מוטב הוא שהלקוח לא יפריע ולא יתערב במהלך הפרויקט'. התוצאה במרבית המקרים היתה כישלון הן בתוצר והן בציפיות הלקוח (70% זוכרים ...). מתודולוגית הAgile  אומרת שהלקוח הוא חלק מהצוות, עליו לתעדף את הדרישות, לאשר או לפסול את תוצרי הביניים, לשנות או להוסיף דרישות חדשות (תפקיד ה Product Owner ) 
התכנית שלנו היא מבוססת ערך (value driven) ולא מבוססת תכנון (plan driven), משמע שאנחנו נמדדים על פי ההתקדמות שלנו בתוצרים עובדים (לא מצגות, לא תכניות על גאנט מרשים, ואפילו לא פיתוח לפני בדיקות) אשר אנחנו מספקים בכל שלב. 
זוהי למעשה הצורה הקרובה ביותר בה נימדד בסיום הפרויקט.

שורת סיכום
אז עד כמה יעילה מתודולוגית ה Agile ? מחקרים שנעשו בשנים האחרונות מראים שיפורים משמעותיים כמעט בכל פרמטר נמדד של חברות שהטמיעו את המתודולוגיה (איכות, תוצר, שביעות רצון לקוחות, עלויות). מה שמחקרים אלו אינם מראים זהו מימד הזמן שלוקח שלב ההטמעה. ישנם לא מעט ארגונים אשר שמעו על הצלחת השיטה, פונים אלי בבקשה להוביל את התהליך ומצפים לראות את התוצאות כבר בתוך מספר שבועות בודדים. 
חשוב להדגיש - 
1. זוהי מתודולוגיה (מוכחת, אבל עדיין מתודולוגיה) ותמיד קיים צורך להתאים אותה לצורכי הארגון.
2. כמו כל הטמעה של מתודולוגיה חדשה, לוקח זמן עד שהמערכת מתרגלת ומתייצבת ע"ב התהליכים החדשים. כמה זמן? תלוי בגודל הקבוצה, במידת שיתוף הפעולה של ההנהלה וכו' ..
בכל מקרה - ניתן בהחלט לזהות את מגמת ההשתפרות כבר בשלבים הראשונים של ההטמעה. 


בהצלחה !

יוגב טל
Senior Project Manager, PMP,
Agile Transformation Lead,

PMI Israel E-Magazine Editor

(Photo by Max Oppenheim/Stone+/Getty Images/82755182)

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








3 תגובות:

  1. אחלה מאמר, תודה:)

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

    השבמחק
  3. שלום לאנונימי,
    בנושא תעדוף תכולות - כתבתי מאמר בנושא (ראה - "ניהול ממוקד ערך - Value Focused Management")
    חשוב דווקא להבין כי השיטה אינה כלי כי אם תפיסה חשיבתית שונה. היא בעצם מניחה שבכל פרויקט שהוא יהיו שינויים אשר נצטרך להתמודד איתם. למעשה גם היום אנחנו משתמשים בכלים לניהול שינויים (כדוגמת ניהול סיכונים) אך עדיין ההשפעה של שינויים אלו על הפרויקט היא משמעותית. אג'יל מציעה דרך להתמודד עם שינויים אלו בצורה טובה הרבה יותר אשר תחזק את הפרויקט ולא תחליש אותו.
    אני ממליץ לך לקרוא מאמר נוסף שכתבתי בנושא בשם - "The Agile Mindset"
    לגבי פרויקטים המשלבים תוכנה וחמרה - זו אינה תחום המומחיות שלי לכן אמנע מלתת על כך תגובה
    יחד עם זאת, ממאמרים שקראתי בנושא מציינים את האפקטיביות של השיטה גם בפרויקטים מסוג זה.

    יוגב

    השבמחק