AGILE SOFTWARE DEVELOPMENT METHODOLOGIES AN OVERVIEW OF THE CURRENT STATE OF RESEARCH

מתודולוגיות פיתוח תוכנה זריז (Agile) :

סקירה של מצב המחקר העכשווי

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

מבוא ומוטיבציה

מאז תחילת המשבר הפיננסי העולמי הנוכחי חברות מונחות טכנולוגיה רבות סבלו מהשפעותיו, ונאלצו לפטר אנשים או להפחית באופן דרסטי עלויות (Wauter, 2009). הישרדותה של החברה עצמה הופכת להיות תלויה ב time-to-market (מרעיון המוצר ועד היציאה לשוק), לספק בזמן ללקוח ולמזער עלויות. הספרות המדעית שופעת דוגמאות שבהן הצלחת הפרויקטים מניעה את הצלחת החברות, או את הדרך האחרת סביב כישלון הפרויקט המעמיד את החברה מחוץ לעסקים ((Voas & charrette, 2005 Whittaker, 2002)), (Jones, 1995). כתוצאה מכך, צמצום הסיכון ופרויקטים מתקרבים באופן מובנה הופכים להיות קריטיים כגורמי הצלחה. במהלך השנים האחרונות פיתוח ארגוני תוכנה למדו על היתרונות של מתודולוגיות Agile, כגון Scrum ו- XP. הספרות המדעית והעיתונים העסקיים מציגים סיפורי הצלחה רבים המדגישים את היתרונות של ארגונים אשר אימצו בהצלחה שיטות Agile. כתוצאה, ארגונים רבים שואפים כעת לאמץ שיטות Agile.

סקירה כללית של מתודולוגיות Agile

Agile מייצג קבוצה של מתודולוגיות הנדסת תוכנה אשר מבטיח לספק פרודוקטיביות מוגברת, איכות והצלחה כוללת בפרויקטים של פיתוח תוכנה. מתודולוגיות כאלה הן SCRUM (Schwaber & Beedle) Agile Software Development with Scrum, 2001), XP (Beck & Andres, Extreme Programming) Explained: Embrace Change, 2004), והפחות מוכר Crystal (Cockburn, 2001). המתאר של מתודולוגיות Agile נקבעו על ידי מנשר Agile, שפורסם על ידי קבוצה של מתרגלי תוכנה (al et. Beck, 2001).

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

חקר על ההשלכות החברתיות של שימוש במתודולוגיות Agile

לכל מתודולוגיות Agile יש משותף מסוים שמדגיש את ההיבטים החברתיים של פיתוח תוכנה, לוקח בחשבון סדרה של ערכים מפורשים, כגון תקשורת (Schwaber & Beedle, Agile Software Development with Scrum,2001), או אומץ (Beck & Andres, Extreme Programming Explained: Embrace Change,,2004). כמו כן, במתודולוגיות אלה מעורבת  קבוצה של שיטות עבודה מומלצות כגון תכנות בזוג, אינטגרציה מתמשכת או פריסות יומיות (Beck & Andres, Extreme Programming Explained: Embrace Change, 2004). בספרות נמצא כי בדרך כלל לצוותי Agile בוגרים יש אחיזה חברתית וטכנית טובה יותר, כשתקשורת חיונית להצלחה (MacKenzie & Monk, 2004). כתיבת קוד מבוצעת לעתים קרובות על ידי זוגות של מפתחים, בעוד התפקידים המסורתיים בפיתוח תוכנה analyst) (tester and architect נעלמים (Năftănăilă,2008).

בעוד שהמתודולוגיות המסורתיות מסתמכות על מספר רב של מסמכים ופריטים ((artefacts, SCRUM ושאר מתודולוגיות Agile משתמשים במינימום של תיעוד, כזה המספיק רק עבור הפרויקט לרוץ תחת תנאים טובים. כרטיסי הסיפור והקיר הינם שניים מהפריטים  The role of  physical artefacts in agile) software development: Two complementary perspectives, Sharp, Robinson, & Petre,  2009) אשר נושאים שתי מטרות עיקריות: לאפשר לכידת דרישות ולתמוך בתהליך הפיתוח. הוכח כי צוותים שונים משתמשים במוסכמות שונות במקצת עבור פריטים אלו, במונחים של פריסת כרטיסים, צבעי כרטיס וארגון עקרונות לקיר. יש, עם זאת, כמה תכונות משותפות. לדוגמה, רוב סיפורי משתמשים של הקבוצות נכתבים בשפה טבעית, ומשתמשים בתבנית הידועה של XP, Beck&Fowler, Planning) Extreme Programming, 2000)  בעקבות דפוס “בתור <<תפקיד >> אני רוצה << התנהגות >> כך ש<< תועלת >> “. כל כרטיס בדרך כלל עובר דרך מחזור החיים הכללי כגון: הסיפור כתוב על הכרטיס, הכרטיס הוא לפי סדר עדיפויות של הלקוח, כרטיס מוערך על ידי הצוות, כרטיס מוקצה לאיטרציה, מיושם על ידי מפתחים, ונחשב כ”בוצע”(Schwaber, SCRUM Development Process, 1995)..

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

