“Elke sprint een beetje beter”

Vandaag een blog over het samenwerken met Guapa. We zijn inmiddels al een geruime tijd bezig met onze SCRUM-methodiek en ik wil deze vandaag graag toelichten. Dit om een beter beeld te geven van onze manier van werken.

Voorbereiding

Een goed project zal altijd voorbereiding nodig hebben. Vaak is de klant al een tijd bezig met het nieuw te bouwen platform voordat ze bij ons aankloppen. Er is al een wensen- en eisenlijst met een globaal beeld van het nieuwe platform. Om dit te verfijnen zal er eerst een zogenaamde “backlog refinement” sessie plaatsvinden. In zo’n sessie worden de wensen en eisen omgezet naar een backlog voor het project. De globale omschrijvingen worden omgezet in User Stories met een duidelijke omschrijving en opgeknipt in behapbare blokjes werk die later door de developers ingeschat kunnen worden. Er wordt ook een MVP (Minimal Viable Product) vastgesteld waar we samen naartoe kunnen werken. Dit MVP is natuurlijk niet in beton gegoten, want er kunnen in de loop van het project, op basis van inzichten, nog wensen zijn die een hogere prioriteit krijgen.

Scrum Poker

Met de aangemaakte backlog kunnen we vervolgens als developers aan de slag. Er worden inschatting sessies met de klant ingepland en tijdens deze sessies gaan we met meerdere developers scrum pokeren. De eerder gemaakte User Stories worden op volgorde van prioriteit tijdens deze sessies besproken. De stories worden hier nog opgeknipt in subtaken die los ingeschat kunnen worden.

Met kaarten zoals hiernaast afgebeeld mag elke developer voor zichzelf bepalen hoe lang hij met de besproken taak bezig denkt te zijn. Als er grote verschillen in inschattingen zijn kunnen we samen overleggen waarom een bepaalde ingeschatte tijd nodig zal zijn voor een taak. Door hier van te voren goed over na te denken en de uit te voeren taak goed te omschrijven kan elke developer de taak op een later moment in de sprint oppakken.

Omdat de backlog constant bijgevuld wordt blijven inschatting sessies doorlopend gehouden worden. Het is essentieel voor de inschatting sessies dat de klant, als onderdeel van het team, hier ook bij aanwezig is. Hierdoor kunnen vragen die ontstaan tijdens het bespreken van de user stories direct besproken en afgevangen worden.

Sprinten

We werken in 2 wekelijkse iteraties, genaamd sprints. Elke sprint begint met het doorlopen van alle taken die klaarstaan voor de betreffende sprint tijdens de sprint planning. Hierdoor is het gehele team op de hoogte van de taken die in de sprint zitten en de mogelijke bijzonderheden. Alle taken staan op dit moment ingeschat en wel klaar bovenaan de backlog en de sprint kan worden gestart na dit moment. Dit is het startschot voor 2 weken ontwikkelen.

Ontwikkeling

Alle taken die op het scrumboard staan kunnen vervolgens opgepakt worden door het development team. Een developer begint aan een taak en gaat aan de slag om deze klaar te zetten voor de tester. Mochten er tijdens het ontwikkelen vragen ontstaan dan kan hij altijd terecht bij de consultant van het project, of bij de product owner van de klant. De developer test zijn eigen werk en kan het vervolgens bij SonarQube aanbieden.

SonarQube

Dankzij SonarQube kan de code die ontwikkeld is direct gecontroleerd worden op vooraf ingestelde regels. SonarQube is een systeem wat geautomatiseerd code quality checks uitvoert. Hierover heeft Johan eerder een blog geschreven, klik hier om deze te lezen.

Test

Indien de SonarQube controle is geslaagd kan de ontwikkelde feature klaargezet worden op de testomgeving. Op basis van een testrapport dat is klaargezet door de developer die de ontwikkeling heeft gedaan kan de tester vervolgens de feature doortesten op de diverse hardware (tablet, android telefoons, iPhones en de verschillende desktop en laptop resoluties) en software (Google Chrome, FireFox, Safari en Edge).

