Etiska aspekter

Den sista aspekten är etik. Den fråga man kan ställa sig kring produkten samt Teknikåttan är ifall en tekniktävling för barn är etiskt? Lär sig barn genom att tävla, eller sätter det bara press på deras prestation? Detta är en aspekt som vore relevant att undersöka ytterligare i samband med att tävlingen fortsätter hållas.

7

Slutsatser

Syftet med denna rapport är att samla de erfarenheter och kunskaper som projektgruppen har fått genom att utföra detta projekt. För att uppfylla detta syfte togs fyra frågeställningar fram. Dessa, tillsammans med de slutsatser som har kunnat dras utifrån dem, presenteras nedan.

Hur kan systemet implementeras så att man skapar värde för kunden?

Utifrån resultatet och efterföljande diskussion kan vi se att ett system som är lättanvänt sparar tid. Ett system som är användarvänligt gör så att tid sparas vid förberedelser, ändringar och utförandet av tävlingar. Att spara tid för kunden är av stort värde.

Vidare kan man genom att arbeta aktivt med riskhantering som processområde underlätta utvecklingen av produkten. Det ger både riktning och förvarnar för potentiella problem som kan uppstå under utvecklingen, vilket minimerar konsekvenserna av risker som kan inträffa. På så sätt kommer utvecklingen kunna ske smidigare vilket ger en bättre producerad produkt och således skapas mer värde för kunden. Dessutom är det viktigt att välja ett processområde som relaterar till kundens önskemål på bästa sätt.

Vilka erfarenheter kan dokumenteras från programvaruprojektet som kan

vara intressanta för framtida projekt?

Det man kan ta med sig från de erfarenheter som samlades in under projektets gång var att om man stöter på kunskapsbrister inom ett viktigt område i projektet kan det vara värt att investera tid i att i grupp gå igenom området där det råder kunskapsbrist. En ytterligare sak som kontinuerlig erfarenhetsfångst kan bidra till är uppfångst av svagheter i arbetsme- todiken. Med hjälp av detta kan man anpassa sitt arbetssätt under tidens gång beroende på projektets svagheter.

Den viktigaste erfarenheten som gruppmedlemmarna kommer ta med sig är vikten av kontinuerliga avstämningar angående gruppdymaniken. Detta då gruppen kände att det var det som tillförde mest till utvecklingen av grupparbetet. Det gruppen ska göra annorlunda från det här projektet i framtiden är att vara mer konsekventa i uppfångsten av erfarenheter för att kunna göra bättre jämförelser för att se utveckling.

Sammanfattningsvis är erfarenheter som är viktiga att dokumentera arbetsmetodik och gruppsammanhållning då det är de som driver utvecklingen framåt samt påverkar grupp- medlemmarnas individuella välmående.

Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

Det mest användbara hos systemanatomin är att man snabbt kan skapa ett överblick för ett system innan utvecklingsfasen påbörjas. Det är intressant att gå igenom diagrammet någon gång under projektets gång för att se hur det nuvarande skicket av systemet skiljer sig från den den bilden som utvecklingsteamet hade i början.

Hur kan man samarbeta med en kund för att prioritera krav?

Den viktigaste faktorn för att kunna samarbeta med en kund kan sägas vara kommunikation. Detta är extra viktigt då beslut ska fattas. Speciellt i början av ett samarbete är det viktigt att de olika parternas möjligheter och begränsningar är kända, så att ingen har en felaktig bild av de andra. Om dessa delar är kända kan parterna komma fram till en mängd krav som är rimliga att nå. Denna mängd bör planeras väldigt tidspessimistiskt, och bör vara krav som kan utföras under satt tid utan problem. Dessa krav bör även endast vara krav som ger den funktionalitet som kunden prioriterar allra högst. Resterande krav kan då ges lägre prioritet, och arbetas på om tid finns.

A

Scrum-utvecklingsmetodik för

utveckling hos små team

av Dawid Abucewicz

A.1

Inledning

Det kan tyckas att det borde finnas ett bra recept för en mjukvaruutvecklingsprocess. Det kan även tyckas att mjukvaruutvecklingsprocessen är en väldefinierad process som man borde följa. Det finns flera olika utvecklingsmetoder så som vattenfallmodellen, spiralmodellen och iterativmodellen som antar detta [27]. Man kan också betrakta mjukvaruutvecklingsproces- sen som en svart låda där inte allt är glasklart. Utvecklingsprocessen kan vara odefinierad och oförutsägbar. Dessa är antaganden i Scrum-utvecklingsmetodik. Första handbok om vad Scrum är och hur den borde användas skrevs av Jeff Sutherland [28]. Eftersom denna ut- vecklingsmetodik är, jämfört med vattenfallmodellen eller spiralmodellen, relativt ny är det intressant att undersöka hur den fungerar för utveckling hos små team.

