Utöver detta har alla individer i utvecklingsteamet haft roller utöver de angivna i Scrum. Dessa inkluderar till exempel projektledare, testledare och dokumentansvarig. Det gjorde att visst ansvar tillföll de olika rollerna, istället för att alla i gruppen hade lika stort ansvar för allting.
Även en av Scrums grundpelare, transparens, efterlevdes genom de processer som beskrevs tidigare. Detta genom att låta alla i gruppen ha tillgång till all kod och alla aktiva grenar genom att dela en gemensam datakatalog, där alla gruppmedlemmar fritt kunde se över projektet under utveckling. Mötesprotokoll fanns sparade i webbapplikationen RunY- ourMeeting [30] där alla kunde logga in och läsa igenom vad som beslutats på alla möten som uträttats i gruppen. Alla dokument som skrevs fanns också tillgängliga för alla i grup- pen via webbapplikationen ShareLaTeX [31]. E-post med viktig information från handledare, kursansvarig och kund vidarebefordrades också ut till alla medlemmar i projektet.
5.4.1
Modifieringar av Scrum
De större modifieringar som gjordes av Scrum, inkludering av parprogrammering och Kanban-tavla, upplevdes enligt undersökningen i appendix H som något positivt av arbets- gruppen. Parprogrammering upplevdes som något som eliminerade småfel och gjorde det lättare att arbeta då det var lättare att hålla fokus när man inte arbetade ensam. Parprogram- mering gjorde även så att kunskap spreds inom gruppen och det därmed nästan alltid fanns någon på plats som var insatt i en specifikt del av systemet. Kanban-tavlan skapade struk- tur i arbetsgruppen eftersom det var lätt att se vad som det fanns att arbeta med, vem som arbetade med vad, och hur lång tid olika uppgifter hade tagit.
5.5
Översikt över individuella bidrag
Nedan följer en kort sammanfattning av respektive gruppmedlems individuella bidrag. A Adam Combler: En studie av tidsuppskattningsmetodik i ett agilt, småskaligt mjuk-
varuprojekt
I ett agilt mjukvaruprojekt kommer varje iteration att behöva planeras. Hur denna planer- ing står sig mot den verkliga tidsåtgången och hur planeringen kan förbättras studeras i detta avsnitt. Från studien framgår det främst att det är möjligt att få en hög andel avklarade uppgifter av de planerade vid sprintens slut. Detta med hjälp av de i studien använda metodikerna och verktygen, som planeringspoker, ansvar för Kanban-tavla och användandet av en hjälplista.
B Philip Friberg: Kundens inverkan på ett agilt mjukvaruprojekt
I detta avsnitt behandlas hur man går till väga med kundkommunikation i ett agilt mjuk- varuprojekt samt vilken roll kunden har i förhållande till utvecklarna i ett agilt mjuk- varuprojekt. Med hjälp av jämförelser mellan teori och erfarenheter från projektet framgår det att utvecklarna och kunden bör befinna sig på samma plats för fysiska möten, det krävs även en hel del tid från kundens sida för att arbeta med agila utvecklare. Det viktigaste är att båda parterna kan vara flexibla annars kan inte arbetet fungera agilt.
C Jani Jokinen: Fysiska eller nätbaserade möten i vår digitala värld?
Kommunikation är ett kraftfullt redskap som används dagligen. Detta avsnitt kommer att ge en inblick i vilka kommunikationskanaler används av studenter, samt vilka för och nackdelar det finns med de.
D Elin Larsson: Dokumenthantering i ett småskaligt mjukvaruprojekt med agil utveck- lingsmetodik
5.5. Översikt över individuella bidrag
inom en projektgrupp kan hantera och producera dokument agilt samt vilket värde de framtagna dokumenten får. Resultatet visar följande nyckelpunkter för dokumenthanter- ing; fördela arbetat mellan alla gruppmedlemmar, inför en granskningsprocess, genomför regelbundet dokumentmöten samt sätt upp interna deadline. Vidare framkommer det att kravspecifikationen och arkitekturdokumentet får ett högt värde för gruppen och kunden. E Erik Mansén: REST och SOAP, en jämförelse av webbtjänsters uppbyggnad
Detta avsnitt behandlar fenomenen REST och SOAP, de två huvudsakliga metoderna för API-implementation. Det finns mycket att vinna på att förstå skillnaderna mellan dessa, så att man kan göra rätt beslut i valet mellan dem. Studien finner att enklare system i längden vinner över mer avancerade sådana, då avancerade system ofta innebär en större ansträngning för att hantera egenskaper man i slutändan inte har behov av.
F Tobias Martinsson: Undersökning av metod för testning och enhetstesters betydelse vid parprogrammering
I detta avnsnitt behandlas det hur parprogrammering påverkar enhetstester samt för- och nackdelar med att testa sin egen och testa andras kod. I undersökningen visas det att parprogrammering fungerar bra för småskaliga projekt och minskar antalet mindre fel i koden. Det visas även att testa kod skriven av någon annan kan vara väldigt gynnsamt för mindre projekt.
G Albin Pettersson: Effekten av versionshantering på projekt och val av versionshanter- ingsverktyg
Inget projekt kan få perfekt kod på första försöket och därför är versionshantering ett väldigt effektivt hjälpmedel för att underlätta utvecklingen av projekt. Men hur stor ef- fekt har det egentligen på ett projekt och vilket versionshanteringsverktyg ska man an- vända? Detta avsnitt undersöker just dessa punkter och visar vilka för- och nackdelar versionshantering har samt vilka olika egenskaper som är viktigast för ett versionshanter- ingsverktyg.
6
Diskussion
I detta kapitel behandlas lärdomar och vad som hade kunnat göras annorlunda i projek- tet. Diskussion kring hur den framtagna produkten kunde skapa värde för kund, gruppens gemensamma erfarenheter samt hur det är att arbeta med en systemanatomi tas upp. Resone- mang kring hur man kan säkerställa integration av separat utvecklade moduler och hur Scrum har anpassats till detta projekt behandlas. Även hur produkten spelar in på hållbar utveckling och hur detta hade kunnat påverka skapandet av kravspecifikation presenteras.
6.1
Värde för kunden
Något som hade kunnat förändras i projektet, och möjligtvis skapat samma värde för kun- den, är hur koden granskades. Exempelvis hade en metod som over-the-shoulder review (sv: över-axel-granskning ) kunnat användas istället för parprogrammering. Metoden går ut på att en utvecklare visar sin kod för en annan utvecklare och förklarar tanken bakom den efter att en arbetsuppgift är avklarad [32]. Det hade kunnat skapa värde för kunden på ett annat sätt än vad parprogrammering gjorde.
Över-axel-granskning istället för parprogrammering ger möjligheten att arbeta på flera arbetsuppgifter samtidigt. Det medför att kunden kan få mer värde från produkten med avseende på hur mycket som utvecklats. Fördelen med parprogrammering är att kunskap delas inom gruppen, koden granskas direkt samt, i bästa fall, får hög kvalitet samtidigt som den skrivs [22]. Enligt en studie av Cockburn och Williams kan antalet buggar minska med upp till 15 procent då parprogrammering används [23].
Även om detta alternativa sätt hade gjort att fler saker hade utvecklats samtidigt är det inte säkert att det hade bidragit till en bättre produkt och arbetsklimat. Enligt utvärderingen, som hittas i appendix H, upplevde flertalet i projektgruppen att arbeta i par som något pos- itivt. Därför var parprogrammering att föredra för denna arbetsgrupp istället för att jobba själva.