איכות עבודת צוות והצלחת פרויקט פיתוח תוכנה Teamwork quality and project success in software development – A survey

איכות עבודת צוות והצלחת פרויקט פיתוח תוכנה: סקר של צוותי פיתוח agile (זריז)

תקציר

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

מבוא

שיטות Agile קיימות כבר בשימוש נרחב בהנדסת תוכנה בעשור האחרון. למרות ששיטות פיתוח agile מדגישות עבודת צוות יותר מאשר שיטות הפיתוח המסורתיות (Nerur et al.2005), אין חקירה מעמיקה של השפעת עבודת צוות איכותית (TWQ) על הצלחת הפרויקט בצוותי פיתוח agile.

שיטות פיתוח agile משמשים כמושג מטריה לתאר מספר שיטות פיתוח (Dingsøyr et al., 2012;Dybå and Dingsøyr, 2008). המניפסט של agile תומך ב”תוכנה עובדת על פני תיעוד מקיף”, “שיתוף פעולה של הלקוח על פני חוזה משא ומתן “, ו”להגיב לשינוי על פני מעקב אחר התוכנית “. לפיכך, להגיב בזריזות לשינוי, חברי הצוות צריכים לעבוד באופן הדוק יותר, ולהיות בתקשורת לעיתים תכופות יותר, להיות מודעים למאמץ עבודה של חברי צוות אחרים, ולהיות מסוגל להעביר את עומס העבודה בין אנשים. ליתר דיוק, המניפסט של agile קובע כי הארכיטקטורות הטובות ביותר, דרישות, ועיצובים נוצרו מצוותים המארגנים את עצמם; התקשורת הטובה ביותר היא תקשורת פנים אל פנים; ואנשי עסקים ומפתחים צריכים לעבוד יחד מדי יום. שיתוף פעולה ותיאום הם מרכזיים גם בספרות agile (Sharp and Robinson, 2010; Strode et al., 2012). בשיטת agile הפופולרית ביותר, Scrum, העבודה מאורגנת בצוותים קטנים ובין-תחומיים עם מנחה וחברי צוות. חברי הצוות מתאמים  את עבודתם בתדירות גבוהה, כמו בפגישות עמידה יומיומיות (Stray)et al., 2016). Vinekar et al. (2006) מסבירים כי לפיתוח agile ולפיתוח מסורתי יש דעות שונות על עבודת צוות.

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

מספר מחקרים חקרו את ההשפעה של איכות עבודת צוות (TWQ) על הצלחת הפרויקט בצוותי תוכנה מסורתיים (Hoegland Gemuenden, 2001; Hoegl et al., 2003; Hoegl et al., 2004; ג’אנז,1999; Li et al., 2010; ריאן ואוקונר, 2009; Vinod et al., 2009).המחקר של Hoegl and Gemuenden (2001) שצוטט לעתים קרובות, למשל, מראה את ההשפעה של TWQ על ביצועי הצוות והצלחת הצוות עבור קבוצה של צוותי פיתוח תוכנה מסורתיים.

בשל חוסר מחקרים על ההשפעה של TWQ בצוות agile, ערכנו סקר בנושא זה על ידי שכפול המחקר Hoegl ו Gemuenden (2001). שאלות המחקר שלנו היו:

RQ1: מהי ההשפעה של TWQ על הביצועים של צוותי תוכנה agile?

RQ2: מה ההשפעה של TWQ של הצלחת חברי הצוות בצוותי תוכנה agile?

RQ3: כיצד ההשפעה של TWQ על ביצועי צוות ההצלחה של חברי הצוות נבדלת בין צוותי  agile לצוותים מסורתים?

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

2. מודל עבודה קשור ורעיוני

2.1. עבודת צוות בפיתוח תוכנה

עבודת צוות היא ללא ספק חשובה בפיתוח תוכנה. במחקר המסורתי, המחקר של  Faraj and Sproull (2000) הראה קשר חזק בין ניהול מומחיות וביצועי צוות. מחקר נוסף הראה את חשיבות הלמידה השיתופית על הצלחת הפרויקט לצוותי פיתוח התוכנה (Janz, 1999). בפיתוח agile, כמה מחקרים ניתחו את עבודת צוות באמצעות מודלים ביצועים צוות, כגון זו שנמצאה ב  Moe et al. (2010). Sharp and Robinson (2010) תיארו כיצד צוותי פיתוח agile מאפשרים שיתוף פעולה, תיאום ותקשורת. מחקר נוסף Pikkarainenet al. (2008), התמקד כיצד שיטות פיתוח agile משפרת  את התקשורת, וטען כי שיטות Scrum ו- XP משפרות את התקשורת הפורמלי והלא פורמלית. Maruping et al. (2009) הוכיח כי שיטת XP של בעלות קוד משותף ותקני קידוד יכולים להעלות את האיכות הטכנית של מוצרי תוכנה. סקר של גורמי ההצלחה של פיתוח agile מצא כי יכולת הצוות היה אחד הגורמים (Chow and Cao, 2008).