A.1.1

Syfte

Syftet med denna studie är att undersöka hur väl Scrum-utvecklingsmetodiken fungerar un- der utveckling hos små team, som till exempel kandidatgrupper vanligtvis bestående av 8 personer. Vidare är denna rapport tänkt att underlätta för framtida kandidatstudenter och andra som intresserar sig av Scrum-utvecklingsmetodiken identifiering av fällorna som kan förekomma under utvecklingsprocessens gång. Ytterligare kan det vara givande att se hur Scrum-utvecklingsmetodiken fungerar för oerfarna grupper och eventuellt hur den skiljer sig från den klassiska modellen.

A.1.2

Frågeställning

1. Hur skiljer sig den klassiska Scrum-utvecklingsmetodiken från den som används av kandidatgrupper och andra professionella utvecklingsteam?

2. Hur ser fördelningen av timmar ut under en sprint?

A.2. Bakgrund

A.1.3

Avgränsningar

Denna rapport baseras på och utgår ifrån en studie som gjordes vid utveckling av flertal kan- didatprojekt år 2020 men vissa aspekter av Scrum-utvecklingsmetodiken utreds bara hos den kandidatgrupp som utvecklar poängsystem för Teknikåttan som också skribenten av denna rapport är en del av. Därför kan utvecklingen hos andra team skilja sig från utvecklingen av detta projekt.

En del av undersökningen baseras på en enkät som skickades runt bland kandidatgrup- per. Eftersom enkäten förväntas att inte bli besvarad av alla studenter kan det vara svårt att förutse om samma beteende skulle ha förekommit hos andra team vid andra mjukvaruut- vecklings tillfällen.

Ytterligare skedde en stor del av utvecklingen under en pandemi som på grund av säker- hetsskäl gjorde fysiska möten omöjliga. All kommunikation skedde över olika slags kommu- nikationskanaler istället.

A.2

Bakgrund

Scrum-utvecklingsmetodiken används mer och mer för mjukvaruutveckling av team med varierande storlekar. Ytterligare diskuteras metodiken i samband med flera IT utbildning- ar. Eftersom denna rapport skrivs som en obligatorisk del av ett kandidatprojekt som in- nehåller mjukvaruutvecklings aspekt fanns det många funderingar på vad som kan va- ra givande att undersöka. Flera kandidatgrupper som utför kandidatprojektet varje år be- stämmer sig för Scrum-utvecklingsmetodik. Därför väckte kunskapen och förståelse an- gående Scrum-utvecklingsmetodiken bland kandidatgrupper ett intresse. Mjukvaruutveck- lingen i samband med kandidatprojektet är ett passande tillfälle för att utreda hur Scrum- utvecklingsmetodiken fungerar för mjukvaruutvecklingen hos små team genom att försöka hitta svar på frågorna i A.1.2.

A.3

Teori

Scrum-utvecklingsmetodiken består av olika slags beståndsdelar som karaktäriserar denna metod. Här beskrivs Scrum-ramverk både som en helhet och i detalj.

A.3.1

Scrum-utvecklingsmetodik

Scrum har sitt ursprung i rugby spel där åtta spelare deltar i en så kallad scrummage. I rugby finns det en situation där alla spelare samlar ihop sig och försöker få kontroll över bollen genom att knuffa varandra [[27]].

Scrum-ramverk är en agil utvecklingsmetod [28] som innebär att utveckling av stora pro- jekt sker iterativt och inkrementellt. En av agil utvecklingsmetodens principer är ett team som jobbar nära varandra. Kommunikation och interaktion mellan människor spelar större roll än verktyg som används [29].

Ken Schwaber i sin tur beskriver Scrum-utvecklingsmetodiken som en komplicerad pro- cess som kräver maximal flexibilitet [27].

Scrum-utvecklingsmetodiken antar att utvecklingsprocessen är odefinierad och okontrol- lerbar. Den betraktas som en svart låda och för att hantera den används olika slags bestånds- delar som beskrivs nedan.

A.3.2

Scrum-beståndsdelar

Scrum-ramverket består av olika beståndsdelar som underlättar utvecklingsprocessen. De hjälper att hantera den odefinierade sprint-fasen [27].

A.3. Teori

A.3.2.1 Produktbacklogg

En lista som tas fram, uppdateras och underhålls av produktägaren. Produktbacklogg in- nehåller element som beskriver alla funktioner och förbättringar som kan behövas imple- menteras i systemet såsom alla problem som behöver lösas. Produktbackloggen är aldrig en komplett lista utan den utvecklas kontinuerligt och dess element prioriteras om under hela projektets gång. Den borde också vara den enda källan till systemets krav för Scrum-mästaren och utvecklingsteamet [28].

