Vilket stöd kan man få genom att skapa och följa upp en systemanatomi?

För att få en tydlig och konkret bild av systemets uppbyggnad togs en systemanatomi fram. Denna hjälpte gruppen att se vad som praktiskt behövde implementeras och om den initiala bilden av systemet var sund.

4.2

Utvecklingsplan

Projektet har arbetat efter arbetssättet Scrum och använt Git för versionshantering. Eftersom detta avsnitt innehåller många utvecklingsspecifika uttryck på engelska följer i tabell 4.1 de- finitioner av några begrepp.

Tabell 4.1: Utvecklingstermer.

Uttryck Beskrivning

Branch Gren. Ett Git-objekt som definierar en ny förgrening i utveck- lingshistoriken.

Main branch Gren där levererbara versioner av mjukvaran läggs till.

4.2. Utvecklingsplan

forts. från föregående sida

Uttryck Beskrivning

Release branch Gren där potentiellt levererbara versioner av mjukvaran läggs till.

Development branch Gren där kompletta features läggs till.

Feature branch Gren fokuserad på en minimal utvecklingsidé. Commit Ändring av kod som läggs på en branch.

Issue Identifierat problem eller förändringsuppmaning som samlas och hanteras i Kanban-brädor på GitLab.

Merge Sammanslagning av en branch till en annan. Merge request Förfrågan om att få göra en merge.

Fast forward Term som beskriver att ändringarna som görs vid en merge kan göras utan konflikter som måste lösas manuellt.

Repository Förvaringsplatsen för Git. Branches, commits, issues och merge requests samlas alla i ett repository. I detta projekt ligger dessa på GitLab (se avsnitt 3.1.3).

4.2.1

Utvecklingsmetod

Under projektets utvecklingsarbete har en variant av Scrum använts. Scrum är en agil ut- vecklingsmetod som definierar hur arbete utförs, med förhoppning om att effektivisera det. Iterationslängden var en vecka lång. I huvudsak följde detta projekt den metod som utformas i The Scrum Guide. [49] Nedan listas dess olika händelser och hur de modifierades till detta projekt.

4.2.1.1 Utvecklingsmöte

Denna händelse kallas i The Scrum Guide för Sprint Planning. Här sattes ett utvecklingsmål för veckan och en plan gjordes därefter. Detta mål såg i första hand till så att nästkommande milstolpe möttes, men kunde involvera andra utvecklingsmål. Målet i sig uttrycktes som ett specifikt utvecklingsstadium hos produkten. Målet formulerades alltså inte som att ”Städa upp koden”, utan istället ”Produkten ska kunna levereras med en uppstädad kodbas”.

Här valdes aktiviteter utifrån de issues som låg i respektive utvecklings-repository. Dessa betraktades som projektets Product Backlog. Då issues valts så att de uppfyllde utvecklingsmå- let lades dessa i en GitLab-milstolpe. En milstolpe skapades för varje vecka och motsvarade alltså en Sprint Backlog. Notera att dessa milstolpar representerade sprint-målet och inte nöd- vändigtvis projektets utvecklingsmilstolpar.

Det som bestämts under detta möte ändrades inte under veckans gång, om inte utveck- lingsledare sade så. Detta gjordes endast vid extraordinära händelser, som att projektets mål plötsligt ändras av en extern part.

4.2.1.2 Dagliga scrums

Dagliga scrums genomfördes varannan dag, eftersom projektmedlemmarna hade andra kur- ser parallellt med detta projekt. På dessa möten planerades de nästkommande 48 timmarnas arbete i detalj. Det var viktigt att inte planera längre fram än dessa 48 timmar, eftersom den diskussionen ändå skulle komma vid nästa möte. Dessa möten fick ej ta mer än 10 minuter. Under detta möte besvarade varje utvecklingsmedlem frågorna:

4.2. Utvecklingsplan

2. Vad gör jag idag och imorgon som innebär att produkten tar sig närmare målet? 3. Vilka problem har jag just nu som hindrar mig från att produkten utvecklas?