מודלים מפורטים המציגים קשרים בין היבטים שונים של איכות עבודת צוות וביצועי צוות שימשו במחקרים של צוותי תוכנה; למשל, אלה המתוארים  Hoegl and Gemuenden (2001), Salas et al. (2005), Dickinson and McIntyre (1997) and Janz (1999).. (2005). בעבודה זו, אנו מתמקדים בגורמים המתוארים על ידי   Hoegl and Gemuenden (2001).

2.2 איכות עבודת צוות (TWQ)

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

TWQ הוא קונספטואליזציה כמו בניית סדר גבוה יותר המבוסס על מודל הקלט של תהליך הקלט של Hackmanעל התנהגות ויעילות קבוצתית (Hackman, 1987) ונגזר מ McGrath (1964). שישה תתי מבנה של תקשורת, תיאום, מאזן של תרומת חברים, תמיכה הדדית, מאמץ וכיסוי קישוריות אמצעים רלוונטיים לביצוע של אינטראקציה פנימית בצוותים; ראה טבלה 1. תיאור מפורט יותר.

2.2.1 תקשורת

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

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

2.2.2 תיאום

Malone and Crowston (1994) מתארים תיאום כ”ניהול תלויות בין פעילויות “. תלויות אלו כוללות משאבים משותפים, הקצאות משימות וקשרי משימות / משימות משנה. פעילויות רבות בתהליכי משימות מוקצות לחברים בודדים. הרמוניזציה וסינכרון של פעילויות אינדיבידואליות אלה חשובים עבור ה- TWQ והצלחת הפרוייקט (Tannenbaum)et al., 1992; ברניק ואחרים. 1995). צוותים צריכים להסכים על מבנים משותפים לפריקת העבודה, לוחות זמנים ומאמצים הדרושים עבור המשימות. תיאום פירושו שצוותים חייבים לפתח ולהסכים על מבנה מטרה משותף הקשור למשימות שיש לו מספיק תת-משימות ברורות עבור כל חבר צוות. צוותים ב agile, משימות לעתים קרובות נבחרות או מואצלים בעת תכנון איטרציה חדשה. באיטרציה נתונה, חלק מ”סיפורי משתמש” (דרישות) בצבר ההזמנות מקבלות תיעדוף. סיפור משתמש לעתים קרובות מחולק למספר משימות. עומס העבודה עבור המשימות נאמד וכל משימה מתוכננת או נבחרת על ידי אחד או יותר מחברי הצוות.

2.2.3 מאזן תרומת החבר

תרומת הידע והניסיון הרלוונטיים למשימה מכל החברים לתהליכי קבלת ההחלטות של הצוות היא לטובת הצוות (Hackman, 1987; Seers et al., 1995). תרומה מאוזנת היא קריטית בצוותי תוכנה עם חברים שיש להם מומחיות בתחומים שונים (פיתוח ליבה, פיתוח GUI,ארכיטקטורת המערכת, בדיקות וכו ‘). אם רק אחד או אפילו רק כמה חברי הצוות שולטים בדיונים, האחרים עשויים להיות בעלי פחות מוטיבציה לעבודה, אשר בתורו עלול לעכב את ביצועי צוות הכוללים. המפגשים היומיים (Stray et al., 2016) בצוותי agile תומכים באיזון כזה של תרומת חברים.

2.2.4 תמיכה הדדית

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

2.2.5מאמץ

חברי הצוות צריכים לעשות כמיטב יכולתם כדי לתמוך במשימות של הקבוצה.. Hackman (1987) מתאר תנאים התומכים במאמץ, ואומר שחשוב “שאינטראקציה בין חברים תמזער את ההתבטלות החברתית ובמקום זאת תקדם את המחויבות המשותפת בין חברי הקבוצה לצוות ולעבודתו.” תיעדוף משימות של צוות על משימות אחרות הוא אינדיקטור טוב למאמץ שחברי צוות משקיעים במשימות משותפות  (Hackman, 1987; Pinto and Pinto, 1990). בקבוצת מיקוד במחקר של מה מעכב ומה מעודד עבודת צוות יעילה בצוותי agile, מתן עדיפות למשימות של הצוות נתפסו כאחד הגורמים החשובים ביותר עבור השגת ביצועי צוות טובים יותר (Dingsøyr and Lindsjørn, 2013).

2.2.6 לכידות

