Werkwijze
Werken in een (scrum) team
In dit project hebben we gewerkt in een scrum team. Het leek mij persoonlijk een goed idee om dit project te tackelen in een team, niet alleen vanwege de omvang van het project maar ook vooral om te leren hoe je zo'n project van A tot Z op zet in een team.
De workflow
Voor het project heb ik in samenwerking met m'n teamgenoten een (soort) scrum workflow geprobeerd op te zetten. Zo hebben we gebruik gemaakt van GitHub projects als een soort scrum board waarbij de issues die we konden inschieten fungeerde als tickets die opgepakt konden worden.
Elke dag hadden we 's ochtends als team een stand-up om de dag door te nemen. Als we het nodig achtten hadden we ook aan het eind van de middag een korte stand-up om het werk van de afgelopen dag door te nemen. Dit maakte, in samenwerking met het overzichtelijke project board, dat we allemaal van elkaar precies wisten waar we aan bezig waren.
Elke week een sprint
Om afbakening te vinden in de tickets die we inschoten en omdat we sowieso elke week een meeting hadden met de opdrachtgever heb ik besloten om dan ook elke week als een sprint te zien. Zo konden we enerzijds aan de opdrachtgever 'makkelijk' uitleggen wat we de afgelopen week hebben gedaan en wat we die week daarop zouden gaan doen. Anderzijds hielp het ons om alles af te bakenen en prioriteiten te stellen in de tickets die op de backlog stonden.
Kwaliteit hoog houden
Om de codekwaliteit van het project hoog te houden en om de ontwikkeling van ons allemaal te stimuleren stond ik erop dat we het project netjes oppakten door te werken met branches, pull requests en code-reviews. De master branch was dan ook afgezonderd om direct code op te pushen.
Elke feature die gebouwd moest worden had dus z'n eigen issue met zogenaamde acceptance criteria (wanneer is dit ticket af?). Voordat iemand aan een feature begon te werken diende diegene een branch aan te maken als feat/my-feature.
Vanuit die branch kon je dan gaan bouwen aan de feature om, wanneer de feature af is, een pull request in te schieten. Een andere teamgenoot keek dan vervolgens de code en het prototype na waarna er feedback werd gegeven. Door dit te doen blijf je allemaal scherp en hou je de (code) kwaliteit van zo'n project hoog.
Last updated