המחקר של (Sharp, Robinson, & Petre, The role of physical artefacts in agile software developament: Two complementary perspectives, 2009) שואף לשפוך אור על שימוש בפריטים פשוטים אלה במתודולוגיות Agile (ובמשתמע ב Scrum) על ידי ניתוח של נקודות מבט חברתיות ולא חברתיות של שימוש בכרטיסי סיפור והקיר. המחברים מוצאים כי, מלבד העובדה כי גם סיפורי המשתמשים והקיר יש להם משמעויות נפרדות משלהם, יש להן משמעויות משולבות חזקות (משמעויות המתרחשות רק כאשר משתמשים בהן יחד). לכן, מתוך פרספקטיבה לא רציונלית המחברים מוצאים כי באמצעות כרטיסי סיפור והקיר מוביל אל: קירבה של מיפוי בין המוחות של המשתמשים לבין מה שהם מנסים להביע, רמה נאותה של הפשטה, מתן משמעות לאמצעי סימון משני (למשל באמצעות צבעים, פריסה ותוויות), ומביאים לעקביות בפרויקט, צימצום פיעפוע של משמעות, להראות תלויות נסתרות, ולשפר את הנראות הכוללת בפרויקט. מפרספקטיבה חברתית, המחברים מסיקים שהסימון אינו קיים בבידוד, הוא חייב להיות ממוקם במציאות של הגדרה חברתית. לדוגמה, המחברים מראים כי ביחס לכרטיסי סיפור, הקבוצות פיתחו טיפול רב (במיוחד כאשר מטפלים בהם פיזית, במצבים כמו להזיז אותם על הקיר או לכתוב עליהם הערות).

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

ההשלכות של המאמר, במיוחד בעת יישום מתודולוגיות Agile, הן שניתן לעשות שימוש בכלי תוכנה כדי לנהל צוותים של Agile , אך רק לאחר שנוצר הקשר חברתי ומשמעותי. מדווחים מצבים שבהם לצוותים יש שני אמצעים לאחסון הפרטים: פיזית עבור חברי צוות מקומיים, ובכלי תוכנה, עבור חברי צוות מרוחקים. עם זאת, על מנת לשמור על המשמעות הפיזית של הפרטים, צוותים מגבים את כלי התוכנה עם שיחת טלפון ואפילו תמונות הקיר בזמני פיתוח קריטיים. ( Sharp, Customer collaboration in distributed agile teams, 2008).

מחקר על יישום מתודולוגיות Agile

