Nyttomaximering av spikes Johan Hedin Sånemyr D11, LTH dat11jh1@student.lu.se Victor Shu-Ming Lam D11, LTH dat11vla@student.lu.se 2016-03-07 Sammanfattning Som projektledare av ett team programmerare så kan sättet att tillämpa hemuppgifter som kallas spikes göra väldigt stor skillnad. I vår studie har vi provat en rad olika spikes, sättet att komma fram till dem samt dess verifiering för att få en bättre förståelse över vad som är optimalt och hur man kan få ut så mycket av processen som möjligt. Under sju veckors tid har vi dokumenterat och följt upp processen för detta och utifrån det har vi tagit fram konkreta tips och förslag. En djupstudie i kursen Coachning av programvaruteam
1 Introduktion I kursen EDA260 delas de deltagande upp i grupper om 10-12 personer där man får som uppgift att med hjälp av Extreme Programmings metodik skapa ett mjukvaruprojekt. Projektet skapas under 6 iterationer där de deltagande lägger ungefär 14 timmar per iteration. Varje iteration består av måndagens programmeringssession som kallas för veckans långlabb på 8 timmar samt onsdagens planeringsmöte där man i 2 timmar reflekterar över långlabben, tidsestimerar kommande uppgifter samt kommer överens om vilka spikes som ska delas ut. Spikes är hemuppgifter som tänks gynna teamet samt projektet som helhet och detta ska ta maximalt 4 timmar att utföra vilket ska vara klart tills nästa långlabb. [2] Alltså är nästan 30% av projektets tid tänkt att läggas på spikes. Detta är en utmärkt möjlighet till att underlätta och förbättra det övriga arbetet och vår hypotes som vi vill undersöka är om vilka spikes som väljs och hur noggrant de följs upp kan spela stor roll för projektets framgångar samt hur man gör hela processen på bästa sätt. Därför har vi försökt få igång en bra kommunikation i teamet gällande om vad som behöver göras och förbättras, vilket särskilt görs på onsdagar men även under långlabbarna. På varje planeringsmöte delas sedan spikes ut beroende på vad diskussionen mellan teamet och coacherna har lett till. I vår studie kommer vi att presentera de upptäckter vi gjort tillsammans med användbara tips för framtida projekt som kan leda till att processen för spikes blir så effektiv som möjligt. 2 Bakgrund 2.1 Projektbeskrivning Kurserna som projektet avser är EDA260 samt EDA270 där den första är för datateknik- samt infocomstudenter som i andra året läser kursen där man får som uppgift att i grupper om 10-12 personer skapa ett program för motorcykelstävlingar som beställs av en kund som kan komma med lite varierande krav. Kraven är uppbyggda av stories som beskriver en funktionalitet. Till sin hjälp har teamet två coacher som också är studenter som har läst EDA260 men nu istället läser EDA270 som går ut på att förbereda sig för att på ett så bra sätt som möjligt kunna coacha teamet i rätt riktning, detta görs genom att till exempel reflektera kring eventuella problem och utmaningar som kommer att uppstå under projektets gång. [7][1] På kontinuerliga coachseminarium diskuteras vilka möjligheter coacherna har att driva ett projekt framåt utan att överträda sin roll som coach. Vi kom fram 1
till att man kunde ställa frågor som förde diskussionerna åt en viss riktning eller ge ordet till någon som vi tror kommer säga det vi vill, men det var högst osäkert i vilken utsträckning det skulle fungera. Vi ville ta detta ett steg längre och det är där spikes kommer in. Med spikes kan vi säkerställa att någon i teamet har den kunskap som behövs för att ta projektet framåt utan att vi behöver ingripa samtidigt som vi kan se till att de blir bättre förberedda på utmaningen utan att vi styr och ställer för mycket. En fråga kan dirigera arbetet i en viss riktning medan en spike medför att teamet verkligen tar ett stort steg i den riktningen. 2.2 Frågeställningar Inledningsvis bestämde vi oss för att dela ut spikes om arkitektur som kan vara relevant för projektet. Det skulle upprepas varje vecka och anpassas efter behov. Vi märkte att spikes riktade mot arkitektur och design var ganska begränsat och valde därför att utöka studien till att även omfatta hantering av spikes i sin helhet. Den utökade omfattningen innebär att vi kan dokumentera och följa betydligt fler spikes samtidigt som utrymme ges för att använda olika metoder till att ta fram och formulera spikes, maximera dess nytta i syfte att uppnå önskvärd effekt. Framförallt ska studien kunna besvara följande frågor: Vad är en bra spike och vilka typer av spikes ger bäst effekt? Hur stor effekt har spikes på projektet? Hur säkerställer vi att spikeuppgifterna utförs korrekt? Hur ser man till att hela processen gällande spikes blir så effektivt som möjligt? Hur kan spikes bidra till så bra kunskapsspridning som möjligt? Vilka tips kan vi ge kring spikes? 2.3 Om Spikes Under projektets gång har vi tagit fram och följt upp totalt 72 spikes. Spikes är uppgifter som utförs utanför ett projekts planerade arbetstid. En spike är således inte en del av det normala arbetet utan handlar mer om att man ska ta reda på mer om något som kan vara användbart för projektet.[4] [3] Alla spikes karakteriseras huvudsakligen av två delar: hur de har framkommit och vad de innehåller. För att ge en tydlig överblick över resultaten och för att skapa en bättre koppling mellan olika spikes har vi kategoriserat alla enligt systemet nedan. Det finns också spikes som kan tillhöra flera kategorier. Vi har kommit fram till indelningen genom att granska de spikes som delades ut första veckorna i syfte att hitta en terminologi för diskussioner om spikes. 2
2.3.1 Framtagningssätt Spikeuppgifternas framtagningssätt har varierat lite vilket beskrivs under rubrikerna nedan, men gemensamt så beror de på diskussioner, erfarenheter och observationer som sker under långlabbar och planeringsmöten. Under dessa tillfällen då vi noterat något som kan leda till en spikeuppgift har detta antecknats. Oftast så har utdelade spikes ursprungligen kommit från alla kategorier nedan. Coacher Detta är spikes som coacherna har valt utifrån deras uppfattning om vad som behövs eller för att försöka driva projektet i en viss riktning. Det är vanligt att designmönster som factory method eller verktyg som byggskript framkommer på detta sätt eftersom coacherna har erfarenhet av vad som kan gynna teamet. Team Dessa spikes är framtagna av teamet själva utan någon påverkan av coacherna. Då teamet som helhet oftast har en bättre insikt i projektet och dess kod har de många gånger en bättre uppfattning om vilka spikes som är nödvändiga för projektets framgång. Det blir ofta väldigt konkreta spikes som löser olika problem som teamet stött på. Team och coacher Detta är det genomgående mest använda sättet för att ta fram spikes på där en aktiv diskussion mellan teamet och coacherna sker. Här diskuterar hela teamet fram de olika spikeuppgifterna med fokus på vad som är viktigast och säkerställer att uppgifterna är rättvist fördelade. Det börjar ofta med att teamet har en idé om vad de vill utföra som de förklarar för coacherna som i sin tur kan bidra med tips och eventuellt förklara varför det inte går. Kund Kunden är en central del av projektet då det är personen som bestämmer vad som efterfrågas i produkten. Egentligen beror i grund och botten alla spikeuppgifter på kundens önskemål i form av stories men här avser vi uppgifter som kunden i vissa fall efterfrågar som spikes. 2.3.2 Spikekategorier Vi har delat in alla spikes i följande 5 kategorier för att under och efter projektet enklare kunna utvärdera och dra slutsatser om hur de olika kategorierna har skilt sig åt. Det finns egentligen betydligt fler sätt att dela in spikes men vi fick begränsa oss till att välja de 5 tydligaste kategorierna för att få mindre spridning och tydligare resultat i våra enkäter. Storybaserade Spikes som har en direkt anknytning till en story vars syfte är att under långlabben få ett mer effektivt arbete med den specifika storyn. I en del fall handlar det om stories som kommer att kräva en del spiketid som exempelvis att sammanställa och skicka återkoppling efter att ha granskat ett annat teams tekniska dokumentation. 3
Arkitekturbaserade Spikes som direkt bidrar till förbättrad arkitektur, exempelvis genom att lära sig mer om olika designmönster eller att planera en refaktorisering. Specifikt har det handlat om två olika sätt att utföra detta, antingen genom att först studera mönster och principer för att sedan hitta delar i koden där det kan appliceras på eller så har man identifierat illaluktande kod och försökt hitta ett sätt att förbättra det efteråt.[5] Problembaserade När teamet eller coacherna upplever att det finns ett problem kan det ofta vara bra om någon lägger lite extra tid och fokus på det, då är spikes ett utmärkt verktyg för att lättare lösa problemet utan att tid från långlabben läggs på detta. Spikes erbjuder flexibilitet genom att individuell tid kan läggas på att identifiera orsaker till problem medan man istället löser dem i par. Experimentella Spikes som är experimentella handlar om att utforska nya områden och olika lösningar som kan vara bra för både teamet och projektet, detta innefattar uppgifter som ämnar att samla kunskap om olika valmöjligheter för att kunna ta så bra beslut som möjligt. Det leder kanske inte alltid till något användbart för projektet direkt men på sikt är det kunskap som kan bidra till både projektet och individen. Välsmakande Dessa spikes brukar tilldelas 2 personer per iteration där uppgiften är att baka någon fika till teamet eller ta med något annat som efterfrågas, till exempel kaffe och mjölk. Att utvecklarna får vila lite under dagen och ha en fikapaus där man kan diskutera lite andra saker kan i många fall förbättra programmerandet eftersom energin och motivationen ökar. 2.4 Målsättning Målsättningen med studien är att hitta en process att jobba med spikes som är optimalt för teamet. I vår metodik provar vi flera saker som vi tror kan leda till bättre effektivtet och resultat. Det finns många faktorer som tillsammans utgör en bra spike, förhoppningen är att vi ska kunna presentera några av dessa i slutsatsen. Teoretiskt sätt är det rimligt att noggrant utvalda spikes med en genomgående uppföljning med tydliga förväntningar som alla är införstådda i kommer att bidra mest. Kriterierna för en bra spike är att personen som utför den ska lära sig något, att projektet utvecklas av det arbetet och att kunskapen sprids vidare på bästa sätt. 3 Metodik Metodikens huvudsakliga syfte är att utforska området, det kommer inte finnas konkreta bevis för att ett sätt är bättre än något annat utan snarare indikationer 4
och faktorer som kan påvisa att ett visst sätt är bra. Vår process för att undersöka spikes i allmänhet har varierat beroende på projektets fas och tillstånd. För att kunna få ett bra stöd för vår undersökning har vi inte enbart jobbat utifrån sättet att lägga upp projektets spikedel på det sätt som vi själva trott ska leda till bäst resultat utan har experimenterat lite med anledningen att vår grupp empiriskt ska kunna erfara skillnaderna i de olika tillvägagångssätten. 3.1 Planeringsmöten Spikes delas alltid ut på onsdagarnas planeringsmöten men metoden för att komma fram till dem samt att dela ut dem har skiljt sig. På första mötet innan gruppen hade börjat programmera var det helt upp till oss coacher att välja ut lämpliga spikes då gruppen på grund av dess tidiga stadie inte hade så stor insikt i vad som behövde göras och hade därför inte så mycket att tillföra gällande valet av spikes. Vårt mål gällande spikearbetet inför den första iterationen var att få gruppen förberedd för att kunna komma i arbete på ett smidigt sätt där alla ska vara så insatta som möjligt. Vi förberedde inte någon iteration 0 som innebär ett skelett till projektet så vi delade ut spikeuppgifter om att skapa ett skelett, repetera designmönster, läsa på om GIT, lära sig om ANT-script för att automatisera en release till kunden samt förbereda inläsning och utskrift till filer. 3.2 Långlabbar Varje måndag morgon innan gruppen börjar programmera så samlas vi i ett stand-up möte där allas spikeuppgifter gås igenom. Detta görs genom att vi coacher ger ordet till var och en som får presentera hur uppgifterna har gjorts och vad de har kommit fram till, därefter är det upp till de övriga att ställa frågor samt diskutera om det behövs. Här är det viktigt att vi som coacher försöker förtydliga saker som kanske kan verka oklara och se till att nödvändiga diskussioner sker samt att alla är med i samtalet och förstår dess innehåll. Ett problem som annars brukar kunna förekomma är att en person redovisar sin spikeuppgift väldigt kort, svårförståeligt eller otydligt vilket leder till att spikeuppgiftens nytta inte tas del av alla. Detta kan lösas ganska enkelt genom att som coach ställa följdfrågor som förtydligar uppgiftens resultat på ett diplomatiskt sätt, samtidigt som man får en större garanti på att uppgiften har genomförts på ett korrekt sätt. Följdfrågor behövs bara om uppgiftens redovisning inte är tillräckligt grundlig men frågor till gruppen i syfte till att säkerställa kunskapsspridning tror vi enbart är positivt. Följdfrågor kan behöva förberedas om uppgiften avser något område som vi coacher inte har tillräcklig kunskap i, annars har vi nöjt oss med grundliga frågor som garanterar att uppgiften är utförd. Denna princip leder även till en högre standard på redovisningarna då gruppmedlemmarna under projektets gång märker att spikeuppgifterna kräver en viss sammanställning då den kommer presenteras och diskuteras tillräckligt 5
mycket enligt coachernas bedömningar. Vi har provat olika sätt att maximera kunskapsspridningen genom förberedda frågor, frågor baserad på vår egen erfarenhet och även krav på skriftlig sammanfattning av det man har kommit fram till. 3.3 Experiment Tiden det tar att komma fram till de olika spikeuppgifterna varierar och det kan gå väldigt snabbt när det finns mycket förberedande arbete som behövs göras medan det ibland kan ta tid att komma fram till 10-12 rättvist fördelade uppgifter som både tidsmässigt uppgår till 4 timmar samt motiveras utifrån projektets behov. Det viktiga enligt oss är dock inte att arbetet säkerligen uppgår till 4 timmar utan att tiden som läggs verkligen gör nytta för teamet och projektet som helhet. En och samma spikeuppgift kan ibland ta en timme för en person medans den tar över 4 timmar för en annan då alla har olika kunskapsnivåer inom olika områden samt lär sig och utför arbeten olika snabbt. Nyttan spikeuppgiften ger kan också variera beroende på vem man ger uppgiften till, om exempelvis en väldigt duktig och programmeringsvan person får en refaktoriseringsspike kan refaktoriseringen göras bättre och utförligare och på så sätt ge teamet mer nytta än om en person med betydligt sämre kunskaper gör det. Då kursens syfte är att deltagarna ska lära sig så mycket som möjligt istället för att slutprodukten ska bli så bra som möjligt är det därför vår uppgift som coacher att jobba mot en så stor kunskapsspridning som möjligt. Därför kan nyttan av spikes tolkas olika utifrån olika synvinklar, där teamets nytta kan avse projektets framgång men också gruppmedlemmarnas lärande utifrån kursens perspektiv. För att nå detta genom spikes har vi kommit fram till att det kan göras på lite olika sätt. Antingen genom att låta en erfaren person utföra uppgiften tillsammans med en mindre erfaren där den mindre erfarna på så sätt lär sig eller genom att två erfarna får jobba ihop för att projektet ska gå framåt, alternativt kan man låta två helt nya personer sätta sig in i det så att de får utforska och lära sig mer. Alla alternativ innehåller såklart en redovisning för att sprida kunskapen. Vi har under projektets gång medvetet haft iterationer med väl valda spikes och iterationer med få förberedda spikes. Sammanfattningsvis har vi gjort saker som vi tror är bra och även mindre bra för att bekräfta eller avvisa olika teorier. Redan inför iteration 2 gav vi ut refaktoriseringsspikes då detta inte hade gjorts alls noggrant under långlabben. I slutet av iteration 1 så skedde en stor mergekonflikt som inte kunde lösas, därför delas en spike ut för att lära sig hantera mergekonflikter. Vi märkte att det efter iteration 2 fanns flera ställen i koden som designmönstret template method kunde användas, därför delades en spike ut där koden skulle undersökas för designmönster tillsammans med en spike om att automatisera UML-diagram. Inför iteration 4 handlade en spike om att hitta nåt verktyg för 6
att kolla testteckningen då vi märkte att väldigt få följde testdriven utveckling. Utöver detta har några refaktoriseringsspikes delats ut i de sista iterationerna. 3.4 Enkäter Vi har skickat ut enkäter i slutet av projektet för att ta reda på mer om vad alla tycker om spikes efter att ha arbetat med det i ett helt projekt. Vi har skickat ut olika enkäter till vårt eget team, coacherna och de övriga teamen för att få en överblick av hur det ser ut generellt och för att få in åsikter från personer som inte har påverkats av vår studie. Vårt eget team har inledningsvis inte blivit informerade av vår djupstudie eftersom vi har varit mer intresserade av att se hur olika val och beslut påverkar och inte vill att våra kontinuerliga observationer ska påverka resultatet. 3.5 Diskussioner Vi har arbetat för att gruppen kontinuerligt har försökt vara så självkritisk som möjligt och särskilt försökt sett till att alla i gruppen har känt att alla har varit delaktiga och fått säga sina åsikter och tankar gällande de beslut som tagits. Vi har även försökt roterat runt teamets roller då medlemmarna i början tenderade att få tydliga roller. Det löstes ganska enkelt genom att förklara kursens syfte om att alla ska få prova på de olika rollerna och förklarat vad som förväntas göras.[6] Vi har fört aktiva diskussioner med vårt eget team för att ta reda på hur olika spikes har utförts och vilken effekt de anser att de har fått. Vi har också lyssnat noga på vad de anser ha behövts i projektets olika faser. I slutet av projektet använde vi en del av utvärderingen till att diskutera spikes för att få en djupare förståelse än vad enkäterna har kunnat ge. 3.6 Observationer Under projektets gång har vi också gjort en hel del observationer, bland annat hur bra det flyter på, om vi kan minska väntetider under långlabbarna och hur de kommunicerar med varandra för att ta del av den kunskap man har införskaffat via spikes. 4 Resultat Den största delen som slutresultaten bygger på baseras från enkäterna som både studenter från EDA260 och EDA270 har fått svara på men även från kontinuerliga samtal med gruppen och individuella personer samt slutsatser utifrån egna erfarenheter som vi coacher har fått erfara. Vi har skickat ut 3 olika enkäter där en är mer innehållsrik och riktad till vårt team, två mindre utförliga enkäter där den ena har skickats till coacherna och den andra till deras team. De svar som har kommit till användning när vi reflekterat och kommit fram till slutsatser 7
finns i bilaga 1. Vi är överlag mycket nöjda med resultaten eftersom vi har fått tydliga indikationer på hur spikearbetet kan uppnå högre effektivtet som har kunnat bidra till konkreta slutsatser. 4.1 Spikes utfall De tidiga refaktoriseringarna ledde till bättre helhetsförståelse samt enklare påbyggnad av koden, detsamma gäller spikes som handlar om arkitekturen. Spiken om att automatisera UML-diagram resulterade i att de började använda object aid. Spiken om att kolla testtäckning ledde till att testtäckningsverktyget Clover infördes vilket motiverade många till att börja skriva fler test. 5 Diskussion 5.1 Reflektioner Allmänt om spikes så ser vi flera klara trender i resultaten som stödjer mycket som lärts ut i kursen och som är överens med vår uppfattning. Majoriteten tycker att spikes har haft en stor påverkan på projektet där kunskaperna som lärts från uppgifterna tycks komma till god användning under långlabbarna. Gällande kunskaperna som teamet har fått genom spikes så har åsikterna varierat lite om det är lärdomar som tros kunna komma till nytta även efter projektet. Alla svar tyder på att de har fått kunskap som kommer vara användbart i framtiden men hur mycket det handlar om varierar, vilket är förståeligt då de spikes som innefattar områden som kan vara användbara utanför projektet inte har kunnat delats ut till alla, samt att alla har olika förkunskaper och därför har vissa tagit med sig mer än andra. Gällande tillvägagångssättet för att ta fram spikeuppgifterna så är det en klar majoritet som tycker att det blir bäst genom att det sker genom en aktiv diskussion mellan coacher och utvecklare snarare än att det bestäms mestadels av coacher eller utvecklare. Detta håller vi med om då utvecklarna ofta har en bättre uppfattning om vilka problem som är aktuella och vad som är nödvändigt samtidigt som coacherna kan se till att tillräckligt utförliga diskussioner sker. Vi har försökt få en noggrann genomgång och diskussion av resultaten av spikeuppgifterna vilket majoriteten har tyckt varit lagom medans några haft åsikten att det kunnat diskuteras ännu mer. Detta tyder på att mycket genomgång, redovisning och diskussion av resultaten är att föredra då ingen har tyckt att det gåtts igenom för lite. Endast en person av de som svarat har tyckt att uppgifterna ska verifieras genom en lätt kontroll. Åsikterna pekar mest åt en lagom hård kontroll men också ganska jämt utspritt åt båda hållen även om det lutar lite åt hårdare kontroller. Åsikterna om kontroller stämmer också överens i en annan fråga där fler personer tror att projektet gynnas av att coacherna förbereder frågor som är relevanta för varje spike jämfört med att inte göra det. 8
Hur mycket projektet gynnas är lite olika men att det har en positiv påverkan är alla överens om. I slutet av projektet införde vi ett krav på en skriftlig sammanfattning av spikearbetet och detta tycker större delen resulterade i att spikes utfördes grundligare än tidigare. De slutsatser som kan dras gällande vilka kategorier av spikes som haft störst effekt på projektets framgång är att arkitektur/design- och problembaserade spikes påverkat mest. Det resultatet styrks särskilt från svaren av både coacherna och av vårt team men också från övriga teams svar även om skillnaden inte är lika stor. Vi har diskuterat detta med gruppen och vi fick uppfattningen att dessa ansågs ge bäst resultat på grund av lite olika anledningar. En förbättrad arkitektur underlättar både helhetsförståelsen samt mycket kommande arbete och fördelen med att lägga refaktoriseringen som en spikeuppgift motiverades med att teamet redan i början på långlabben kunde sätta sig in i de nya förändringarna och påbörja sitt arbete utifrån den nya arkitekturen istället för att refaktoriseringen påbörjas på morgonen varpå många får tidsödande mergekonflikter när den väl pushas in. Det viktiga med denna metod är att förändringarna gås igenom noggrant så att alla kan komma igång med arbetet så snabbt som möjligt. Problembaserade spikes som ansågs ungefär lika effektiva motiverades i vårt team särskilt av osäkerheten gällande tiden det tar att lösa okända fel. Inom programmeringen kan ett okänt fel ibland avklaras snabbt men i andra fall ta extremt lång tid. Om det okända felet berör något som mycket annat beror på så kan detta leda till att många i gruppen inte kan fortsätta eller påbörja nya stories. Det anses alltså bättre att välja det säkra före det osäkra och lägga okända problem som spikeuppgifter även om dem kanske kan lösas snabbt och inte uppgår till 4 timmar istället för att riskera ovan nämnda problem. Storybaserade spikes var något vi provade en del, där uppgifterna ofta bestod av att förbereda arbetet inför specifika stories, till exempel genom att tänka ut hur det ska lösas och skriva pseudokod för lösningen. De ansågs inte ge så bra effekt, skälen till detta var att teamet tyckte att det var som att göra uppgiften hemma och göra om samma sak igen när man kom till långlabben. Uppfattningen var att det hade varit mycket effektivt om man fick förbereda kod istället för pseudokod vilket inte var tillåtet. För att nå en så bred kunskapsspridning som möjligt genom valet av vilka man delar ut spikes till så tyckte majoriteten i vårt team att detta åstadkoms bäst genom att låta mindre erfarna personer utföra uppgiften tillsammans med de som är mer erfarna för att sedan redovisa resultatet till gruppen. Denna åsikt var övervägande följt av att hellre låta mindre erfarna personer utföra uppgiften samt redovisa jämfört med enbart erfarna. När detta diskuterades så var skälen till resultatet att sammansättningen av oerfarna med erfarna har en större garanti på att kunskap sprids till de oerfarna samt att kvalitén på resultat och redovisning inte förändras. Enbart oerfarna på uppgiften ansågs också ha 9
större garanti på kunskapsspridning än enbart erfarna. Viktigt att ha i åtanke är att valet i högsta grad beror på hur villiga teammedlemmarna är gällande att självmant försöka ta del av resultaten genom att fråga och diskutera under och efter redovisningen av spikes. Om teamet verkligen vill och jobbar aktivt för detta var de flesta överens om att kunskapsspridningen blir bäst genom att låta minst en erfaren person vara med för att garantera kvalitén då kunskapen ändå kommer spridas. I vårt team så håller alla med (även om graden medhåll varierar) om att en spike som lär en något som är användbart utanför projektet föredras framför en som inte gör det, även om den valda spiken kräver mer arbete än den andra. Frågan är något otydlig då det inte nämns något om hur mycket mer arbete som krävs samt hur användbart det man lär sig är. Slutsatsen som kan dras som också stärktes efter diskussionen är att det är mer motiverande att utföra en spike vars kunskap tros kunna komma till användning utanför projektet, då det därmed inte enbart ses som en arbetsuppgift utan personlig vinning. 5.2 Slutsatser 5.2.1 Skapa spikes Ett aktivt samarbete mellan teamet och dess coacher är optimalt eftersom teamet kan ha en bättre uppfattning om aktuella problem och känner sig även mer involverade och engagerade i uppgifterna samtidigt som coacherna kan bidra med erfarenhet för att ge uppgifterna ett mer konkret mål. 5.2.2 Prioritera spikes Spikes där man får lära sig nya saker som kan vara användbart även efter projektet bör prioriteras eftersom motivationen ökar och således även effektiviteten på arbetet. Arkitektur- samt problembaserade spikes är de kategorier som anses mest effektiva. 5.2.3 Kunskapsspridning En skriftlig sammanfattning gör det lättare för teamet att ta del av kunskaperna från spikeuppgifterna. Att som coach ställa följdfrågor i syfte att säkerställa en djupare diskussion av det man har kommit fram till där hela teamet involveras bidrar till en bättre kunskapsspridning. Det är också bra att låta någon med mer erfarenhet och någon med mindre erfarenhet jobba tillsammans i en spike för att säkerställa både kvalité och kunskapsspridning. 5.2.4 Följa upp spikes Lagom hård kontroll gällande spikes bidrar till ett grundligare arbete och därmed bättre effekt. Kontrollmetoder: noggrann genomgång med tillhörande diskus- 10
sion, förberedda relevanta frågor samt en skriftlig sammanfattning. 5.3 Framtida studier Studien begränsades lite av att vi enbart haft ett projekt och ett team att arbeta med. Om möjlighet ges i framtiden skulle det vara intressant att använda våra olika metoder på isolerade team och därmed kunna dra slutsatser utan att experimenten påverkar varandra. 6 Tillkännagivanden Vi vill rikta ett stort tack till Lars Bendix som har bidragit med kunskap och återkoppling till vår studie. Vi vill också tacka vår kund Niklas Fors som aktivt har prioriterat och diskuterat så att vi har kunnat skapa en realistisk arbetsmiljö att utföra studien på. Slutligen vill vi också tacka alla coacher och team som bidragit med reflektioner som hjälpt vår studie. Referenser [1] Kent Beck. Embracing Change with Extreme Programming. IEEE Computer, Okt 1999. [2] B. Magnusson G. Hedin, L. Bendix. Teaching extreme programming to large groups of students, Journal of Systems and Software. Lund University, 2005. [3] Chromatic James Shore. The art of Agile Development. O Reilly, Okt 2007. [4] Dean Leffingwell. Agile Software Requirements. Addison-Wesley, Jan 2011. [5] Robert C. Martin. Agile Software Development - Principles, Patterns, and Practices. Prentice Hall, 2003. [6] L. Svedberg. Gruppsykologi. Om grupper, organisationer och ledarskap. Studentlitteratur, 2003. [7] W. Wake. Extreme Programming Explored. Addison-Wesley, 2000. 11
Bilaga 1