Quality Review

De geteste feature staat na een geslaagde test klaar voor de lead developer van een project om te controleren. Deze lead developer zal vervolgens controleren of de kwaliteit van de code voldoet aan de standaarden en of de meest efficiënte en correcte code is gebruikt.

Consultant test

Wanneer de development flow is voltooid komt de user story klaar te staan voor de consultant van een project. De consultant test als laatste of de story voldoet aan alle eisen van de klant. Als de taak ook hier akkoord is bevonden, dan wordt hij klaargezet in de release van deze sprint.

Release naar Acceptatie

Alle taken die door de bovenstaande flow heen zijn gekomen worden samengevoegd in een release naar de acceptatieomgeving van de klant. De lead developer voegt alle zogenaamde feature branches (elke story wordt in een eigen aftakking gemaakt zoals getoond op onderstaande afbeelding, zodat deze ook per stuk toegevoegd kan worden aan een release) toe aan de nieuwe versie van de acceptatieomgeving en zet deze klaar op die omgeving.

Acceptatie

Na deze release kan de klant de nieuwe features testen op de acceptatieomgeving. Dit is een moment waarin feedback verzameld kan worden of waarop de taken kunnen worden geaccordeerd voor een livegang. Van de verzamelde feedback worden taken klaargezet voor een volgende sprint en de taken die goedgekeurd zijn worden weer klaargezet voor de lead developer.

Feedback

Voor alle taken waarop feedback is gekomen staan worden specifieke feedback taken aangemaakt waarin duidelijk omschreven staat wat er nog toegevoegd zou moeten worden voordat de story klaar is om live te gaan. Deze feedback gaat ook nog los door bovenstaande flow heen, zodat de kwaliteit van de feedback gegarandeerd kan worden.

Live

Indien er geen feedback was op de taken dan kunnen de gemaakte features allemaal doorgezet worden naar de live release, anders dan zullen alleen de features die al helemaal af zijn meegaan met de live release. Deze wordt met de klant ingepland en klaargezet. Indien een project net begonnen is dan zal er eerst meerdere sprints ontwikkeld worden voordat versie 1.0 (MVP) live gezet zal worden. De inhoud van versie 1 is geheel te bepalen door de product owner. Een van de voorbeelden van een klant die op deze manier met ons samenwerkt is A Little Lovely Company, over deze samenwerking heeft Robbert ook een blog geschreven.

Retrospective

Als afsluiting van elke sprint hebben we als team een retrospective waarin we kunnen terugkijken op de werkzaamheden van die sprint. Deze retrospectives kunnen ook gehouden worden met het team van de klant. Hierdoor kunnen we direct feedback krijgen over de voortgang, algemene werkzaamheden en kijken wat we de volgende sprint nog weer beter kunnen doen. Dit is ook het doel van SCRUM werk, elke sprint ontdekken waar nog verbeterpunten zijn. Dit geldt dan zowel voor de werkwijze als voor het project.

Demo


Tijdens de retrospective is er ook een demo moment waarin nieuwe features gedemonstreerd kunnen worden. Hierdoor weten we ook allemaal wat we allemaal kunnen maken en deze kennis kunnen we dan weer inzetten bij de andere projecten.

Praise

Als afsluiter van de retrospective hebben we het “beker” moment. Tijdens dit moment mag de huidige houder van de praise-beker deze beker doorgeven aan een nieuwe eigenaar met een toelichting waarom deze persoon de beker heeft verdiend.

Wil je meesprinten?

Vind je onze werkwijze zo interessant dat je graag mee wilt sprinten als collega of klant? We hebben genoeg openstaande vacatures, check hiervoor deze link. Wil je als klant meewerken in ons scrumteam, neem dan gerust contact op.