במונחים של יישום מתודולוגיות Agile, הספרות היא נדירה למדי. אנחנו יכולים לזהות את המחקר (Nerur, Mahapatra, & Mangalaraj, 2005) המראים כי נדידה למתודולוגיות Agile כרוכה בנושאים הקשורים לניהול, אנשים, טכנולוגיה ותהליכים.

במונחים של קבלה של מתודולוגיות Agile, אנו יכולים לזהות את המחקר המשמעותי של (Chan & Thong, 2009) אשר מנסה להתמודד עם מה ניתן לעשות כדי להתגבר על אתגר קבלת מתודולוגיות Agile. הם מספקים סקירה ביקורתית של הספרות הקיימת על קבלת מתודולוגיות מסורתיות SDMs ו Agile, ולפתח מסגרת קונספטואלית  עבור קבלת מתודולוגיות Agile המבוסס על פרספקטיבה של ידע ניהולי.

מבוסס על עבודה קודמת על מתודולוגיות Agile (בעיקר מקרים לימודיים) בעיתונים כגון (Ceschi, Sillitti, Succi, &Panfilis, 2005), או (Cohn & Ford, 2003) הם מציעים מסגרת קונספטואלית לגבי קבלת מתודולוגיות .Agile הם מציעים שורה של גורמים, כגון (א) גורמים הקשורים ליכולת (יעילות עצמית, ניסיון,הדרכה, תמיכה חיצונית), (ב) גורמים הקשורים למוטיבציה (השלכות על הקריירה, תמיכה מראשי הניהול, התנדבות, נורמה סובייקטיבית, תרבות ארגונית), (ג) גורמים הקשורים להזדמנויות (עבודת צוות, תקשורת, הבנה משותפת, יחסים מפרך) השפעה על תוצאות ניהול ידע (יצירת ידע, שימור והעברה). תוצאות ניהול ידע, מצד שני, יחד עם מאפייני מתודולוגיית Agile (שימושיות, תפיסה קלה של שימוש, תאימות נתפסת, נתפסת הפגנות, בגרות נתפסת) מובילה לקבלה.

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