הגדרה משותפת של לכידות קבוצתית היא “תהליך דינמי אשר באה לידי ביטוי בנטייה של הקבוצה להיצמד יחד ולהישאר מאוחדים במרדף אחר מטרותיה ויעדיה” (Mudrack, 1989). Mullen and Copper (1994) מבחינים בין שלושה היבטים של לכידות קבוצתית: (1) מחויבות למשימות הצוות, (2) משיכה בין אישית של חברי צוות, ו (3) קבוצת גאווה / צוות הרוח. בסקר של 31 צוותי תוכנה, נמצאה לכידות קבוצתית גורם השולט בבדיקת ההשפעה של לכידות קבוצתית, ניסיון קבוצתי ויכולת צוות על ביצועי צוות (Lakhpanel, 1993). בצוותי agile, החברים ממוקמים לעתים קרובות קרוב למשרד. על פי מודל התפתחות agile של, יחידים והאינטראקציות שלהם מוערכים מעל תהליכים וכלים, ובכך חושפים את הערך של לכידות קבוצתית.

2.2.7  TWQ בפיתוח מסורתי לעומת פיתוח agile

מבני המשנה של TWQ לובשים צורות שונות בפיתוח מסורתית ובפיתוח .agile

טבלה 2 מדגישה חלק מההבדלים.

2.3 הצלחת פרויקטים בפרויקטי תוכנה

ההמשגה של הצלחת הפרויקט כמשתנה כמבנה רב-משתני מתואר ב Gladstein (1984) is described in Gladstein (1984), Hackman (1987), Sundstrom et al. (1990), Pinto et al. (1993) and Denison et al. (1996).  . ספרות זו מבחינה בין תוצאות הקשורות למשימה למשל, איכות של מוצר תוכנה ועלות ותקציב) ותוצאות הקשורות לאנשים (למשל, שביעות רצון חבר הצוות וכדאיות הצוות). במחקר זה, אנו משתמשים בתוצאות בקטגוריות של ביצועי צוות והצלחת הצוות; ראה טבלה 3

2.3.1 ביצועי צוות

ביצועי הצוות עשויים להיות מוגדרים כ”מידה שבה הצוות מסוגל לעמוד באיכות שהוקמה, עלות, זמן מטרות ” (Hoegl and Gemuenden, 2001). מודלים רבים של ביצועי צוותים ומסגרות של צוותי עבודה מתארים TWQ ואת הקשר שלו לביצועי הצוות באופן כללי, כגון e.g., Mathieu et al. (2008), Cohen and Bailey (1997) and Rasmussen and Jeppesen (2006).  .

ביצועי הצוות ויעילות הצוותים משמשים לעתים קרובות במילה נרדפת בספרות; לפעמים הביצועים של הצוות הם חלק מאפקטיביות הצוות, למשל, , Cohen and Bailey (1997) ולפעמים יעילות הצוות היא חלק מביצועי צוות, למשל,

Hoegl and Gemuenden (2001). רוב המודלים של ביצועי צוות (או יעילות צוות) מקורם במדע הניהול ופסיכולוגיה (Salas et al., 2007). במחקר זה, ביצועי צוות מתוארים במונחים של אפקיביות של תתי מבנה ויעילות. האפקטיביות מתייחסת למידת ההתמודדות של הצוות ציפיות לגבי איכות המוצר. האיכות של מוצר תוכנה נמדדת לעיתים קרובות על ידי הלקוח, וכוללת היבטים כגון פונקציונליות, חוסן, אמינות וביצועים. היעילות מתייחסת למידת עמידתה של הקבוצה בציפיות לגבי איכות הפרויקט.

2.3.2 הצלחת חברי הצוות

צוותים צריכים לעבוד בצורה שמגדילה את המוטיבציה של חברי הצוות ויכולתם לעסוק בעבודת צוות עתידית

 (Hackman, 1987; Sundstrom et al., 1990). ברור כי ההצלחה של חברי הצוות מגבירה את המוטיבציה שלהם לעבוד על פרויקטים עתידיים של אותה קבוצה. שיתוף פעולה עם חברי צוות אחר גם מספקת הזדמנות ללמוד מיומנויות חברתיות, ניהוליות, טכניות ויצירתיות. בחלק ממודלים של ביצועי צוות למשל, Janz (1999), הלמידה מוגדרת כאחת ההיבטים של TWQ, ולכן נתפסת כתרומה להצלחתו של הפרויקט – התוצאה שלו – ולא כחלק מהתוצאה עצמה.

2.4 דגם קונספטואלי

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

Hoegl ו Gemuenden (2001)  נותנים תיאור מפורט של שניהם, הרציונל התיאורטי והעדויות האמפיריות ליחסים החיוביים בין TWQ לבין ביצועי צוות התוכנה והצלחת חברי הצוות. מבנה TWQ מספק מידה של תהליך שיתוף הפעולה של הצוות, המתמקד באיכות של אינטראקציות. במחקרים אחרים, הוכח כי שיתוף פעולה בתוך צוותים משפיע הן על ביצועי הצוות והן על הצלחת חברי הצוות.