När frågorna besvarades gällde det att hålla det kort. Målet var att informera övriga par- ter om vilken utveckling produkten hade gjort. Hade produkten inte gjort någon utveckling skulle projektmedlemmen exempelvis inte spendera tid på att förklara hur jobbigt ett pro- blem hen fastnat på var. Att inte ha gjort någon utveckling var alltså ett godtagbart svar. Problem togs upp under fråga 3, men beskrivningen hölls kort och saklig. Efter att dessa tre frågor besvarats individuellt gavs en kort stund åt att reflektera över om utvecklingen var i fas med planeringen och om några andra möten behövdes. Efter detta avslutades den dagliga scrumen.

Då mötet avslutats fick detaljer gärna diskuteras, men det ansågs viktigt att detta inte gjor- des på den dagliga scrumen. Det gjorde att utvecklare som inte behövde delta i diskussionen kunde göra andra saker.

4.2.1.3 Utveckling

Utvecklingsarbetet skedde på distans. När en projektmedlem satte sig för att jobba med ut- veckling fanns hen alltid tillgänglig på Discord (se 3.1.1). Där kunde då projektmedlemmen dela skärm med andra utvecklare och föra diskussioner. I övrigt utfördes arbetet på samma sätt som om det bedrivits på universitetet.

4.2.1.4 Restarbete

Om arbete återstod i slutet av arbetsveckan var målet att det i största möjliga mån ändå skulle genomföras under nästkommande vecka. Såg det ut att bli stora mängder restarbete kvar informerades utvecklingsledaren så tidigt som möjligt.

4.2.1.5 Återblick

Återblicken var en kombination av Scrum retrospective och Scrum review från The Scrum Guide. I detta projekt genomfördes den endast av projektets tre utvecklingsledare. Under återblicken gjordes en metaanalys av veckans arbete. Frågor som diskuterades var hur arbetet fungerat för utvecklarna, hur processen fungerat, vad som kunde förbättras och vilka ändringar som borde göras. För att alla problem och åsikter skulle komma fram var det viktigt att övri- ga projektmedlemmar hade meddelat utvecklingsledarna innan veckans slut om eventuella problem som hade uppstått under veckan.

4.2.2

Veckoplanering

Schemaläggningen för aktiviteterna ovan anges i tabell 4.2.

Tabell 4.2: Utvecklingsschema

Mån Tis Ons Tors Fre Lör Sön

Utvecklingsmöte X

Daglig Scrum X X X

Utveckling X X X X X

Restarbete X

4.2. Utvecklingsplan

4.2.3

Versionshantering

Git användes för projektets versionshantering. Detta skedde på uppmaning av kursledning- en. En fullständig version av verktyget GitLab fanns tillgängligt för projektets deltagare via Linköpings universitet (se avsnitt 3.1.3). Det finns många sätt att använda Git men grundat i en diskussion på Atlassians webbplats [50] användes en anpassning av GitFlow. GitFlow definierades av Vincent Driessen år 2010 [51] och är en robust metod för att hantera projekt i större skala. Eftersom detta projekt var i något mindre skala implementerades arbetssättet på ett något mer ledigt sätt. Målet var dock att hålla den övergripande strukturen som definierat. Arbetsflödet i GitFlow illustreras i figur 4.1.

I detta arbete gavs några av projektrollerna speciella ansvar för versionshanteringen. När en ny release-kandidat kom till development-branchen fick testledaren och kvalitetssamord- naren (se avsnitt 2.5.1) ansvar att granska denna så att den höll eftersökt kvalitet. Samma sak gällde för varje delansvarig (till exempel gränssnittsansvarig) då feature-brancher föreslogs för merge till utvecklings-branchen.

4.2.3.1 Commit-meddelanden

Meddelanden i Git höll en gemensam struktur. Alla meddelanden och text rörande kod och utvecklingsarbete skrevs på engelska. Det fanns inga krav på att språket skulle vara formellt, men däremot skulle språket vara precist och därför lades det vikt på korrekt terminologi. Tempus hölls konsekvent och commit-meddelanden skrevs i presens, till exempel ”Add new feature.” istället för ”Added new feature.”. Varje commit-meddelande listade tydligt de änd- ringar som gjorts och vid större ändringar beskrevs även de ingående komponenternas inter- aktion. Varje commit var sammanhängande och rörde en minimalt nödvändig mängd änd- ringar. Stora ändringar delades i största möjliga mån upp i flera commits. Meddelanden som ”skräp git”, ”test”, ”fungerar nu” eller ”!%#&” var strängeligen förbjudna.

