Gebruik van Gitlab en git¶

Tijdens dit project maken jullie weer gebruik van Gitlab en git.

Gitlab¶

Het grootste deel van de Gitlab repository voor dit project richt je zelf in met je team:

Maak een board ‘Product Backlog’. Hierop komen alle user stories te staan.
Maak voor iedere sprint (sprint 4, 5 en 6) een board aan met vier lists (Open, Doing, Verify, Closed)
Koppel aan iedere sprint-board de juiste Milestone. De milestones zijn al aangemaakt in de repository. Zie verder de planning.
Gebruik, waar nodig, duidelijke labels.
Indien je epic user stories gaat maken houd dan rekening met de volgende uitleg over Epics.
Om een user story toe te wijzen aan een sprint wijs je deze toe aan een Milestone. Dit kun je doen bij de eigenschappen van een user story.
Om een Burndown Chart te krijgen moet een Milestone een begin- en einddatum hebben, deze vind je onder Planning. Vervolgens vind je de Burndown Chart door op één van de Milestones onder Plan > Milestones te klikken.
Aan het eind van een sprint moet er altijd een bruikbaar product zijn. User stories die niet af zijn gaan door naar de volgende sprint. Test een user story dus goed voordat je deze op Done zet! Dit doe je onder andere door de Definition of Done na te lopen. Hier valt ook de aanwezigheid van tests onder!

Nog een aantal aandachtspunten:

Iedere user story waar aan gewerkt wordt dient eent zogenaamde vertical slice te zijn. Hiermee wordt bedoeld dat alle benodigde onderdelen zijn opgenomen om een stuk functionaliteit op te leveren: HTML, CSS, Web Components, API en Database communicatie. Een afgeronde user story is dus nooit énkel de frontend of énkel een API, het is een combinatie van alles bij elkaar en op zichzelf dus volledig functioneel.
Maak gebruik van de Burndown Chart in jullie repository en probeer de ideale lijn qua verbranding van punten te volgen.

Git¶

Zaken waar je rekening mee dient te houden bij het gebruik van Git:

Werk in branches op functioneel niveau. In het artikel over git lees je meer over het gebruik van branches.
Commit en pushed regelmatig. Ditzelfde zou je kunnen zeggen over mergen om vervelende merge conflicten te voorkomen.
Commit messages zijn met actief taalgebruik beschreven (Added/Removed/Fixed/Changed …). Een alternatief is het gebruik van Conventional Commits.

Teampagina en samenwerkingscontract¶

Ieder team maakt een teampagina en een samenwerkingscontract. Deze worden vastgelegd in de docs-map van de Gitlab repository. De teampagina en het samenwerkingscontract zijn via de documentatie site in te zien.

Voor de teampagina is al een template aanwezig in docs-map van het startproject.