אנו לא מודעים לכל תיאוריה או מחקרים קודמים אשר מצביעים על הבדל בין התפתחות פיתוח מסורתי ופיתוח agile בהקשר של השפעה של TWQ על ביצועי צוות והצלחת חברי הצוות. אף על פי כן, אנו חוקרים הבדלים כאלה ב- RQ3.

3. שיטת מחקר

סקר זה היה שכפול מובחן (Lindsay and Ehrenberg, 1993). Hoegl and Gemuenden (2001)  חקר צוותים מסורתי; חקרנו צוותי agile. לשם הפשטות, נתייחס לשני סקרים, בהתאמה, הסקר המסורתי וסקר agile.

3.1 מדגם המחקר

הקריטריונים להשתתפות במחקר שלנו היו כי צוות השתמש במתודולוגיה  agile במשך שנה לפחות, והוא סיפק תוכנה ללקוח לפחות פעם אחת. צוותים גויסו בוועידת Agile הנורבגית בנובמבר 2011, אשר משכה כ -400 משתתפים מ -100 חברות. אנחנו גייסו 71 צוותים מ -26 חברות כמשתתפים בסקר שלנו. צוותים אלה כללו 76 ראשי צוותים, 78 בעלי  מוצרים ו323 חברי צוות. שנים עשר חברות תרמו רק צוות  אחד בסקר; שאר החברות תרמו בין 2 ל 11 צוותים. החברות פעלו בתחומי היישום הפיננסי, התקשורת, המשלוח, הנפט, וייעוץ, שניהם (75%) מהמגזר הפרטי ו(25%) מהמגזר הציבורי. הם שונים מחברות ייעוץ קטנות עם פחות מ -10 מפתחים לחברות גדולות עם כמה מאות מפתחים. בין צוותי גייס, 16 היו צוותים “מעבר לחוף” ממוקמים בהודו,סין ומלזיה. רוב הקבוצות השתמשו ב- Scrum (69%); האחרים השתמשו ב Kanban (19%) וכן שילוב של Scrum, Kanban, וXP (12%). צוותי Scrum השתמשו בפגישות עמידה יומיות, איטרציות של תכנון, איטרציות של ביקורות ופגישות רטרוספקטיביות. מרווח האיטרציה היה 2.8 שבועות בממוצע. מפגשי עמידה יומיים השתמשו גם בצוותי Kanban. מרווח השחרור היה 4.3 חודשים בממוצע עבור כל הקבוצות.

לוח 4 מראה כי בקרב הנשים היו יותר נשים ראשי צוותים ובעלי מוצרים (כ 1 ב 3) מאשר בקרב חברי צוות (כ 1 ב 6). לחלק מראשי הצוות היו תפקידים אחרים בצוות (בעיקר מפתח), אבל הם ענו על הסקר בתפקיד של ראש צוות. יתר על כן, לחלק מחברי הצוות היו יותר מתפקיד עבודה אחד בצוות. תפקידם העיקרי של חברי הצוות היה מפתח (73%), בודק (14%), ואדריכל מערכת (7%). תפקידים אחרים היו GUI מעצב, צוות תמיכה, מנהל תצורה, ואחראי QA.

אפשר לשאול אם כל הקבוצות שהשתתפו בסקר שלנו היה agile. זה לא עניין טריוויאלי כי אין הגדרה ברורה של מה הוא צוות agile. עם זאת, אנו רואים צוותים במחקר כצוותי  agile כי (1) כל הקבוצות ציינו בסקר כי הם השתמשו Scrum, Kanban, XP, או היברידית, וכן (2) אנשי הקשר של החברות שאליהן פנינו בכנס הנורבגי Agile טען כי הקבוצות שהשתתפו בסקר היו agile.

3.2 איסוף נתונים

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

עבור כל פריט בשאלון (טבלה 7, נספח א ‘) התבקשו המשיבים לציין את הסכמתם עם הצהרה על סולם מ 1 (לא מסכים בכלל) ל 5 (למסכים מאוד) מנקודת המבט האישית שלהם, ולא מכל מה שחשבו שהוא עשוי להיות נקודת המבט של כל הקבוצה. חברי הצוות הגיבו לכל 61 פריטים בשאלון, בעוד שראשי הצוות ובעלי המוצר הגיבו רק ל 15 פריטים שבדקו ביצועי צוות במיוחד.

3.3 משתנים שנחקרו

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