מסמך נוסף המציע מסגרת ליישום ושיפור מתודולוגיות Agile בפועל הוא (Qumer & Henderson-Sellers, 2008). המחברים יוצאים מן ההשערה כי בפועל, ארגונים מעטים מסוגלים לקחת גישת פיתוח זריז מיידית ולאמץ אותה בהצלחה על פני תקופה קצרה – במקרים רבים, יישום מלא דורש שנים. המחברים מציגים ומסבירים את תוכנת Agile כפתרון מסגרת ( (Framework (ASSF). בעת בחינת המודל המוצע, המחברים הוכיחו (אם כי מדובר בממצאים עקיפים מהמחקר שלהם) ש- SCRUM מציג את דרגת הזריזות הגבוהה ביותר במונחים של תרגול. פתרון למסגרת(Framework) בתוכנת Agile (ASSF) המוצע על ידם, ניתן להשתמש בו כדי ליצור, לשנות או להתאים את המצב הספציפי בתוכנה Agile באמצעות גישה הנדסית לשיטת מצבים, משוב ומודל-העל סטנדרטי. המחברים הטמיעו מספר מודלים ותהליכים חדשים ב- ASSF, כגון מודל למדידת זריזות ותהליך, מסגרת פתרון תוכנה זריז ותהליכי הנדסה וניהול מבוססי ידע, סביבת עבודה זריזה וערכת כלים של Agile.

מחקרים על תקשורת בפרויקטים של Agile

בספרות הקודמת על ניהול פרויקטי תוכנה הוכח כי התקשורת היא גורם הצלחה חשוב (Stelzer & Mellis, 1998), וכי התקשורת נחשבת כעוזרת לפיתוח תוכנה להיות יעיל יותר בחברות (Pasasiva & Lassenius, 2003). נראה כי הבעיה העיקרית נובעת מהעובדה שכל השחקנים בתהליך פיתוח התוכנה (משתמשים, לקוחות, צוות, צוות תחזוקה, ניהול) צופים ומתקשרים על אותו מוצר מנקודות מבט שונות: משתמשים דורשים שלמוצר תהייה מידת שימושיות גדולה, לקוחות מחפשים אמינות ועלויות תחזוקה נמוכות, כמו גם זמן מהיר לשוק (time-to-market), מנהלים מחפשים לצמצם עלויות, צוותי תחזוקה מחפשים תיעוד ואמינות, בעוד צוות הפיתוח מחפש אתגרים טכניים ולעבור לפרויקט הבא (Boehm & Ross, 1989).

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

המחקר שלהם (תחת ניסיון לשמור על מחקר איכותני, המבוסס על שני מקרי מחקר שנעשו באותו ארגון) מציג כמה מסקנות מעניינות במונחים של תקשורת בפרויקטים. לדוגמה, SCRUM שמה דגש רב על המפגשים היומיומיים, הנתפסים באופן כללי כמסייעים בהפחתה של הבלבול לגבי מה צריך להיות מפותח (מאן & מאורר, 2005). מצד שני המחברים, מתייחסים בעבודתם של (Murru, Deias, & Mugheddue, 2003), מציעים שפגישות תכנון זריזות עשויות לגרום לסיכון כי הלקוחות התובעניים מקבלים את מה שהם רוצים והם מועדפים על ידי גישה זו, אבל ההחלטות לא תמיד מנותחות בפירוט מספיק מנקודת מבט טכנית, המוביל במרומז להשפעה שלילית על מטרת הפרויקט הכוללת. דוגמה נוספת מתייחסת לתפיסת החלל הפתוח: אם כי בדרך כלל החלל הפתוח הסביבה נתפסת כפרודוקטיביות יותר בפיתוח תוכנה, המחברים מצאו עדויות למצבים שבהם הגדרת מרחב פתוח נתפסה כמסיחה. כמו כן, כשזה מגיע לתקשורת בין צוות הפרויקט לבין בעלי העניין בפרויקט (לקוח, ניהול וכו ‘), המסקנות של (Turner,2003) לגבי העובדה כי מנגנוני תקשורת מוגבלים פורמלית ובלתי פורמלית יכולים לעכב תקשורת בין צוותי פרויקט פיילוט בהקשר של פיתוח תוכנה זריז אושרו על ידי המחברים. עבודתם של (Rising & Janoff,2000)  אושרה גם על ידי (Pikkarainen, Haikara, Salo, Abrahamsson, & Still, 2008), בתמיכה בהשערה לפיה איטרציות קצרות של זמן שמוקצה לפעילות בפיתוח תוכנה זריז הם הסיבה העיקרית לשיפור תקשורת בצוותי פיתוח תוכנה.

מחקרים אמפיריים בנושא מתודולוגיות Agile

נטען כי במחקר הנוכחי יש רק כמה מקרי חקר לימוד בנושא פיתוח תוכנה זריז  (Layman, Williams, & Cunningham, 2006). אמנם זה נכון, יש כמה מסמכים אשר חקרו אמפירית שיטות Agile, כגון Scrum או XP. למשל, המסמך של (Salo & Abrahamsson, 2008) מביא סדרה של ממצאים מעניינים ממחקר אמפירי של Scrum ו- XP בארגוני פיתוח תוכנות משובצות אירופיות; למשל, המחברים מראים כי 77% מהמשיבים אשר השתמשו ב Scrum דיווחו על חוויות חיוביות, בעוד ש 27% מהנשאלים תבעו להשתמש ב- Scrum באופן שיטתי או עיקרי במהלך פרויקט. עם זאת, מספר המחקרים האמפיריים נותר נמוך, ויש לערוך מחקר נוסף באיזור הזה.

מסקנות ומחקרים נוספים

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

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

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