Kvalitetsarbete

Det huvudsakliga kvalitetsarbetet skedde genom kodgranskningar som genomfördes under projektets gång. Som utgångsläge utfördes granskningarna i helgrupp på utvalda kodfiler.

5.4. Gemensamma erfarenheter

Detta övergick i ett senare skede till att utvecklingsledare granskade kod i releasekandidater (se avsnitt 4.2.3.3). För en mer djupgående beskrivning av kodgranskningsarbetet och för- bättring av denna process, se appendix F. Projektets kvalitet kontrollerades och granskades även genom att tester utfördes under projektets utveckling (se avsnitt 5.3.4).

5.3.4

Testarbete

Syftet med att genomföra tester var att säkerställa att den kod som skrivits var korrekt och att den uppfyllde de krav som specificerats i projektets kravspecifikation. Tester genomfördes kontinuerligt genom utvecklingsprocessen för att minimiera risken att fel upptäcktes för sent i utvecklingsprocessen, då de varit kostsammare att åtgärda. De olika typer av tester som genomfördes var enhetstester för att kontrollera enskilda funktioner, integrationstester för att kontrollera API mellan olika moduler och systemtester för att kontrollera hela systemet.

5.4

Gemensamma erfarenheter

I detta avsnitt beskrivs några av projektgruppens erfarenheter från projektet och sådant som gruppen tagit med sig från tidigare arbeten och projekt.

5.4.1

Erfarenheter från projektet

Nedan presenteras projektgruppens erfarenheter från detta projekt.

5.4.1.1 Förberedelsearbetet

Innan systemimplementationen påbörjades genomfördes ett omfattande förberedelsearbete som resulterade i ett antal dokument. Dessa dokument användes olika mycket under imple- mentationen, men lade grunden för det tidiga implementationsarbetet och var föremål för många diskussioner under projektets gång. De fungerade även som stöd om problem upp- kom eller om något designbeslut var otydligt.

5.4.1.2 Dokumentarbetet

Lärdomar från dokumentarbetet var att gruppen hade uppskattat en tydligare planering av hur mycket tid som skulle ägnas åt dokumenten och när denna tid skulle läggas. Gruppen uppskattade även att mycket av dokumentarbetet gjordes gemensamt, då detta underlättade diskussioner och samarbete.

5.4.1.3 Tidsplanering

Projektet producerade två tidsplaner under projektets gång. Den första var en plan som täck- te hela projektet från början till slut (se figur 5.6). Efter några veckors implementationsarbete skedde en del förändringar i planeringen, vilket ledde till att ytterligare en tidsplan utveck- lades den 14 april 2020. Denna tidsplan omfattade de drygt 1 500 arbetstimmar som återstod att utföra under april och maj månad (se figur 5.7).

Figur 5.8 visar att gruppen totalt ägnade 1 022 timmar åt implementation och design av systemet. Vidare visar figur 5.9 att totalt 789 arbetstimmar lades på skrivande av dokument, varav ungefär 520 timmar lades på kandidatrapporten. Resterande ca 900 timmar lades på uppstart av projektet, undervisning i form av föreläsningar och seminarier, samt administra- tion och möten.

5.4.1.4 Uppdelning i utvecklingsgrupper

Uppdelningen ledde till uppdelning i egna möten och kommunikationskanaler. De olika grupperna hade ett gemensamt möte i veckan, men utöver det bedrevs utvecklingsarbetet mestadels separerat. När delsystem som rörde båda utvecklingsgrupperna implementerades

5.4. Gemensamma erfarenheter

Figur 5.6: Första utkastet av tidsplanen.

5.4. Gemensamma erfarenheter

Figur 5.8: Antalet arbetstimmar som spenderades på design och implementation av systemet.

5.4. Gemensamma erfarenheter

utsågs ansvariga ur varje utvecklingsgrupp som då samarbetade på implementationen av det delsystemet.

5.4.1.5 Ansvarsfördelning

Alla projektmedlemmar fick minst ett särskilt ansvarsområde att arbeta med under projek- tets gång (se avsnitt 2.5.1). Ansvarsuppdelningen fungerade mycket bra. När en ny uppgift visade sig för projektgruppen var det nästan alltid omedelbart tydligt vem som borde få an- svar för att utföra eller koordinatera arbetet med denna uppgift. Genom denna uppdelning kunde projektmedlemmarna fokusera på sina egna arbetsuppgifter och lita på att även andra uppgifter blev gjorda.

5.4.1.6 Kravspecifikation

Systemet implementerades efter en kravspecifikation som togs fram med kunden (se avsnitt 2.1). Gruppen kände att trots att de var medvetna om de krav som systemet skulle uppfylla så glömdes dessa ofta bort, vilket gjorde att implementationen ibland skedde i omotiverad ordning och med fokus på fel delar.

5.4.1.7 Kundsamarbete

Projektet genomfördes med en kund som hade sin vision av slutprodukten. Det var därför viktigt att hela tiden ha en öppen dialog och ha stor förståelse för varandra. Kontinuerlig uppdatering av situationen gjorde att kunden var delaktig i hela implementationen genom veckomöten där problem diskuterades. Detta ledde till att missförstånd kunde undvikas och en produkt kunde tas fram som både kunden och projektgruppen var nöjda med. Det trans- parenta samarbetet gjorde att kravspecifikationen skrevs på ett sätt att visa krav lämnades öppna att tolkas för gruppen.

5.4.1.8 Återblicksmöten