טבלה 5 מציגה את הנתונים הסטטיסטיים של 14 המשתנים המשמשים למדידת TWQ, הצלחת חברי הצוות, וביצועי הצוות כפי שהוערכו על ידי חברי צוות, ראשי צוותים ומנהיגי פרויקטים, בהתאמה. כל משתנה מיוצג כממוצע אריתמטי של פריטים בודדים המרכיבים את המשתנה. את כל המשתנים ניתן לראות כמתחלקים בדרך כלל לפי Shapiro-Wilk הבדיקה של נורמליות כפי מיושם SPSS 23, למעט יעילות ראשי  צוות (p = 0.011), אפקטיביות ראשי  צוות (p = 0.025) והיעילות של בעלי המוצר (p = 0.010). מצאנו  רק הבדלים שוליים בתוצאות המדווחות לאורך מאמר זה בעת הסרת תצפיות שגרמו לחוסר נורמליות. כדי לשמר את הכוח הסטטיסטי, שמרנו על התצפיות הללו.

בטבלה 5  יש גם דוחות של אלפא של Cronbach, זהו נתון סטטסי עבור אמינות עקביות פנימית. ערכי אלפא של Cronbachחושבו ברמת הקבוצה, כלומר, על הערכים המצטברים. level, that is, on Nunnally and Bernstein (1994)  החשיבו את אלפא של Cronbach כגבוה מ 0.7 כמשביע רצון. כל המשתנים היו משביעי רצון, למעט איזון של תרומת חבר, אשר ערך אלפא של 0.58. מטריצת המתאם של המשתנים הנחקרים מוצגת בלוח 6.

3.4 ניתוח סטטיסטי והמודל הנבדק

אישור ניתוח סטטיסטי בוצע באמצעות ניתוח משוואות מבניות  (SEM) כפי שמיושם בחבילה lavaan (Rosseel, 2012) באמצעות R (R Core Team, 2015).. לא חסרו נתונים.כל הפרמטרים נאמדים באמצעות הסתברות מקסימלית עם התפלגות “wishart”.

SEM מאפשר אפיון של מערכת משוואות עבור שני סוגים עיקריים של מודלים בו זמנית (Anderson and Gerb ing, 1988). ראשית, מודל המדידה מציין כיצד קבוצה של משתנים יכולים לייצג מושג של עניין. הפרדת נתונים אנליטית בלבד  היא האם משתנה נצפה או סמוי (Borsboom, 2008). כדי להיחשב “נצפה”, הנתונים חייבים להיות זמינים ישירות(כמו 14 המשתנים שדווחו בלוחות 5 ו 6). לעומת זאת, משתנים חבויים נאמדים ממשתנים נצפים בתוספת שגיאות, או ממאגרים של משתנים סמויים אחרים. במחקר זה, מודלי המדידה הנחקרת הם כדלקמן: TWQ מיוצג כמשתנה סמוי עם שישה משתנים נצפים שבהם גורם עומס יכול להשתנות (כלומר, מודל congeneric). ישנם ארבעה משתנים סמויים אחרים: הצלחת חברי הצוות, והביצועים שהצוות דיווחו, בהתאמה, חברי הצוות, מנהלי פרויקטים ובעלי מוצרים. כל אחד מארבעת המשתנים הסמויים הללו מיוצג על ידי שני משתנים נצפים עם גורם עומס שווה (כלומר, מודל שווה-ערך של טאו). שגיאת מדידה בכל חמשת המודלים מוגדרת כבלתי מתואמת.

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

הבדיקה של המודל מתאימה למדידה ולמודלים מבניים ומבוססת על שונות; כלומר, מטריצת שונות שנוצרה על בסיס המודלים משווית עם מטריצת ​​השונות של הנתונים בפועל. הבדלים בין שתי מטריצות השונות האלו, יענו על השאלה האם הנתונים מתאימים לדגם שצוין. מטריצת השונות עבור הסקר agile חושבה מהמשתנים המדווחים בלוחות 5 ו  6 . מטריצת השונות של הסקר המסורתי חושבה באמצעות מטריצת המתאם, ממוצעים וסטיות התקן שדווחו ב Hoegl & Gemuenden (2001). אנו מדווחים על מודל שמתאים על ידי שורש ממוצע ריבוע שגיאה של קירוב (RMSEA) ורווח סמך 95% שלה. ערכי RMSEA מתחת ל -0.05 מצביעים על מודל מתאים בקירוב; ערכים סביב 0.08 מצביעים על מודל מתאים מקובל והערכים מעל 0.10 מצביעים על מודל מתאים לא מקובל.

3.5 התאמת המודל

