I detta avsnitt så diskuteras metoden för projektet. Här diskuteras utvecklingsmetoden och implementationen av chattsystemet. Även andra aspekter av metoden som kvalitetscoach- ningen (avsnitt 4.3), informationsinsamling och metod för att fånga erfarenheter tas upp och diskuteras.
6.2.1
Utvecklingsmetoder
6.2.1.1 Scrum
Att använda Scrum i mjukvarutuvecklingsprojekt är vanligt i industrin och något som kan vara effektivt. Scrum användes som utvecklingsmetod genom hela projektet. Första halvan av projekt hade gruppen standup-möten varannan arbetsdag, detta ökades till varje arbetsdag under andra halvan. Orsaken till detta upplägg under andra halvan av projektet var för att projektmedlemmarna hade mer schemalagd tid. Detta innebar att mer utveckling kunde ske under andra period av terminen. Med hjälp av upplägget under andra halvan av projektet
6.2. Metod
fick projektmedlemmerna en bra uppfattning om vad resten av medlemmarna gjorde och en bättre inblick i hur gruppen låg till. Tvåveckorssprinter applicerades också under hela projektet. Längden på två veckor fungerade bra eftersom enveckassprinter hade blivit för korta och gruppen hade antagligen inte hunnit med så mycket på den tiden. Dessutom hade längre sprintar på tre veckor eller mer inte fungerat eftersom totallängden på projektet bara var en termin. Därför hade tre eller fler veckor per sprint blivit alldeles för lång tid och för få sprintar för att kunna förbättra processer mellan sprintar. På två veckor kunde gruppen ha en hyfsat stor sprint-backlog och större implementationer hann göras under dessa sprintar. Dessutom var längden på sprintarna bra då det hann dyka upp förbättringsmöjligheter för nästkommande sprint som kunde tas upp på återblicksmöten.
6.2.1.2 Trello
Som tidigare nämnt i rapporten användes ett Trellobräde för att lägga upp aktiviteter till backloggen, sprint-backloggen samt de uppgifter som hade blivit behandlade. Till en början av projektet användes inte Trello så mycket främst på grund av att aktiviteterna i backloggen var generella och stora, till exempel kunde hela dokument vara enskilda aktiviteter. Detta gjorde att Trello inte blev utnyttjat till dess fulla potential. Senare i projektet började dock Trello användas mer i samband med att större aktiviteter bröts ner i mindre delar som kunde delas ut på Trellokort. Trello har en funktion där gruppmedlemmar kan tilldelas olika kort. Detta gjorde det möjligt att få en bra överblick av vad alla gruppmedlemmar jobbade med. I början av varje sprint strävade gruppen efter tilldela en medlem till varje kort för att säkerställa att inga aktiviteter blev bortglömda.
6.2.1.3 Github
Github användes under projektet och var nytt för gruppen eftersom tidigare kurser främst använde Gitlab. Dock är skillnaderna mellan de två olika plattformarna ganska små och det gick snabbt för gruppen att bli van vid användandet. Anledningen till att Github användes istället för Gitlab som projektgruppen är vana med var främst för att kunden ville ha det. Det som fungerade väldigt bra med Github var att gruppen kunde integrera olika testverktyg. Dessa testverktyg var Pytest, pytest-cov, Flake8 och Jest. Varje gång någon pushade upp kod så aktiverades testerna och de kördes på den kod som fanns. Detta var väldigt användbart då det motiverade alla att se till att koden följde kodstandarder samt var testad innan ko- den pushades upp. Dessutom var det lättare att hitta fel som kan ha skapats av den senaste pushen eller andra moduler som kan ha påverkats av misstag.
6.2.1.4 Implementation
I detta projekt användes flera olika programmeringspråk för att implementera koden. Servern var utvecklad i Python med Flask som grund och Socket-IO för socketkommunikationen. Hemsidan var utvecklad i HTML, CSS och TypeScript. Det enda biblioteket som importera- des för gränssnittet var Socket-IO-biblioteket för socketkommunikationen på klientsidan. All stilning och HTML-struktur gjordes från grunden.
6.2.1.5 Systemanatomi
För att skapa chattsystemets arkitektur användes sysstemanatomin som en utgångspunkt. Fi- guren skapa en förståelse för hur arkitekturen är strukturerad samt vilka beståndsdelar borde ingå i systemet. Dessutom förenklade systemanatomin kravdokumenteringen och kravstruk- tureringen. Eftersom systemanatmoin skapade en överblicklig bild av chattsystemet.
6.2.1.6 Alternativa implementationssätt
Det hade varit möjligt att implementera servern i ett annat språk som till exempel C++ för att få bättre prestanda men i detta projekt prioriterades snabb uppsättning före prestanda. Det var därför servern blev implementerad i Python med ett par färdiga bibliotek. En alternativ lösning som hade gjort utvecklingen av hemsidan betydligt snabbare hade varit att använda bibliotek som React. Detta hade underlättat en hel del då stor del av tiden lades på att försöka få hemsidan attraktiv. Anledningen till utvecklingen från grunden var att öka lärningsmöjlig- heten för projektet. Genom att lösa problem utan bibliotek skapades en bättre förståelse för utvecklingen. Ett annat alternativt implementationssätt hade varit att utveckla i JavaScript istället för TypeScript. Detta hade gjort det enklare att sätta upp projektet då det inte krävs en fungerande kompilator för att göra koden körbar. Dock så hade detta gjort att det hade varit svårare att sätta upp en rimlig kodstruktur då det inte går att statiskt typa variabler. Det hade också troligtvis skapat svårlösta buggar som inte uppstod i detta projekt då TypeScript användes.
6.2.2
Metod för att fånga erfarenheter
Dagliga standup-möten var ett sätt för gruppen att utbyta erfarenheter och information samt identifiera problem. Om det behövdes ett längre möte bokades det in gemensant vid ett tillfäl- le där alla kunde närvara och lades sedan till i den gemensamma kalendern. Återblicksmötet i slutet av varje sprint var ett annat tillfälle att fånga erfarenhet. På dessa möten diskuterades vad som hade gjorts under sprinten och vad som kunde förbättras inför nästa sprint.
6.2.3
Kvalitetscoachning
Gruppen samarbetade med en studentgrupp från TDDE46. Två representater från projekt- gruppen, kvalitetssamordnaren och testansvarig, gick på 4 schemalagda möten och ett extra 5:e möte som anordnades mellan grupperna. Studenterna från TDDE46 hjälpte inte bara till med kvaliteten utan delade också med sig av deras egna erfarenheter från deras kandidat- arbeten. Mellan mötena fick gruppen egna uppgifter att utföra inför mötet. Projektgruppen coachades samtidigt med projektgruppen PUM1 och det blev värdefulla tillfällen att utbyta information.