Genom de möten som hölls i slutet av varje sprint utvärderades arbetet som genomförts och eventuella brister eller förbättringsområden påpekades. På detta sätt lärde sig projektgrup- pen vad som kan vara svårt i ett projekt och hur väl de ingående arbetsprocesserna fungera- de. Huvudsakliga punkter som diskuterades var bland annat att mer aktivt arbete med issues behövdes då det ibland var osäkert vem som arbetade med vad och om arbetet var färdigt eller inte. En annan återkommande punkt var uppdelningen av arbetet och tidsfördelningen mellan implementation och dokumentation. Större fokus behövde läggas på dokumentation och gruppen behövde gemensamt ta ett beslut om hur detta skulle säkerställas då det var svårt att ta det ansvaret individuellt. Till sist var dessa möten lämpliga för produktion av release-kandidater och tillät utvecklingledarna att utvärdera produkten regelbundet, något som uppskattades av projektgruppen.

5.4.2

Tidigare erfarenheter

Då alla gruppmedlemmar har erfarenheter från tidigare projekt och projektliknande arbeten samlades dessa lärdomar in för att förbättra utgångsläget inför detta projekt. Dessa presente- rades i projektplanen och implementerades enligt följande:

• Tidsplanering. Projektmedlemmarna hade i tidigare projekt haft problem med detta. Därför användes verktyget Clockify (se avsnitt 3.1.4). Genom detta kunde gruppen log- ga sin spenderade arbetstid och utvärdera var mer resurser behövde läggas under kom- mande veckor. Något som dock inte hanterades i detalj var kopplingen mellan aktivi- teter och förväntad tidsåtgång. Istället planerades arbetsveckor på så sätt att de skulle innebära jämn fördelning av totalt nerlagd tid.

5.4. Gemensamma erfarenheter

• Delad kunskap. Målet var att kunskap om en del av produkten aldrig skulle vara kon- centrerad hos en projektmedlem utan att minst två personer borde besitta kunskapen. Detta var något som följdes till viss del genom gemensam programmering, men in- te upprätthölls för vissa delar av systemet. I detta projekt resulterade det inte i några konkreta problem, men gruppen var ändå medveten om risken som uppstod som kon- sekvens av detta.

• Gemensamt arbete. Gruppen ville möjliggöra mycket gemensamt arbete, då detta skul- le förenkla kommunikation och samarbete i problemlösning. I och med distansläget blev detta en utmaning som löstes med hjälp av verktyget Discord (se avsnitt 3.1.1), där gruppen kunde samlas virtuellt och diskutera. Detta fungerade överlag bra med några få undantag då någon projektmedlem ej nyttjade detta verktyg och blev som konse- kvens svår att kontakta.

• Prioritera arbetsuppgifter. Då det ej är hållbart att endast arbeta med sådant man tyc- ker är kul bestämde gruppen att arbetsuppgifter skulle fördelas gemensamt. Detta im- plementerades genom Scrum-möten där veckans arbete planerades. Detta visade sig dock svårt att genomföra helt, och balansen mellan dokumentarbete och implementa- tion blev stundtals skev trots detta. Sett till implementationsarbetet fungerade detta sy- stem däremot mycket bra då alla alltid hade arbetsuppgifter och de planerade delarna av systemet implementerades i tid.

• Utvärdera planering. Gruppen ansåg det viktigt att utvärdera den gjorda planeringen och skulle göra detta genom att följa projektplanen och uppdatera tidsplanen. Detta hanterades genom att varje vecka hålla ett återblicksmöte som del av Scrum-arbetet. Under detta möte utvärderades veckans arbete och eventuella förbättringar diskutera- des. Uppdatering av tidsplanen gjordes när ungefär halva projektet passerat, då det i detta skede var klart för gruppen vad som behövde göras och hur mycket tid som fanns att fördela.

• Dokumentarbete. En vanlig erfarenhet från tidigare projekt var att arbete med doku- ment ofta prioriteras ner under projektets gång och istället görs i efterhand. Inför detta projekt ansåg gruppen att dokumentarbetet borde göras kontinuerligt. Detta misslyc- kades gruppen till stor del med att uppfylla, och dokumentarbetet utfördes ofta under extrainsatta sessioner där dokumenten stod i fokus. Endast vid några få tillfällen doku- menterades ändringar samtidigt som de bestämdes.

• Kommunikation. En positiv erfarenhet som många av projektets medlemmar upplevt var att bra kommunikation uppmuntrar till problemlösning. För att åstadkomma detta skulle gruppen sätta upp relevanta kommunikationskanaler och hålla gemensamma möten veckovis. Detta fungerade mycket väl genom Scrum och veckomöten, och frågor som dök upp diskuterades direkt och löstes snabbt.

• Sammanhållning. En gemensam åsikt var att god gruppsammanhållning bidrar till god arbetsmoral. För att uppnå detta anordnades en kick-off där gruppmedlemmarna fick lära känna varandra och bli bekväma med gruppen. Vidare såg projektgruppen till att alltid ha en öppen dialog och välkomna åsikter för att säkerställa att alla ingående med- lemmar kände sig hörda och respekterade.

5.4.3

Distansläge

Under projektets gång övergick Linköpings universitet till distansläge. Detta innebar att pro- jektgruppen snabbt fick ställa om till att genomföra arbete på distans. Detta gav erfarenhet av verktyg och erfarenheter som kan användas om liknande situationer skulle uppstå i fram- tiden.