4.2.3.2 Merge requests

När en feature branch var redo att merge:as till utvecklings-branchen gjordes detta genom en merge-request. Denna granskades och godkändes av minst en (för back-end) eller två (för front-end) granskare utöver skribenten innan en merge kunde ske. Det lägre antalet granskare för back-end berodde på att denna utvecklingsgrupp var mindre än utvecklingsgruppen för front-end. En merge tilläts endast om den kunde göras fast forward, vilket betydde att ansvarig utvecklare själv var tvungen att hantera konflikter. Dessa skulle lösas med en lokal merge.

4.2.3.3 Releases och versionsnummer

Under utvecklingsarbetet jobbade en utvecklare alltid mot en release. Varje release hade ett versionsnummer på formen X.X.X där version 1.0.0 var projektets första kompletta version. Varje sprint-mål motsvarade en release, och dessa ökade versionsnummret till X.1.0, X.2.0, X.3.0 och så vidare.

Nuvarande release var den release som just då jobbades mot. Under arbetet mot nuvaran- de release prioriterades de tillägg som ingick i det mål som satts för den aktuella sprinten. Tillägg som ingick i kommande releaser fick arbetas med, men dessa kunde inte mergeas till development-branchen förrän den release tillägget siktade mot var nuvarande release.

Nästa release blev nuvarande release då en release branch skapades. Detta betydde att alla tillägg till nuvarande release var integrerade och att man nu kunde gå vidare till nästa release. Således var alltså nuvarande release till exempel 0.3.0 fram till att en release branch skapas. Nuvarande release blev då direkt 0.4.0.

4.2. Utvecklingsplan

Feature

Development

Release

Master

0.2.0 0.1.0 Merge request Branch Pull Commit

4.2. Utvecklingsplan

4.2.3.4 Branchstruktur

Gitflow definierar fem olika typer av branches. [51] Denna struktur användes även i detta projekt, med mindre ändringar. Projektet hade två huvudsakliga branches, Development och Master, samt tre typer av temporära branches, Feature, Release och Hotfix.

• Development - Denna branch hade till syfte att integrera tillägg. Notera att tillägg från nästa release inte fick läggas till på Development innan en release branch skapats för nuvarande release.

• Master - Denna branch samlade kompletta och testade versioner av mjukvaran. I Git- Flow innehåller master vanligtvis endast kompletta helversioner (1.X.X, 2.X.X, osv), men eftersom detta projekt var så begränsat i omfattning lades även första nivån av subversioner på master.

• Feature - Feature-branches, som ibland kallas Topic branches i annan litteratur, förgrenas från och mergas till Development. Syftet med en feature-branch var att isolera ändring- ar relaterade till en minimal utvecklingsidé. Dessa hölls därför begränsade i omfattning och mergades tillbaka till Development så tidigt som möjligt.

• Release - Dessa branches förgrenades från Development och mergades till Master. Release-branches innehöll releases med komplett tilläggsinnehåll och var endast till för att testning och buggfixar skulle kunna ske separerat från vidare utveckling. En- dast små ändringar fick alltså göras på release-branches. En utvecklingsledare skapade release-branchen och lämnade sedan över till kvalitets- och testansvariga.

• Hotfix - Hotfix-branches förgrenades från Master och kunde sedan mergeas tillbaka till Master eller Development. En hotfix lagade ett kritiskt problem i produkten som upp- täcks efter det berörda tillägget kommit till Master. En Hotfix ökade versionsnummret med x.x.1.

5

Resultat

I denna del av rapporten beskrivs och sammanställs resultaten av projektet som projektgrup- pen har åstadkommit.

5.1

Systembeskrivning

I detta avsnitt beskrivs systemets design och implementation.