ניתוח גורמי האישור של מודל המדידה עבור TWQ הצביע על התאמה כמעט הדוקה למודל (χ2 [9] = 10.73, p = 0.30, RMSEA [רווח סמך 95%] = 0.052 [0.000-0.150]) 5 עם זאת, כפי שצוין על ידי מרווח ביטחון רחב עבור RMSEA, אחד לא יכול לטעון בביטחון מספיק כי המודל מתאים כי רווח הסמך העליון (0.150) הוא מעל הלא מקובל (כלומר, 0.10). שים לב כי הקריטריון של Kaiser ו Cattell’s ותרשים scree התקבלו: מרכיב אחד יכול להיות שחולץ עם ערך עצמי מעל 1 והיה “מרפק” ברור בתרשים ערך עצמי. עם זאת, שני קריטריונים אלה הם יותר בדומה להיוריסטיקה, והם מרוצים יותר בקלות ממבחני האישור שאנו מדווחים.

כל גורמי העומס המעורבים היו משמעותיים (p <0.001). המודל הכללי של התאמה של הנחקר (מדידי ומבני) היה מודל קצת יותר גרוע מאשר מודל המדידה של TWQ לבדו (χ2 [71] = 100.64, p = 0.012,RMSEA = 0.077 [0.038-0.110]). בנוסף לכוח סטטיסטי נמוך על דחייה של מודל הולם, היו גם בעיות עם אינדיקטורים מתואמים מאוד, וכתוצאה מכך מטריצה ​​מוגדרת שאינה ניתנת להגדרה במהלך האמידה, ראה למשל, (Wothke, 1993) ושונות שגיאות שלילית. על ידי הסרת שני משתנים סמויים של הצלחת חברי הצוות ואת הביצועים של בעל הפרויקט (יחד עם ארבעת המשתנים המחוונים שלהם), הבעיות הללו נפתרו והתאמה הכוללת של המודל השתפרה (χ2 [34] = 38.26, p = 0.28, RMSEA = 0.042 [0.000-0.100]), עם שינויים זניחים למשקלות רגרסיה וגורם העמסה עבור המשתנים הנותרים.

4. תוצאות

סעיף 4.1 מדווח על התוצאות עבור שאלות מחקר 1 ו -2.

סעיף 4.2 מדווח על תוצאות שאלת מחקר 3.

4.1. הקשר בין TWQ לבין המשתנים התלויים

איור 2 מציג את התוצאות עבור המודל הנחקר. המשתנים הנחקרים מיוצגים כמלבנים ומבנים מיוצגים כאליפסות (כלומר, משתנים סמויים). חצים ללא מוצא מראים שונות השגיאה, והחצים ממשתנים חבויים למשתנים הנצפים מראים את הגורמים המתוקננים. כל גורם עומסים הם משמעותיים ב p < 0.001. .חצים מ- TWQ לארבעה משתנים חבויים תלויים מראים את מקדמי נתיב (מבניים).

באיור, התיאום היה שונות השגיאה הגבוהה ביותר (0.78) והגורם הנמוך ביותר טוען על TWQ (0.47); מקדם הנתיב המבני הנמוך ביותר היה מ- TWQ לביצועי הקבוצה כפי שדורגו על ידי בעל המוצר (0.06). יש לציין כי מקדמי הנתיב נאמדים סטנדרטית כך שעלייה של סטיות תקן אחת במשתנה בלתי תלוי יביא לעלייה בסטיית התקן כפי שניתן על ידי המקדם הנאמד. לדוגמה, המקדם המשוער של 0.997 (מעוגל ל -1.00 באיור) בין TWQ לבין הצלחת חברי הצוות מרמז על עלייה של

1 SD ב TWQ יהיה עם רווח סמך 95% תוצאה של גידול צפוי של 0.95-1.05 SD בהצלחת חברי הצוות.

לגבי שאלת מחקר 1, TWQ משפיע באופן משמעותי על הביצועים של הצוות כאשר הביצועים מדורגים על ידי חברי הצוות (p <0.001) וראשי צוותים (p = 0.010). ההשפעה גדולה עבור הדירוג של חברי הצוות (R2 = 0.466) ו בינוני עבור הדירוג של ראשי צוותים (R2 = 0.104). ל- TWQ אין השפעה על הביצועים של הצוות כאשר הביצועים מדורגים על ידי בעלי המוצר (p = 0.593, R2 = 0.004).

לגבי שאלת מחקר 2, TWQ משפיע באופן משמעותי על ההצלחה של חברי הצוות, אשר דורגו על ידי חברי צוות בלבד (p <0.001). ההשפעה היא גדולה, כמעט אחדות (R2 = 0.994).

4. הבדלים בין צוותים מסורתיים וצוותי agile

