Ook wij maken fouten. Sommige bugs overleven unit tests, code reviews en de acceptatie-test door de klant. En precies die bugs komen tevoorschijn als je als developer met een totaal ander project bezig bent. Hoe ga je daarmee om?
Twee principes voor het omgaan met bugs:
1) Personal responsibility
Robert C. Martin zegt in 97 Things Every Programmer Should Know:
The single most important trait of a professional programmer is personal responsibility. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their work- manship. A professional programmer does not pass that responsibility off on others.
Oftewel, je fixt je eigen bugs.
2) Volledige focus op huidige sprint
Scrum leert dat een team zich ongestoord moet kunnen concentreren op de huidige sprint, en alleen bezig moet zijn met wat bijdraagt aan het sprintdoel. Dus geen bugs fixen die niet op de backlog staan.
Designated Developer
Welke van deze twee principes geeft de doorslag? Wij hebben gekozen voor de tweede. Bij ons is er altijd een DD-er. Een Designated Developer. Iemand die vrijgemaakt is om allerlei soorten technische hulp te bieden, zoals:
- bugs oplossen
- kleine aanpassingen doen
- simpele imports
- inschattingen van de kosten van uitbreidingen
- uitzoeken waarom iets op een bepaalde manier werkt
De DD-er werkt nauw samen met de internet consultants die support leveren. Op die manier kunnen we snel technische support bieden zonder dat developers voortdurend gestoord worden.
Iedereen is af en toe DD-er. Zo krijgen we toch nog iets van de waarde van het eerste principe mee. We zien onze eigen fouten en die van onze collega's. Als we DD-er zijn mopperen we geregeld op de domme en onnodige bugs. Maar stiekem zijn we best trots op het feit dat één DD-er voldoende is om de fouten van zo'n 20 scrum developers te fixen :-).