ORDINA BLOGT

Tussen noodzaak en verspilling: bevindingen registreren in Agile projecten

Onlangs kreeg ik via LinkedIn een vraag gesteld over de (on-)zin van het registreren van bevindingen in een Agile project.

  • Anko Tijman
  • 26 maart 2012

Noodzaak-vs-verspilling

Voor testers is het vastleggen van bevindingen namelijk noodzaak, terwijl het soms door agilisten wordt gezien als verspilling.  ‘Moet het nu wel of moet het niet?’luidde de vraag. Omdat er geen eenduidig Ja of Nee op te geven, zal ik een aantal overwegingen op een rijtje zetten.
 

Waarom het registreren van bevindingen noodzakelijk is

Vanuit het perspectief van de tester is de wereld van bevindingen eenvoudig: je moet bevindingen eenduidig kunnen reproduceren,  hertesten en kunnen afsluiten. Daarnaast is een sluitende administratie een must om een rapportage te kunnen draaien en de stakeholders inzicht te kunnen geven in de status van het project. Daarnaast is dit een middel om metrics te verzamelen om later in het traject betere voorspellingen te kunnen doen. Ook vanuit het perspectief van de klant kan het noodzakelijk zijn om bevindingen vast te leggen, bijvoorbeeld wanneer er tijdens het project door verschillende gebruikersgroepen getest wordt.

 

Waarom het registreren van bevindingen verspilling is

Wanneer je als Agile team bij elkaar op de kamer zit en nauw samenwerkt met elkaar en de primaire voortgang van het project wordt bijgehouden middels het scrumboard (link), waarom dan juist bevindingen registeren in een of andere vreemdsoortige tool waar -behalve testers- niemand zijn weg in kan vinden? Je zit naast elkaar, je praat met elkaar en simulatie is zo gedaan. Less is more.
 

De middenweg

Ja, die is er! J. Het hangt namelijk van jouw projectteam af, hoe je bevindingen registreert. Want niet registreren is vaak geen optie, maar omslachtig vastleggen frustreert het Agile proces. Hierbij een aantal principes uit de praktijk:
 
1)      Een bevinding mag nooit vergeten worden. Dat houdt dus in dat alleen wanneer een ontwikkelaar een bevinding hetzelfde dagdeel nog oplost, het wellicht niet noodzakelijk is het formeel vast te leggen. Maar in alle andere gevallen dus wel.
 
2)      Registeren betekent niet altijd een tool gebruiken. Als post its in het project voldoen voor user stories, waarom dan bugs niet? Voor sommige bugs is dus een post it voldoende. Maar voor andere bugs is dat dus niet het geval. Dan is het juist van belang dat de genomen stappen reproduceerbaar zijn
 
3)      Zorg dat een bevinding makkelijk te reproduceren is. Anders heb je hem namelijk voor niets geconstateerd. Er zijn al teams die bijvoorbeeld filmpjes opnemen van bevindingen (bijvoorbeeld met behulp van Jing).
 
4)      Een bevindingen tool gebruiken betekent niet altijd het volledige traditionele beslissingsproces doorlopen. Wanneer het beslissingsproces van een bevinding is opgesteld met een groot watervaltraject in het achterhoofd dan zullen er waarschijnlijk veel stappen in zitten die voor een Agile team overbodig zijn. Teamleiders die bugs moeten beoordelen, Change Advisory boards die wensen moeten beoordelen… in een Agile team zit je dicht bij elkaar en liggen verantwoordelijkheden laag dus dan is dat procesmatige overkill.
 
5)      Zorg bij gebruik van een tool dus voor een lean bevindingenproces. Aanmaken, toewijzen, hersteld melden, hertesten en afsluiten moeten weinig inspanning kosten. Ga uit van de happy flow in het proces, bouw geen procesmatige blokkades in  maar biedt opties aan– dat scheelt het team veel kostbare tijd. Bij uitzonderingen kun je dan uitwijken en laat de uitzondering niet de regel beheersen.
 
6)      Maak een test die borgt dat de fout niet opnieuw kan optreden. Veel teams schrijven eerst een (falende) geautomatiseerde test om de fout te reproduceren en herstellen daarna de code zodat de test weer slaagt. Zo voorkom je situaties waarin het testen van een reeds opgeloste bevinding geen bevredigend resultaat oplevert. Tevens is daarmee de fout gedocumenteerd (geregistreerd) in de code.
 
Voor ieder projectteam zal de afweging hoe bevindingen te registreren anders zijn. Soms gelden er natuurlijk wel organisatorische afspraken. En soms moeten die worden herzien. Waar het om gaat is dat iedere discipline zijn werk goed moet kunnen doen: bevindingen oplossen, hertesten, rapporteren. De waarheid ligt vaak ergens rond het midden. We horen graag jullie ervaringen!

 

Over de auteur:

Anko Tijman

Anko Tijman is Thought Leader Agile bij Ordina. Vanuit die rol neemt hij het voortouw in inhoudelijke discussies over Agile, DevOps en Lean werken. Hij is sinds 2004 in dienst van Ordina. Hij is onder meer betrokken bij AgileOverheid, is Computable Expert en is trainer van de Agile-managementtraining Management3.0.