A.3.2.2 Sprintbacklogg

En lista vars element kommer ifrån produkt backlogg. Sprintbacklogg är en slags riktlinje för en specifik sprint som innehåller en bild på allt arbete som måste utföras för att uppnå sprintens mål. Den uppdateras kontinuerligt under sprintens gång och ska vara förståelig för varje teammedlem under standup-möten [28].

Sprintbacklogg brukar illustreras som en tabell med åtminstone följande rubriker: To-Do: Vad som är kvar att utveckla; In progress: Vad som utvecklas just nu; Done: Vad som utveck- lades. Sprintbackloggen kan ses som en tillfällig sammanfattning av en sprint.

A.3.2.3 Inkrement

En inkrement är en summa av alla kompletta element ifrån produktbacklogg från både tidi- gare sprintar och den senast avslutade sprinten. I slutet av varje sprint tas det fram ett funge- rande block av system som kan integreras med tidigare versionen. Detta kan också kallas för ett inkrement [28].

A.3.2.4 Sprint

Utvecklingprocessen delas upp i sprintar. Oftast är det en period av en till fyra veckor under vilken utvecklingsteamet tar fram ett inkrement. Varje sprint är planerad och ett sprintmål sätts upp av Scrum-mästare och utvecklingsteam tillsammans.

A.3.2.5 Standup-möte

Oftast är det ett dagligt möte som hela utvecklingsteamet deltar i. Standup-möten är ungefär 15 minuter långa. Under dessa möten svarar utvecklingsteamet på följande frågor: Vad har jag gjort sedan föra standup-mötet?; Hade jag några problem som hindrade mitt arbete?; Vad ska jag göra tills nästa standup-mötet? Standup-möten är ett sätt att hålla utvecklingsteamet uppdaterat och fokuserat på sina uppgifter.

A.3.2.6 Sprintplanering

Sprintplanering är ett möte där sprintmål och element valda ifrån produkt backlogg diskute- ras av alla som tillhör Scrum-teamet. Beroende på sprintens längd kan sprintplaneringen ta upp till åtta timmar. Scrum-mästare håller teamet fokuserat och ser till att diskussionen inte spårar ur. Målet med sprintplaneringen är att komma fram till vad som kan bli levererat av teamet i slutet av sprinten och hur det kan åstadkommas.

På slutet av sprintplanering-möte borde det självständiga utvecklingsteamet kunna för- klara för Scrum-mästare och produktägaren hur de ska uppnå sprintmålet [28].

A.3.2.7 Sprintretrospektiv

Sprintretrospektiv-mötet sker efter en utförd sprint. Detta kan ses som en möjlighet för för- bättringar i kommande sprintar. Mötet kan ta upp till tre timmar beroende på sprintens längd. Scrum-mästare håller teamet fokuserat och ser till att diskussionen inte spårar ur. Målet med

A.4. Metod

mötet är att identifiera problem som inträffade under sprinten och även att kunna föreslå för- bättringar som sedan kan inkorporeras i en kommande sprint. [28] På ett sprintretrospektiv- möte brukar hela teamet svara på följande frågor: Vad fungerande bra under sprinten?; Vad fungerade dåligt under sprinten?; Vad kan förbättras i en kommande sprint?

A.3.3

Scrum-roller

I Scrum-ramverket kan man identifiera tre roller som påverkar och bidrar till utvecklingen.

A.3.3.1 Scrum-mästare

En Scrum-mästare i Scrum-ramverket är en person som leder ett utvecklingsteam och alla Scrum-möten som ska vara korta och fokuserade på utvecklingen. Den identifierar också en initial backlogg som ska utföras under sprintens gång. Scrum-mästaren ser till att alla blir tilldelade ett jobb och att utvecklingen går framåt. För att se till att ny funktionalitet levereras kontinuerligt håller Scrum-mästaren koll på backlogg items och beslut tagna av utvecklings- teamet. Scrum-mästaren är dock inte en teamledere [30].

A.3.3.2 Produktägare

En produktägare i Scrum-ramverket är den person som står närmast kunden. Det är produkt- ägaren som är ansvarig för att ta fram, uppdatera och prioritera items i en produktbacklogg. Produktägaren är också ansvarig för teamets förståelse av produktbackloggen [28].

A.3.3.3 Utvecklingsteam

