Wat is een code review retrospective?
Een code review retrospective is een overleg waarin je team kijkt naar hoe het code reviewt, niet naar de code zelf. Pull requests die dagenlang blijven liggen, opmerkingen zonder context, reviews die alleen naar de stijl kijken: zulke problemen komen zelden ter sprake in een gewone sprintretro, omdat ze over ieders week verspreid zijn en niet aan één gebeurtenis vastzitten. Het bord heeft vier kolommen. "Wat gaat goed?" verzamelt de reviewgewoonten die je wilt behouden, zoals een handige checklist of een respectvolle toon. "Wat gaat niet goed?" gaat over de knelpunten, van te grote pull requests tot standaarden die per persoon verschillen. "Wat kunnen we verbeteren?" maakt daar concrete veranderingen van, zoals een maximale omvang voor wijzigingen of een afgesproken reactietijd. "Welke vragen zijn naar boven gekomen?" parkeert de open vragen die het team eerst moet uitzoeken voordat het een besluit kan nemen. Houd deze retro na een grote release, wanneer trage reviews de oplevering beginnen op te houden, of wanneer er nieuwe mensen bij komen en de ongeschreven reviewstandaarden van het team op papier moeten. Houd het blameless: het onderwerp is het proces, niet iemands opmerkingen bij een bepaalde pull request.
Format voor de code review retrospective
Wat gaat goed?
Wat werkt er goed in onze code reviews?
Begin met wat werkt. Vraag naar concrete reviewpraktijken die geholpen hebben en geef erkenning aan mensen wier reviews het verschil maakten.
Wat gaat niet goed?
Tegen welke problemen of knelpunten liepen we aan bij code reviews?
Zorg dat mensen problemen kunnen benoemen zonder iemand de schuld te geven. Vraag om concrete voorbeelden, zoals een review die dagen duurde of een opmerking waar je weinig mee kon.
Wat kunnen we verbeteren?
Hoe kunnen we ons code reviewproces en onze werkwijze verbeteren?
Vraag om concrete, uitvoerbare voorstellen. "Betere reviews" is geen actie; "pull requests opsplitsen die meer dan één feature raken" wel.
Welke vragen zijn naar boven gekomen?
Welke nieuwe vragen of onderwerpen om verder uit te zoeken kwamen op?
Schrijf de vragen op die het team vandaag niet kan beantwoorden en spreek af wie elke vraag vóór de volgende retro uitzoekt.
Wanneer dient u deze retrospective te gebruiken?
- Wanneer reviews de oplevering vertragen of voor wrijving zorgen en je wilt weten waarom.
- Wanneer je wilt dat developers de reviewpraktijken delen die voor hen werken.
- Na grote releases of projecten, om te kijken hoe de reviews standhielden onder druk.
- Wanneer er nieuwe mensen bij komen en het team afspraken moet maken over reviewstandaarden, verwachtingen en reactietijden.
Voorstellen voor ijsbrekers
- Wat is de interessantste code die je onlangs hebt gereviewd?
- Als je één functie aan je code-editor kon toevoegen, welke zou dat zijn?
Wilt u een opwarmoefening waarbij uw team daadwerkelijk meedoet, en niet alleen hardop antwoorden geeft? Bekijk gratis ijsbrekers →
Ideeën en tips voor uw retrospectievevergadering
- Houd de discussie vrij van schuld, zodat mensen eerlijk durven te zijn over reviews die ze lastig vonden.
- Geef naast de problemen ook erkenning voor goed reviewwerk, zoals heldere opmerkingen of een snelle reactie.
- Betrek iedereen die code schrijft of reviewt, ook testers.
- Spreek één of twee concrete veranderingen af in plaats van een lange lijst goede voornemens.
- Volg de actiepunten op en houd de voortgang bij in je volgende retrospectives.
- Laat de facilitatorrol rouleren, zodat verschillende perspectieven de discussie leiden.
Veelgestelde vragen
Wat is een code review retrospective?
Wanneer houd je een code review retrospective?
Welke vragen stel je in een code review retrospective?
Hoe lang duurt een code review retrospective?
Wat is het verschil met een sprintretrospective?
Gerelateerde sjablonen
Ontdek waarom bugs ontstaan en voorkom dat ze terugkomen
DevOps-retrospective
Evalueer deployments, incidenten en overdrachten tussen dev en ops.
Retrospective technische schuld
Vind, rangschik en los je technische schuld planmatig af
Retrospective Productontwikkelingsproces
Kijk verder dan sprints en evalueer hoe je producten bouwt.