Natuurlijk, al diegenen die volgens het boekje (A)TDD doen en hun code voorzien van xUnit tests en SLIM/Fitnesse, Cucumber en bij elke build de volledige regressie test runnen zullen dit niet herkennen: soms doet het programma toch niet wat je eigenlijk zou willen. De meeste mensen noemen dat een defect, alhoewel de scheidslijn tussen een echte fout en nieuwe functionaliteit erg dun kan zijn.
Voor hen die dankzij (A)TDD en wat nog meer 100% correcte programma’s opleveren is dit artikelen weinig interessant. Voor hen die toch nog, ondanks al hun moeite en effort geconfronteerd worden met defects biedt dit artikel advies over hoe defects te schedulen. En, als lezer mag je ook stiekem toegeven er nog steeds fouten in de software zitten. Niemand zal het horen….
Defects kunnen zowel binnen als na de sprint gevonden worden. Bij die defects die binnen de sprint gevonden horen is het, als het bij een huidig backlog item hoort, nog gewoon bij het werk wat gedaan moet worden. Het maakt dan niet uit of we eerder dachten dat het item af was, voldeed aan de DoD en de reeds de zegen van de Product Owner heeft gekregen. Op zich is er nog niets aan de hand, als we tenminste nog niet geleverd hebben.
Het eenvoudigst werkt het als de ontwikkelaars ook degenen zijn die die fouten vinden. Vinden mensen buiten het team ze, of zijn het gespecialiseerde testers op een andere locatie, dan onstaat al snel de werkwijze om het in een defect tracking systeem op te slaan, met z’n bijbehorende lifecycle, overhead en deprimerende uitstraling. Liever niet, en een goede reden om aan kwaliteit te werken.
Vind je een fout vlak voor het einde? De Product Owner is uiteindelijk degene die aangeeft of hij wel of niet het backlog item goedkeurt, maar ik zou hopen dat de Scrum master de Product Owner stimuleert, of in ieder geval de optie geeft, om het item af te keuren. Dit is moeilijker dan op het eerste ogenblik lijkt, meestal willen we het toch nog net goed vinden. En dus maken we van de kleine foutjes een release note en een nieuw defect die we ooit nog eens gaan doen. Mocht de Product Owner het item niet afkeuren dan zou het alsnog een goed teken zijn als het team bij de volgende sprint planning minder inhoud accepteerd. Ook daar is als Scrum master een rol weggelegd om bij de sprint planning een spiegel voor te houden.
Maar nu, het product is geleverd en wordt door echte gebruikers in gebruik genomen, of wordt, in complexere omgevingen, door product testers onder handen genomen. En die vinden alsnog fouten. Ondanks alle moeite die we erin gestopt hadden om die fouten te voorkomen. Die defects horen op de product backlog thuis, net zoals al het ander werk dat gedaan moet worden.
Dat laatste wordt als lastig ervaren door teams die met User Stories, Story Points en Velocity werken. De velocity is bedoelt om de capaciteit in te schatten waarin nieuwe, waarde toevoegende, functionaliteit toegevoegd kan worden. En defects gaan dan weer over dingen waar we de punten al verwerkt hebben in onze berekening en ze voegen geen nieuwe functionaliteit toe.
Bij het klakkeloos op de backlog zetten van defects en ze net zo behandelen als andere user stories onstaat een moeilijker in te schatten plaatje, neemt de transparantie af. Het is alsof je afdrijft, de snelheid die je meet is niet de snelheid die je werkelijk hebt. Moet je dan maar voor elk item dat je op de backlog lijst zet alvast een een blokje defect fixing opnemen? Dat is wel de standaard praktijk bij veel plannings processen, maar daarmee red je het ook niet, je keurt als het ware goed dat er fouten in je software zitten.
Als je op een velocity gebaseerde plannings techniek gebruikt wil je dat de velocity die je meet, en dus gebruikt als voorspelling, af neemt. Dat is eenvoudig op te lossen door defects geen story points te geven. Als ze opgelost zijn leveren ze geen bijdrage aan de snelheid op.
Defects kosten natuurlijk wel tijd om op te lossen, maar daar is de sprint planning voor. De Product Owner selecteert de items van de backlog, maar het team geeft aan wat hun capaciteit is. En die wordt voor een sprint uiteindelijk berekend in uren die nodig zijn om de items te realiseren, niet in de punten die bij het item staan.
Voor de Product Owner zal dit helaas niet voldoen. Hij gebruikt die punten dus wel als voorspeller en hij zal toch vaak moeten aangeven wanneer het opgelost is en of het de planning in gevaar gaat brengen. Hij zal dus wel behoefte hebben aan een inschatting met story points, om zo te kunnen zien in welke sprint ze terecht gaan komen. Wel inschatten, maar niet meerekenen…
Maar dan klopt de velocity ook weer niet. We rekenen met een lagere snelheid omdat we weten dat we defects moeten gaan oplossen, maar die staan ook al in de backlog en dus rekenen we ze twee keer…
Niet alle defects zijn echter gelijk. Sommige zijn zeer urgent, vragen om actie op dit moment, andere zijn de kleine schoonheidsfoutjes, de dingetjes die net beter gekund hadden. De meesten zullen dus ook wel werken met een prioriteits systeem, zo heb ik ooit het MoSCoW systeem toegepast zien worden op defects, of krijgen ze een prioriteits indicatie met een getal. Als team en als Product Owner helpt dit niet veel, de hiervoor genoemde problemen blijven bestaan.
Bij elk defect moet uiteindelijk de afweging gemaakt worden “doen we het nu of doen we het straks“, geheel in lijn van Getting Things Done. Deze defects dragen dan niets bij aan de velocity. Bij een overvol sprint programma zal de capaciteit afnemen en kunnen niet alle items gedaan worden. Eigenlijk zou dat als resultaat moeten hebben dat de sprint gestopt wordt, maar ik ben nog geen team tegen gekomen wat dat daadwerkelijk doet.
Mocht je zoveel doe het nu defects hebben dat ze niet in je huidige sprint passen dan schuiven ze door naar de volgende, waardoor de velocity nog meer daalt, theoretisch tot het nul-punt. Een krachtig, maar niet zo leuk, signaal.
De Doe het straks hebben dezelfde status als de andere user stories. Wat dus betekent dat het product ook zijn waarde zou kunnen hebben zonder dat ze opgelost zijn. Ze worden, net zoals andere backlog items, gewoon ingeschat en op de backlog gezet. Mocht je veel meer doe het straks dan doe het nu defects hebben dan zou je, nadat je even tevreden bent over jezelf, de criteria kunnen aanscherpen over wat nu en straks betekend.
Los van hoe je ze inschat, blijf defects zien als afwijkend, iets waar je vanaf wilt. Als je ze gaat accepteren als gegeven dan zal je geen manieren meer gaan zoeken om ze te gaan voorkomen. En de meeste defecten kunnen met een lagere inspanning voorkomen worden dan dat ze opgelost moeten worden.
Eigenlijk is dat belangrijker dan defects correct in te plannen.