I Scrum-ramverket är det ett team som brukar bestå av upp till nio personer. Varje teamme- dlem är en professionell utvecklare och som en helhet är utvecklingsteamet oberoende av andra Scrum-roller när det gäller utvecklingen. Utvecklingsteamet bestämmer själv hur varje ny funktionalitet ska implementeras och hur ett inkrement ska tas fram [28].

A.4

Metod

Denna studie använder sig av en litteraturstudie och av en undersökning i form av en en- kät för att kunna besvara på A.1.2. Litteraturstudien gjordes för att kunna bättre förstå och identifiera vilka beståndsdelar Scrum-ramverket består av. Litteraturstudien jämför också hur Scrum-utvecklingsmetodik fungerar för team som använder sig av Scrum på lite olika sätt [30].

Enkäten görs för att kunna jämföra den klassiska Scrum-utvecklingsmetodiken med den som användes av små team och även för att kunna jämföra Scrum hos professionella utveck- lare med Scrum hos mindre erfarna studenter.

Ytterligare undersöks påverkan av Scrum-roller på utvecklingen hos både kandidatgrup- pen som utvecklar poängsystem för Teknik8 och de övriga kandidatgrupperna med hjälp av egna observationer, samt enkäten som besvarades av de övriga kandidatgruppers medlem- marna.

A.4.1

Litteraurstudie

För att undersöka hur Scrum-utvecklingsmetodik används hos professionella team användes en artikel som hittades på IEEE webbsida. Nyckelord som användes vid sökningen var Sc- rum for small teams. Artikel som valdes är skriven av Linda Rising och Norman S. Janoff [30] och berör Scrum-utvecklingsmetodiken för små team som undersöktes på ett AG Commu- nication Systems företag. Den jämför bland annat tre olika team som använde sig av Scrum- utvecklingsmetodik på lite olika sätt. Eftersom artikeln beskriver erfarenheter av tre olika

A.4. Metod

oberoende av varandra team bestämdes det att detta var tillräckligt stöd för att genomföra denna litteruaturstudie.

A.4.2

Enkät

Enkäten skapades med hjälp av Google Formulär och skickades till TDDD96-kursens exami- nator som sedan vidarebefordrade den till alla deltagare i kursen. Enkäten bestod av 11 slut- na frågor och en öppen fråga. Som syfte har den att undersöka om andra kandidatgrupper använde sig av Scrum-utvecklingsmetodiken och hur deras arbete såg ut.

Enkäten bestod av följande frågor:

1. Använde din grupp Scrum-utvecklingsmetod?

• Svar: Ja/Nej (Om svaret var ”Nej” slutfördes enkäten) 2. Hur mycket har du använd dig av Scrum i tidigare projekt?

• Svar: Linjär skala 1-5 (1 - Inget alls, 5 - Alltid)

3. Hur gärna ville du använda dig av Scrum för ditt kandidatprojekt? • Svar: Linjär skala 1-5 (1 - Inte alls, 5 - Jättegärna)

4. Scrum-ramverk består av olika beståndsdelar. Vilka använder sig din grupp av? • Svar: Flerval möjliga (Product backlog; Sprint backlog; Increment; Sprint; Daily

Scrum; Sprint retrospective; Sprint planning)

5. I ett projektarbete med en väldigt begränsad tidsram blir det svårt att följa Scrum på grund av alla möten och planering som ska göras innan arbetet påbörjas. Håller du med?

• Svar: Linjär skala 1-5 (1 - Håller inte alls med, 5 - Håller helt med)

6. Hur stor påverkan tycker du Scrum-mästaren har haft på utvecklingen hittills? • Svar: Linjär skala 1-5 (1 - Ingen alls, 5 - Mycket stor)

7. Hur stor påverkan tycker du produktägaren har haft på utvecklingen hittills? • Svar: Linjär skala 1-5 (1 - Ingen alls, 5 - Mycket stor)

8. Hur högt värderar du kontakten mellan din grupp och kunden? • Svar: Linjär skala 1-5 (1 - Väldigt lågt, 5 - Väldigt högt)

9. Hur mycket tycker du Scrum har hjälpt i ditt kandidatprojekt hittills? • Svar: Linjär skala 1-5 (1 - Inte alls, 5 - Väldigt mycket)

10. Hur mycket känner du att Scrum har hjälp till med att fördela arbetet jämnt bland gruppmedlemmarna hittills?

• Svar: Linjär skala 1-5 (1 - Inte alls, 5 - Väldigt mycket)

11. Hur jämnt fördelade har timmarna under en sprint varit än så länge? • Svar: Ett val från följande möjligt

– Jobbade mest i början av sprinten

– Jobbade jämnt under sprinten

– Jobbade mest i slutet av sprinten 12. Vad tycker du ditt svar i förra frågan beror på?