באמצעות המודל המתואר בסעיף 3.5, הנתונים של Hoegl ו- Gemuenden (2001) הציגו מודל אישור לא מקובל (χ2 [71] = 224.90, RMSEA = 0.123 [0.105-0.141]. גורם העומס של TWQ בשני הסקרים דומים מאוד; ההבדל הגדול ביותר הוא כי הנתונים של סקר agile יש עומס נמוך יותר (0.47) מנתוני הסקר המסורתיים (0.62).

תוצאות שני הסקרים מראות גם הבדלים קלים במקדמים המבניים הסטנדרטיים לנתיב מTWQ לארבעת המשתנים התלויים. איור 3 מראה שהמקדמים בסקר agile גבוהים יותר להצלחת חברי הצוות (R2 = 0.994), ביצועים מדורגים על ידי חברי צוות (R2 = 0.466),ואת הביצועים המדורגים על ידי מנהיגי צוות (R2 = 0.104) מאשר בסקר המסורתי אך נמוך יותר עבור הביצועים המדורגים לפי מוצר (R2 = 0.004). האיור מראה גם כי טעות תקן היא גדולה יותר ככל שמשקל רגרסיה הוא קטן יוצר, בשני הסקרים.

5. דיון

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

5.1. הבדלים בהערכת ביצועי הצוות בקרב המדרגים

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

כרוכה ביתר תיעוד ודיווח, אשר עשוי לעשות את זה קל יותר לקבל תצוגה משותפת של ביצועי צוות. ייתכנו מספר סיבות להבדלים בין הקבוצות. לגבי איכות המוצר, בעלי המוצר, וכן כמה מנהיגים צוות, עשוים לשקול את המוצר יותר מנקודת המבט של הלקוח (פונקציונליות, שימושיות וכו ‘) מאשר חברי צוות, אשר עשויים להדגיש את תכונות הקוד של המוצר (תחזוקה, יכולת בדיקה וכו’), אשר אינם נראים ללקוח. איור 4 מראה כי להסקר ה agile והמסורתי יש הסכמה הגבוהה ביותר בין חברי צוות ומנהיגים (r = 0.42 ו- r = 0.54, בהתאמה). הקונצנזוס בין בעלי המוצר לבין שני המדרגים האחרים הוא נמוך בסקר agile (r = 0.17 עבור חבר צוות ו- r = 0.12 לצוות מנהיג). הקונצנזוס גבוה יותר בסקר המסורתי (r = 0.37 ו- r = 0.40, בהתאמה).

 לגבי איכות הפרויקט, לבעלי המוצר ולראשי הצוות יש סקירה טובה יותר מאשר חברי צוות בהובלת  זמן ועלות מלבד הפיתוח (עלויות ניהול כולל, עלויות תשתית, וכו ‘). במיוחד בצוות agile, חברי הצוות נוטים להתמקד יותר על עלויות רק בתוך איטרציה הנוכחי או שחרור המערכת, דבר שעשוי להסביר כי המתאם בין בעלי המוצר וחברי הצוות הם הרבה פחות בסקר agile(r = 0.03, כלומר, לא קיים) מאשר בסקר המסורתי (r = 0.37).העובדה שחברי הצוות דירגו הן את TWQ והן את הצוות(Gadadstein, 1984): “נראה כי ליחידים יש מודלים מרומזים לגבי האופן שתהליכים קבוצתיים ירוויחו ביצועים וייחסו תוצאות טובות אל הקבוצה בה הונהג התהליך המתאים “.נוכחותם של מודלים סמויים עשויה לגרור הטיה שעשויה להסביר את ההבדלים בדירוג של חברי הצוות לעומת אחרים. בפרט, אם חברי צוות שוקלים להיות TWQ גבוה, הם עשויים גם לשקול ביצועים גבוהים (וההיפך). באופן כללי יותרMacKenzie and Podsakoff (2012)הראה במטא-אנליזה כי התאמה בין משתנים תלויים ולא תלויים מנופחים מ – 133 ל 304 – אחוזים כאשר אותו מעריך העריך את שניהם.

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

Hoegl and Gemuenden (2001) מסבירים מודל מרומז נוסף. בגלל שלמנהלים (בעלי המוצר בסקר שלנו) חסר מידע מפורט על מדדי ביצוע רלוונטיים, הם “מעריכים את התוצאות המבוססות על סמך הרושם הכללי שלהם לגבי המומחיות של ראש הצוות או חברי צוות אחרים,ולא רק בהתחשב בביצועים בפועל “(Hoegl and Gemuenden, 2001). במילים אחרות, המנהלים מעריכים את ביצועי הצוות כגבוהים אם הם רואים את המומחיות בקבוצה כגבוהה. כמו כן,  (Cohen & Bailey, 1997). ציינו “חברי הצוות נוטים לדרג את ביצועי הקבוצה כגבוהים אם הצוות עוסק בתהליכים פנימיים בריאים, כגון שיתוף פעולה ופתרון סכסוכים. מנהלים,אשר עשוים להיות אינטימים פחות עם הדינמיקה הפנימית של הקבוצה, מדרגים צוות גבוה על פי גורמים חיצוניים, כמו כמו מידת התקשורת של הקבוצה עם סוכנים חיצוניים ”   (Cohen & Bailey, 1997). בצוותי agile, בעלי המוצר נראים כסוכן חיצוני ובכך מעריכים את ביצועי הצוות על פי כמה הצוות מתקשר עם בעל המוצר וסוכנים חיצוניים אחרים.

5.2 השלכות על התרגול

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

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

תמיכה הדדית היא המשתנה הנחקר של TWQ עם ההשפעה הגדולה ביותר על ביצועי הקבוצה (לוח 6); כלומר, פתרון מהיר של קונפליקטים, דיונים בונים, כיבוד הצעות ותרומות של חברי צוות אחרים, היכולת כדי להגיע להסכמה, ושיתוף פעולה טוב נחשבים חשובים במיוחד בצוותי agile. הסבר אחד לחשיבות של תמיכה הדדית היא כי אין מנהיג שיכול להתמודד עם התנגשויות ולנהל בעיות אחרות שעלולות להתרחש בצוותי agile מאורגנים. צוותים כאלה עשויים להיות פגיעים יותר לחוסר תמיכה הדדית מאשר צוותים עם סגנון ניהול מסורתי.

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

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

5.3 השלכות על התיאוריה

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

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

5.4 מגבלות

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

אפשר לשאול באיזה היקף הצוותי היו “”agile בסקר שלנו ו”מסורתי” בסקר המסורתי. בסעיף 3.1, הצדיקו את הזיהוי של צוותים agile עבור הסקר שלנו. מאחר ומשתתפי הסקר על ידי Hoegl and Gemuenden  (2001) לא נשאלו במפורש על שיטות הפיתוח, אנו צריכים להצדיק את הזיהוי של הצוותים בסקר כבעלי גישה מסורתית. יש שתי אינדיקציות חזקות. ראשית, מודל מפל המים או תוכנית  מודל מונחה דומה עם גישה רציפה היה מודל הפיתוח הנפוץ ביותר לפני 2001. המניפסט v-agile לא נוסח לפני 2001, והספר הראשון על Scrum פורסם בשנת 2001 (Schwaber and Beedle, 2001). שנית, ההקשר של הסקר המסורתי היה ארגונים גדולים. הצוותים גויסו מארבע מעבדות תוכנה גרמניות, בעלי גודל משתנה 100-500 מפתחי תוכנה. כל ארבע המעבדות היו חלק מארגונים גדולים יותר, שניים מהם היו פעילים עצמאית של אותה חברת אם בארה”ב. במקרה הפחות סביר יחסית כי צוותים אלה יש גישה agile, זה עדיין מעניין כי התוצאות של הסקר הנורבגי שלנו השיגו תוצאות דומות מאוד לסקר גרמני שנערך 15 שנים מוקדם יותר.

שיעור התגובה ברמת החברה היה 26%. ברמת הצוות, שיעור התגובה היה כ -30%; כלומר, מתוךטווח של 200 ל 220 צוותי agile בחברות אלה (עבור כמה מהחברות, לא ידענו את מספרן המדויק של הקבוצות), הצלחנו לגייס 71 צוותים. באיזו מידה צוותים אלה מייצגים צוותי תוכנה agile בתוך או מחוץ לנורווגיה היא שאלה פתוחה. זה יכול להיות כי חברות שמתכוונות להשתתף בכנסים agile נורווגית יש יותר עמדות חיוביות כלפי פיתוח agile יותר מאשר חברות אחרות. כתוצאה מכך, צוותי agile של הסקר עשויים להעריך את TWQ, את ביצועי חברי הצוות ואת ביצועי הצוותים יותר מאשר צוותי agile בחברות המראות פחות עניין ב התפתחות agile.

אנחנו לא מודעים לכל סקר בהנדסת תוכנה שטוען כי המדגם שלו מייצג ענף מסוים. ובכל זאת, ככל שמספר החברות המיוצגות במדגם גדול יותר, סבירות קטנה כי תרבות מסוימת של החברה יהיה הטיה בתוצאות. המחקר המסורתי גיבש תגובות מ -145 צוותים בשלוש חברות. אספנו נתונים מ -26 חברות, כלומר,ממוצע של 2.7 צוותים לחברה. כללנו את רוב הקבוצות (11) מהחברה הגדולה יותר, שהיא הנהלת סוכנות ציבורית. ייתכן שיש עדיין הטיה בתוצאות שלנו כלפי חברות מסוימות אבל במידה פחותה בהרבה ממה שקורה בסקר המסורתי.

5.5 עבודה עתידית

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

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

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

6. מסקנות

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

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

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