Detta gjordes genom att schemalägga ett möte på minst en timme i början av varje sprint där alla gruppmedlemmar samarbetade med att skapa arbetsuppgifter för sprintens backlogg med tydliga beskrivningar. Detta ledde till att det inte behövdes schemalägga extramöten i mitten av sprinten så som det gjordes för sprint två.
Något som inte var en processförbättring, men som ändå gjorde att gruppens arbetspro- cess blev bättre var att gruppen fick en ökad förståelse av kundens önskemål. Detta gjorde det enklare att planera den framtida utvecklingen vilket gjorde att arbetet flöt på bättre.
5.4.5
Kvalitetskrav
Kvalitetskraven satte tydliga mål kring kod-struktur, det skulle följa black och flake8, samt dokumentation, då alla funktioner skulle ha en docstring. Utvecklingen utgick från dessa krav vilket resulterade i läsbar och väldokumenterad kod; vilket var speciellt viktigt eftersom kunden Saab uttryckt att de vill vidareutveckla BPSA.
Att i genomsnitt 70% av uppgifterna under en sprint skulle genomföras nåddes med god marginal då minst 90% av uppgifterna klarades vid varje sprint. Kravet sattes upp tidigt i projektet, innan gruppens medlemmar hade någon vidare förståelse till hur det skulle vara att arbeta med SCRUM i ett projekt av denna storlek. SCRUM har redan krav på att varje sprint ska vara välplanerad och att alla uppgifter som inplanerats i en sprint ska genomföras. Detta gjorde att kravet i slutändan inte fyllde någon större funktion.
Det sista kvalitetskravet var att minst 60% av koden skulle testas med automatiska tester. Detta kom senare att modifieras till att exkludera det grafiska gränssnittet, men även detta krav nåddes med god marginal.
5.5
Gemensamma erfarenheter
Detta projekt är det största och mest seriösa mjukvaruprojekt som projektmedlemmarna varit med i. Detta har bidragit till att projektmedlemmarna har fått många nya erfarenheter.
5.5.1
Tidigare grafisk prototyp
Att tidigt ta fram en prototyp som man kan visa för kunden gör att man tidigt fångar even- tuella missförstånd om hur produktens design och funktion ska vara.
Gruppen tog i ett tidigt skede fram en grafisk prototyp på hur de tänkte att gränssnittet skulle kunna fungera. Det visade sig att det inte varit riktigt samma sak som kunden hade tänkt sig vilket ledde till att projektgruppen fick en tydligare bild över vad de faktiskt ville ha. Figur 5.4 visar ett första utkast av gränssnittet och figur 5.5 visar en senare version.
5.5.2
Planering av sprints
En lärdom man kan dra från avsnitt 5.4.2 är att man bör se till att det finns saker att göra även om backloggen tar slut. Man skulle till exempel kunna göra detta genom att sätta upp några preliminära aktiviteter för nästa sprint som man kan börja på tidigare om tillfället finns.
5.5.3
Reflektionsenkät
Detta avsnitt sammanfattar projektmedlemmarnas svar på reflektionsenkäten. Erfarenheter och lärdomar
Projektgruppen upplevde generellt att arbetet med en strikt tidsplanering var en viktig er- farenhet. En strikt tidsplanering upplevdes ge en bättre översikt av arbetet. I enkätsvaren beskrev en gruppmedlem att de tog med sig lärdomen av att börja arbeta i tid, så att mäng- den arbete inte blev orimligt mycket mot slutet.
5.5. Gemensamma erfarenheter
Figur 5.4: En skärmbild på gränssnittet i ett tidigt stadie
Figur 5.5: En skärmbild på gränssnittet i ett senare stadie
Kommunikation nämndes i många av gruppens enkätsvar. Omställningen till arbete i en, för gruppen, relativt stor arbetsgrupp upplevdes som en viktig erfarenhet, och även att det då blev ännu viktigare med bra kommunikation i gruppen. Planeringen som krävdes för att få åtta personer att arbeta effektivt på ett projekt framgick också som nytt för gruppen. Faktiskt arbete med arbetssätt och verktyg som kontinuerlig integration, GitLab och Scrum upplevde gruppmedlemmar som bra. Flera enkätsvar belyste också vikten av kontinuerlig kommunikation med kunden för att försäkra sig om att produkten som utvecklades var den som faktiskt efterfrågades. Distansarbetets påverkan nämndes också i flera enkätsvar. Kom- munikation och planering upplevdes som svårare som följd av distansarbetet, och teambuil-
5.5. Gemensamma erfarenheter
dingaktiviteter så som kickoffs upplevdes som viktigare än vanligt just för att främja kom- munikationen inom gruppen.
Vad hade kunnat göras annorlunda?
Gällande arbetsmetodik upplevde gruppen att Scrum-varianten som användes hade kunnat justeras. En projektmedlem upplevde att valet av att ha skriftliga Scrum standups istället för muntliga under projektet nog var ett misstag. Gruppmedlemmen ansåg att syftet med att ha standups försvann då det inte riktigt blev någon återkoppling från gruppen, åtminstone inte på samma sätt som en muntlig standup hade gett. Även beslutet att ha sprints om två veckor snarare än kortare om en vecka upplevdes som ett felaktigt beslut, eftersom veckornas arbets- fördelning varierade. Detta ledde till att medlemmarna under vissa sprints fokuserade helt på dokumentskrivande första veckan och utveckling på den andra, vilket gjorde planering och utvärdering av sprints blev svårare.
Pappersprototyper nämns också i enkäterna som en förbättringspunkt, då för att under- lätta kommunikationen med kund. Detta verktyg hade kunnat användas för att försäkra att projektgruppens bild på produkten var den samma som kunden hade.
För att förbättra kommunikationen nämns användandet av en gemensam kalender. Pro- jektmedlemmen menade att den gemensamma kalendern skulle tillåta gruppmedlemmarna att skriva upp när de planerade arbeta, och att detta skulle underlätta planeringen av gemen- samt arbete.
Hur nöjda är projektmedlemmarna med arbetet?
På påståendet ”Jag är nöjd med det vi har utvecklat.” fick projektmedlemmarna svara hur mycket de höll med på en skala 1–10 där 1 är ”Jag håller inte med alls” och 10 är ”Jag håller helt med”. I genomsnitt svarade gruppen 8,00.