Mycket inspiration togs ifrån kundens redan påbörjade mobilapplikation när det kom till strukturen av webbapplikationen. Främst av allt att dela upp applikationens funktioner i tre separata sidor. Något som är nödvändigt i en mobilapplikation för enkel navigation, men mindre så för applikationer som ska visas på en dator.
Istället hade det varit möjligt att följa en annan designfilosofi genom att utveckla applika- tionen i formen av en enda sida. Detta är något vanligare i skrivbordsapplikationer, men är också fullt möjligt i en webbapplikation.
6.1.2
Återstående utveckling och dokumentation
Ett fokus under utvecklingsperioden var att få klart den rent funktionella implementationen av alla prioritet ett krav i kravspecifikationen innan överblivna utvecklingsresurser spende- rades på visuella detaljer och extra funktioner. Detta har resulterat i en funktionellt robust produkt, men det återstår en del arbete för att kunden ska få ut fullt värde ur produkten.
För kunden är presentationen av en produkt under deras logga mycket viktig. En pro- dukt måste representera den bild företaget vill att dess konsumenter ska ha av dem. Därför är visuell kvalité en hög prioritet för digitala produkter. Detta gör att en visuellt oattraktiv, men funktionell applikation inte är av stor användning. Framförallt när företaget har andra digitala produkter som sätter en hög standard i kvalitén av dess GUI. Därför skulle vidareut- veckling av produktens grafik göra att kunden får mer värde från det redan utförda arbetet kring funktionalitet.
Det är också av värde för kunden att så smidigt och effektivt som möjligt kunna vidareut- veckla produkten utan att spendera onödiga resurser på undersökningar och utbildning av utvecklare. För detta så är koddokumentation en stor hjälp. En del av kvalitetskraven var att ha en viss kommentarindex i koden som beskriver syftet och funktionen av olika delar av kodbasen. Dessa är dock inte alltid extensiva nog i sina förklaringar samt täcker inte alltid mindre delar av större kodstrukturer. Därför hade fortsatt arbete med en mer detaljerad do- kumentation i koden gjort att kunden lättare kunnat utöka och förbättra redan existerande delar av kodbasen innan och efter lansering av produkten.
6.1.3
Lärdomar för framtiden
I kapitel 5.5 breskrivs de erfarenheter som gruppmedlemmar har fått av att delta i detta grupparbete. Alla dessa erfarenheter ger något värde till varje medlem som kan använda dess lärdomar i framtida studie och professionella sammanhang.
Utöver dessa erfarenheter så fick medlemmarna lära sig mer om hur det är att arbeta i en grupp med en solid rollstruktur. Detta är något som oftast inte används i andra kurser, men kan appliceras på många arbetsplatser.
Med erfarenheterna kring kundrelationer beskrivet i 5.5 så har gruppmedlemmarna fått insikt att arbeta i större projekt som involverar ett högre antal människor i olika separata grupper. Inte bara var själva arbetsgruppen i sig större än vad många medlemmar tidigare hade erfarenhet av, arbetet krävde även kommunikation med flera externa personer som hade inflytande på arbetetsprocessen. Nämligen kunden och kursledare. Detta är något som lätt kan bli stökigt om inte korrekt struktur och kommunikation uppehålls under arbetsgången.
6.2
Metod
Arbetet i projektet gick bra men det fanns, som alltid, förbättringsfaktorer. I detta kapitel diskuteras hur metoden för sprintplanering, kodgranskning samt testning påverkat projektet. Kapitlet avslutas även med en kort källkritisk diskussion.
6.2. Metod
6.2.1
Sprintplanering
En central aspekt av Scrum är att underhålla en produkt- och en sprintbacklogg. Tanken är att sprintbackloggen ska färdigställas innan sprintens början och sedan inte modifieras under sprintens gång.
Detta är en aspekt av Scrum som inte följdes under projektet. En initial planering gjordes i början av varje sprint men ärenden lades också till kontinuerligt.
Att ha en mer flytande planering har kändes som ett bra val för denna typ av projekt. Eftersom projektet använt sig av, för de flesta projektmedlemmar, nya tekniker var det svårt att göra rimliga tidsestimeringar för uppgifterna. Det föreföll även naturligt att nya uppgifter uppenbarade sig under arbetets gång och det kändes då smidigt att direkt kunna lägga till dem i innevarande sprint.
En sak som man går miste om är dock att utveckla en uppskattning av gruppens produk- tivitet. Med mer tydligt separerade sprinter kan man vid slutet av varje sprint se hur många uppgifter som hunnit genomföras och hur många som är kvar.
De hade dock varit möjligt att göra något liknande även med det mer flytande arbetssät- tet som användes i detta projekt. Det hade exempelvis kunnat gått att räkna ut differensen mellan tillagda och avklarade ärenden för varje sprint och ändå fått en uppfattning av pro- duktiviteten.
För en vidare undersökning av Scrum som projektmodell se appendix A.
6.2.2
Kodgranskning
Kodgranskningen utfördes som beskrivet i kapitel 4.2.3. Kort sammanfattat innebar det att granskaren kollade igenom kolumnen med kallad granskning i Jira och sökte upp motsvaran- de commits i GitLab, för att sedan läsa igenom koden och vid behov lägga in kommentarer.
Ett stort problem med denna metod var bristen av koppling mellan uppgifter och com- mits. Dels kunde flera commits vara kopplade till samma uppgift och dels kunde deras commit-meddelanden vara svåra att koppla till uppgiftsnamnen. Denna process blev därför onödigt tidskrävande.
Ett annat problem var bristen på översikt, både i Jira och Gitlab. I Jira var problemet främst att det inte fanns en tydlig process för hur ärenden som behövde åtgärdas efter granskning skulle hanteras. Ibland lämnades de kvar i kolumnen granskning och ibland flyttades de tillbaka till ”To do”. Vilka båda kunde leda till förvirring. Ärenden som lämnades kvar i granskning kunde råka bli dubbelgranskade och ärenden som flyttades till ”To do” kunde bli tillbakaflyttade till granskning om utvecklaren inte sett granskningskommentarerna i GitLab. I GitLab var det till en början svårt att få en översikt över vilka commits som blivit grans- kade eller ej. Granskaren behövde själv klicka sig igenom listan, öppna varje commit och leta efter kommentarer. Senare i projektet upptäckes dock en grafvy där granskaren åtminstone kunde se vilka commits som hade kommentarer på sig.
Ett sista problem var att två projektmedlemmar fick ta på sig majoriteten av gransknings- ansvaret. Anledningen till denna uppdelning var att utvecklingsledaren och konfigurations- ansvarig hade mest tidigare erfarenhet av webbutveckling. Detta ledde till att gransknings- processen blev något av en flaskhals. Det kan även leda till minskad kollektiv förståelse för kodbasen, om inte alla projektmedlemmar aktivt läser och granskar varandras kod.
Ett alternativ hade varit att använda sig av GitLabs inbyggda ärendehanteringssystem och merge-förfrågningar. Kodgranskningen skulle då bli mer integrerad i arbetsprocessen och det hade varit lättare att koppla ihop uppgifter med rätt commits.
6.2.3
Testning
Under projektets gång har både manuell och automatisk testning använts. Den automatis- ka testningen har bestått ett antal enhet- och integrationstester som kördes varje gång kod pushades till dev-grenen.