מדוע כדאי לשלב אג'יל בניהול פרויקטים

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

במאמר הפעם אתמקד ביתרונות שנותנת השיטה בתחום ניהול הפרויקטים.

מהו אג'יל (בפורמט תקציר מנהלים)

אג'יל היא מתודולוגייה אשר פותחה בשנת 2001 ע"י מומחים בעלי שם בעולם התוכנה, ובראש מעיניה התאמת מתודולוגיות הפיתוח לתנאי השוק החדשים. ה'שוק החדש' מאופיין בעיקר בשינויים טכנולוגיים מהירים הדורשים תגובה 'זריזה' (Agile) מצד הפיתוח. המתודולוגייה מתארת את בעלי התפקידים (R&R) , התהליכים (Ceremonies) והכלים (Artifacts) אשר בעזרתם ניתן לממש את השיטה. (הרחבה בנושא אג'יל ניתן למצוא כאן)

איום או רווח

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

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

האם הדבר פוגע ביכולת מנהל הפרויקט להוביל את הפרויקט להצלחה?

על מנת לענות על שאלה זו, נבחן מספר עקרונות בסיסיים של השיטה -

Welcome Change

“Welcome changing requirements, even late in development” (Principle #2 Agile Manifesto)

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

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

אג'יל למעשה מציעה פתרון יעיל כאמצעי להתמודדות עם מצבים מסוג זה.

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

Self Driven team

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.” (Principle #5 Agile Manifesto)

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

ישנם הרבה מנהלי פרויקטים אשר ימצאו איום במילים "trust them to get the job done".

למנהלים אלו קשה לקבל שיתוף ואחריות הדדית, ויחפשו תמיד להסתמך על עצמם ועל המדדים שיצרו.

(תארתי מנהלים מקבוצה זו בהרחבה במאמר קודם שלי – גישות מוטעות בניהול פרויקטים)

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

לגבי מדדים – מדדי ההתקדמות הם built-in בשיטה, ומספקים תמורה מספקת בהחלט.  

Value Driven

“Working software is the primary measure of progress.” (Principle #7 Agile Manifesto)

האם סיום שלב הפיתוח הוא מדד להתקדמות ? או שמא סיום שלב הבדיקות?

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

אני יכול לחשוב על מספר כיוונים שיכולים להוות איום – החל מ- כלל התחנות שמוצר התוכנה חייב לעבור בכדי לדווח התקדמות, ועד לאותו Product Owner אשר ביכולתו לאשר או לפסול את התוצאה.

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

התקדמות ע"ב value ולא ע"ב Plan (כפי שמציע אג'יל) ואישורו (הייצוגי) של הלקוח הינם רווח נקי למנהל הפרויקט אשר מקבל תמונת מצב מדויקת, מאושרת (verified), והכי קרובה למציאות.

שורת סיכום

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

  

בהצלחה !

*אם יש לכם תהיות והתלבטויות הקשורות לייעוץ והכוונה בנושא –

צרו קשר – yogev05.t@gmail.com

יוגב טל, PMP

Picture source - http://leadinganswers.typepad.com/.a/6a00d834527c1469e20120a8d0b205970b-320wi

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

גישות מוטעות בניהול פרויקטים

?Who is the Agile Project Manager

אפקט האג'יל

אתחול פרויקט בחשיבה אג'ילית

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