C.3.1
Agil arbetsmetod
Ett agilt arbetssätt omfattar olika strategier för produktutveckling där krav och lösningar utvecklas genom samarbete av självorganiserade och tvärfunktionella team, deras berörda parter och eventuella externa kunder [47]. Arbetssättet förespråkar adaptiv planering, tidig leverans och ständig förbättring. Metoden uppmuntrar även snabba och flexibla reaktioner till förändringar vilket möjliggör förändring av krav långt in i utvecklingsprocessen.
C.3.2
Scrum
Scrum är ett ramverk som implementerar ett agilt arbetssätt [48]. Målet med ramverket är att kunna lösa komplexa problem vid produktutveckling samtidigt som den kreativt levererade produkten har det högsta möjliga värde för kunden. Det är lätt att komma igång och implementera Scrum, då det är ganska lättviktigt i sig själv. Scrum definierar upp en ram inom vilket olika processer och tekniker kan användas, vilket medför att kan vara väldigt svårt att bemästra. Översiktligt så består ramverket av mindre Scrum team som har interna roller, händelser och regler.
Scrum uppfanns för att hantera empiriska processer, det vill säga att grunda handlingar baserat på iakttagelser [49]. Det genomförs genom en iterativ inkrementell strategi. Varje empirisk process har tre gemensamma faktorer: öppenhet, inspektion och anpassning.
Öppenhet syftar på att viktiga delar av processen ska vara transparanta för de ansvariga [49]. Dessa aspekter ska vara definierade på ett standardiserat sätt så att alla parter är överens om vad det betyder. Exempelvis ska milstolpar i ett projekt vara definierade så att personer som utvecklar dem har samma uppfattning som produktledningen om när milstolpar är avklarade. Detta ger alla involverade personer god möjlighet att hänga med på vad som händer i projektet.
Inspektion genomförs för att minska risken för oupptäckta oönskade beteenden [49]. Exempelvis så kan Scrum-teamet demonstrera produktens tillstånd efter varje Sprint, detta medför att värdefull feedback kan samlas tidigt in i utvecklingsprocessen. Skulle kunden ha åsikter om kraven skulle det inte vara några problem då utvecklingsarbetet fortfarande pågår. Anpassning sker om en inspektion fastställer att någon aspekt av processen avviker från accepterade gränser, eller att produkten inte håller måttet, då kan processen och kraven justeras [49]. Anpassning görs för att minimera den tid som läggs på att arbeta i fel riktning. Detta kan medföra snabbare tid till leverans, förbättrad kvalité och förbättrad kund- och arbetstillfredsställelse.
Som tidigare nämnts så existerar det mindre team i projekt som följer Scrum-ramverket [49]. Teamen består av produktägare, utvecklingsteam och Scrum-mästare. Produktägaren är ansvarig för att maximera värdet på produkten som skapas av utvecklingsteamet. Utvecklingsteamet består av flertal personer som jobbar med att leverera en utvidgad version av produkten i slutet på varje sprint. Endast personer i utvecklingsteamet kan skapa inkrement. Scrum-mästaren har ansvar för att Scrum-ramverket följs av resterande personer. Detta kan innebära att coacha resterande personer samt leda Scrum-möte. Dessa team är helt
C.3. Teori
självorganiserade och tvärfunktionella. Detta medför att teamen kan anpassa sitt arbete efter deras egna behov och preferenser, samt att de inte behöver bero på något annat team.
C.3.2.1 Sprints
Det mest välkända med Scrum är Sprints [49]. En Sprint sträcker sig vanligast maximalt en månad, men den vanligaste implementationen brukar vara kortare än så. I tidsspannet så ska kompletta inkrement på produkten skapas, så att de nya utvecklade delarna kan visas upp i slutet av Sprinten. Sprinten består i sin helhet av Sprint-planering, daglig Scrum, utvecklingsarbete, Sprint recension och Sprint retrospektiv.
C.3.2.2 Sprint-planering
Vad som ska göras i en Sprint är det som bestäms i Sprint-planeringen [49]. I denna process så deltar hela Scrum teamet. Det är Scrum-mästaren som organiserar och ser till att detta genomförs. Det som ska kommas fram till under planeringsmötet är vad som ska levereras i slutet av Sprinten, samt hur det arbetet ska genomföras för att nå till de uppsatta målen. Vad som ska göras under Sprinten baseras på vilka funktioner som återstår att utveckla från den så kallade Sprint backloggen, där alla funktioner är definierade. Det är endast utvecklingsteamet som bestämmer vad som är rimligt inom tidsramen för Sprinten. Hur arbetet ska genomföras bestäms också av utvecklingsteamet, detta genom att bryta ner målen i mindre tekniska utvecklingsdelar.
C.3.2.3 Daglig Scrum
Daglig Scrum består av ett kort möte på ca 15 minuter som tar plats varje dag, förslagsvis på samma tid och plats [49]. Målet med mötet är att uppdatera resterande teammedlemmar om hur alla ligger till. Frågorna som ska besvaras på detta möte av samtliga medlemmar är Vad har jag gjort från föregående Scrum-möte?, Vad ska jag göra tills nästa Scrum-möte? och Ser jag några potentiella problem i det som ska göras?. Detta möjliggör för bättre sammanhållning inom teamet och ger uppmärksamheten om vad som händer i utvecklingsarbetet, vilket möjliggör för samarbete och förhindrar överlappning i arbetet.
C.3.2.4 Sprint-recension
En Sprint-recension äger rum i slutet av varje Sprint, vilket även detta är Scrum-mästarens ansvar [49]. Målet med recensionen är att inspektera de inkrement som gjorts på produkt- backloggen under Sprinten. Det diskuteras problem som uppstått, vad som har gjorts och vad som inte hunnits med. Här samarbetar Scrum teamet tillsammans med andra berörda parter för att eventuellt modifiera produkt-backloggen med avseende på det som gjorts och kommit fram tills i Sprinten. Här finns det rum för utvecklingsteamet att demonstrera det som utvecklats under Sprinten. Det finns även möjlighet att diskutera vad som bör göras härnäst för att skapa störst potentiellt värde.
C.3.2.5 Sprint-retrospektiv
Sprint-retrospektiv är en möjlighet för Scrum teamet att reflektera över Sprinten som har varit för att komma fram till förbättringar som kan vidtas till nästa Sprint för att göra arbetet bättre och mer effektivt [49]. Detta sker efter Sprint-recensionen men innan Sprint planeringen. Det som utvärderas är främst hur teammedlemmarna mår, hur processer har gått och hur olika verktyg fungerat. Målet är att dessa faktorer ska bli bättre tills nästa Sprint, vilket medför att personer i teamet håller sig motiverade och positiva.
C.4. Metod
C.3.3
Kanban
Kanban är en metod som utvecklats för att öka effektiviteten av utveckling som är anpassat för att kunna leverera nya utgåvor av produkten kontinuerligt under utvecklingsprocessen [50]. Det finns tre huvudprinciper som utgör Kanban: visualisering, limitering av uppgifter och ett tydligt flöde. Det är mycket som liknas med Scrum, men med viss modifikation. Kanban har exempelvis inga bestämda roller inom teamet som Scrum-mästare och produktägare. Det finns inte några Sprints i Kanban, istället så jobbas det med kontinuerlig leverans där ändringar kan genomföras när som helst, till skillnad från Scrum där det endast ska ske mellan Sprintar. En stor del av Kanban är visualisering av arbetsflödet. Visualiseringen kan exempelvis innehålla vad som ska göras, vad som görs just nu och vad som är avklarat. Ett exempel på hur en Kanban tavla kan se ut kan ses i figur C.1. Här limiteras det ofta hur många uppgifter som kolumnen att göra innehåller.
Figur C.1: Exempel på hur en översiktlig bild av en Kanban tavla kan se ut [51] .
C.4
Metod
Kandidatgruppen applicerade en variant av Scrum under ett Kandidatprojekt. Erfarenheter från projektgruppens egna uppfattningar kommer att jämföras med studier ur publicerade artiklar.
C.4.1
Arbetsmetodik
Kandidatgruppen bestämde sig tidigt att det skulle jobbas med Scrum som arbetsmetodik, med viss modifikation. Arbetet kan ses i två olika iterationer, där första iterationen bestod av mycket dokumentation och utbildning av diverse tekniker som behövdes för att kunna utveckla slutprodukten. I den andra iterationen genomfördes mer utveckling. Båda iterationerna bestod av Sprintar som normalt var en till två veckor långa. Sprintarna matchade obligatoriska inlämningar där det passade. Projektgruppen planerade Scrum möte två gånger i veckan, ett på måndagar och ett på onsdagar i samband med handledarmöte. Den första iterationen tog plats mellan den 20:e januari till den 31:e mars, den andra iterationen tog plats från den 1:a april till den 24:e maj. Vid varje Scrum-möte projektgruppen hade så fördes mötesprotokoll, vilket i samband med författarens egna erfarenheter kommer ligga till grund för resultatet av arbetsmetodiken.