tidigare projekt var att antalet dokument som skapades var fler. De olika dokumenten hjälpte till att planera vad, när och hur saker skulle implementeras vilket gav en tydligare bild.
En annan förbättring mot tidigare projekt var att det fanns en vald utvecklingsmetod. Scrum som metod gjorde att arbetet kunde delas in i mindre delar i form av sprinter. I början av varje sprint utfördes en planering och i slutet en utvärdering, vilket gjorde att varje vecka var planerad och utvärderingen gjorde att metoden kontinuerligt kunde revideras. Till en början visste projektgruppen inte helt hur arbetet skulle gå till men efter varje sprint blev det bättre och bättre. Metoden som projektgruppen använde gjorde att hela gruppen var involverad i varandras arbete och varje gruppmedlem hade kännedom om vad andra arbetat med. Om problem uppstod kunde det tas upp på det dagliga Scrummötet, följas upp och lösas tidigt.
En större vikt lades på att programkod skulle skrivas av hög standard och det gjordes genom kodgranskning. Detta medförde att koden både blev mer läsbar och fick en bättre kodstruktur. Ytterligare om kodgransknings för- och nackdelar finns att läsa i kapitel C.
6.1.4
Lärdomar
Lärdomar som tas med från projektet är framförallt erfarenheten från utvecklingsmetoden som användes samt olika tekniker, ramverk och verktyg. Tidigare saknade de flesta av grupp- medlemmarna erfarenhet av att använda GitLabs egna CI/CD och efter projektet har nu samtliga fått en försmak som kan vara värdefull inför framtiden. Projektgruppen har ock- så fått arbeta med Docker som används flitigt i yrkeslivet. Det har också erhållits kunskaper inom olika programmeringsgränssnitt som REST API och hårdvarurelaterade program som Chirpstack. En viktig lärdom är också att arbeta med typsättningssystemet LaTeX som möj- liggjorde att det blev effektivare att arbeta med dokument som följer samma standard och struktur.
Projektgruppen har också fått erfarenhet att arbeta mot en kund vilket var lärorikt. En lärdom som kan tas med är att det inte alltid är enkelt att få kontakt med en kund i jämförelse med en handledare från andra kurser. Det gör att gruppen får ett större eget ansvar och behöver vara ute i god tid när kundkontakt behövs.
6.2
Metod
Nedan följer en diskussion gällande de arbetssätt som gruppen tillämpade under projektet.
6.2.1
Roller och gruppdynamik
Projektgruppen tog tidigt beslut om vilka roller som skulle fördelas inom gruppen, och dessa stod sedan fast genom projektet. Denna tydliga fördelning av ansvarsområden ledde bland annat till att gruppen fick en naturlig strategi för att dela ut ansvar för arbetsuppgifter. Däre- mot förlitade sig gruppen sällan på att en roll skulle ha sista ordet kring beslut inom sitt an- svarsområde, utan lade tid på att gemensamt fatta demokratiska beslut istället vilket ledde till ett mer utbrett ägandeskap av fattade beslut inom gruppen. Gruppens fokus på demo- krati kring beslutsfattande kan ha bidragit till att en del beslut tog längre tid, men gruppen upplevde det ändå som något positivt i sammanhanget, då det gemensamma ägandeskapet upplevdes viktigare än snabba beslut.
6.2.2
Sprintmetod
Den sprintmetod som nyttjades under projektets gång såg till största del inte så mycket för- ändring. Bestämmelser om sprintars längd om två veckor hölls kvar då det visade sig fungera bra. Det gav mycket utrymme för utvecklingsarbete och dokumentskrivning i en bra balans med tillräcklig mängd planeringstid. Längden på sprintarna gjorde även att utvärderingarna
6.2. Metod
inte kom alltför lång tid ifrån det genomförda arbetet de behandlade vilket ledde till givande utvärderingar där endast mycket lite glömts bort. Som komplement till planering och utvär- dering av sprintar hölls dagliga Scrummöten som bidrog med ytterligare kontinuitet i arbetet inom projektet genom att projektgruppen ständigt uppdaterade varandra om vad som skett dag till dag. Dessa dagliga möten gav även projektmedlemmarna ett forum att lyfta frågor och funderingar som dykt upp samt att be om hjälp utan att behöva boka in ytterligare möten, vilket gjorde det lättare för gruppen att tackla nya utmaningar inom projektet gemensamt. Dessutom hjälpte det dagliga mötet projektmedlemmarna att hitta motivation till arbete när övriga gruppen förväntar sig att visst arbete ska utföras. Även de dagar då inga nya problem lyftes på det dagliga Scrummötet bidrog mötena med en stärkt gemenskap och arbetsmoral inom gruppen, om inte annat genom gemensam självömkan kring tidiga morgnar.
En viktigt del av varje sprint var de aktiviteter som konkretiserades under planeringen och sedan lades in i projektets Kanbanbräde. Genom att konkretisera arbetsuppgifter och samla dem på ett ställe gick det enkelt att få en överblick av arbetet under en eller flera sprin- tar och utifrån det prioritera framtida arbetsinsatser. Tillsammans bidrog dagliga Scrummö- ten och översikten från Kanbanbrädet, där uppgifter visuellt tilldelades projektmedlemmar, till att hela gruppen enkelt kunde veta vem som arbetade med vad och till vem de skulle vända sig för frågor inom ett visst område.
Varje sprint avslutades med ett utvärderingsmöte där projektgruppen gick tillbaka till det som planerats för sprinten och jämförde med det arbete som utförts. I samband med mötet fylldes en enkät i som specificerats i 5.5.2. Dessa möten gjorde det möjligt att dra slutsatser om bland annat hur arbetsbördan sett ut jämfört med den som uppskattats på sprintplanerings- mötet för att förbättra framtida uppskattningar av arbetsuppgifters tidsåtgång. Dessutom gav de gruppen möjlighet att omsätta enkätsvar till förbättringsförslag och att omgående fat- ta beslut om dessa om så behövdes.
6.2.3
Utveckling
Under början av projektet delades gruppen upp, en grupp arbetade på hårdvara, en på REST API och en på databaserna. Fördelningen av gruppmedlemmar per grupp var tre, tre respek- tive två. Det möjliggjorde att gruppen kunde fokusera på grundsystemet som gruppen ansåg var viktigare att få klar innan instrumentbrädan påbörjades. Detta fungerade bra då instru- mentbrädan krävde relativt lite arbete implementationsmässigt då Grafana tillhandahåller funktionalitet som gör stor del av arbetet automatiskt genom att enbart koppla databaserna till instrumentbrädan. Allt eftersom de olika komponenterna blev färdiga påbörjades utveck- lingen av användargränssnittet. Då alla grupper blev färdiga med sina komponenter till stor grad samtidigt fick majoriteten av gruppmedlemmarna sätta sig in i Grafana och instrument- bräden.
Vid utveckling av de olika modulerna av systemet användes parprogrammering fastän grupperna bestod av två eller tre gruppmedlemmar. Parprogrammeringen gjordes genom att en utsågs till förare och de andra utsågs till navigatörer. Genom att använda parprogramme- ring som utvecklingsmetod kunde projektmedlemmarna kontinuerligt granska koden och lära sig av varandra under utvecklingen. Den kontinuerliga granskningen gjorde att fler tim- mar kunde läggas på utveckling och färre på att granska koden i efterhand. Indelningen i grupper gjorde också att det alltid fanns minst två personer som förstod det som utveck- lats. Indelningen ledde till att det blev tydligare vad som skulle göras, av vem och vem som kunde kontaktas om det behövdes hjälp inom ett visst område. Den största nackdelen med indelningen var att projektgruppens medlemmar fick ett sämre helhetsperspektiv och att in- tegreringen av olika moduler blev svårare. En annan nackdel är att när två eller fler personer utvecklar tillsammans blir kostnaden i timmar betydligt större och det var något som pro- jektgruppen jobbade med att effektivisera.
6.2. Metod
6.2.4
Testning
Upplägget med kontinuerlig testning i samband med utveckling var något som gruppen upplevde som bra. Efter eller under tiden funktioner utvecklats skrevs enhetstester för att kontrollera att funktionens beteende och utdata var korrekt. Det skrevs också tester när krav skulle kontrolleras och detta gjordes av någon av de andra arbetsgrupperna då den egna gruppen inte fick skriva tester till sin egen kod, detta ledde till en ökad förståelse av övriga moduler i systemet. Tester som skrevs skapade tillsammans en testkörare och dessa kunde automatiseras och exekverades automatisk i samband med att kod lagts upp på Gitlab. Den automatiska testningen utfördes med hjälp Gitlabs inbyggda CI/CD och under testningen kunde även kodstandard och kodtäckning kontinuerligt följas upp. Den automatiska gransk- ningen av koden gjordes utan ytterligare ansträngning, vilket bidrog till att gruppen kunde fokusera på att utveckla snarare än att lägga tid på att läsa de ibland hundratals rader med kod som en funktion eller klass kunde bestå av.
6.2.5
Kodgranskning
För att gruppen skulle få flytta kod från en funktionsgren till utvecklingsgrenen behövde ko- den genomgå en kodgranskning. Kodgranskningen genomfördes av två gruppmedlemmar som inte skrivit den kod som skulle granskas. Detta gjordes för att nya opartiska ögon skulle granska koden, finna fel, komma med nya tankar och peka ut felaktigheter. Kodgranskning- en gjorde att den kod som placerades på utvecklingsgrenen var mer stabil och att mindre tid behövde läggas längre in i projektet för att laga enkla fel. Gruppen upplevde att detta var ett mycket effektivt sätt att genomföra kodgranskning och att slutprodukten blev bättre till följd. GitLabs funktionalitet merge requests underlättade denna process och nyttjades tacksamt av projektgruppen. För en djupare redogörelse av kodgranskning se C.
6.2.6
Dokumentgranskning
Inför varje inlämning skedde dokumentgranskning av samtliga gruppmedlemmar. Det gjor- de att stavfel, konstiga formuleringar och faktafel minskade i dokumenten innan de lämnades in. Det möjliggjorde även att hela gruppen kunde få en bättre översikt av projektets alla delar, från hur testning skulle ske till hur hårdvarumodulen är uppbyggd. Efter det första gransk- ningstillfället insåg gruppen att det var ineffektivt att gå igenom dokument i helgrupp och valde därefter att följa upp granskningen i mindre grupper.
6.2.7
Versionshantering
Gruppen uppfattade att versionhanteringen gick bra. Då systemet var tydligt uppdelat i de olika komponenterna även på GitLab uppkom aldrig konflikter mellan olika filer eller grenar. Användningen av feature branches fungerade också bra vid tillägg av funktioner och testning då det blev tydligt vilken version som inte var fullt godkänd. Huvudgrenen var tänkt att alltid innehålla en stabil version vilket för detta projekt inte var lämpligt då projektet var för litet och över en för kort tid för att kunna innehålla flera stabila versioner. I praktiken sammanfogades utvecklingsgrenen en gång med huvudgrenen vilket gav en stabil version.
6.2.8
Kundkontakt
Under projektet skedde majoriteten av kundkontakten över mejl med enstaka videomöten. I efterhand har projektgruppen konstaterat att regelbundna, exempelvis veckoliga möten, med kund hade kunnat förenkla utvecklingsarbetet. Då hade kunden bland annat kunnat ge respons på mindre problem och bidra med insikt och önskemål på ett smidigt sätt utan långa väntetider. Projektgruppen har också konstaterat att det skulle vara önskvärt att ha fler demonstrationstillfällen med kund men att projektupplägget som innebar att arbete med