Agile op Maat

Onlangs kreeg ik via LinkedIn een vraag gesteld over de
(on-)zin van het registreren van bevindingen in een Agile project. 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!

Door Anko Tijman
---
Lees ook het volgende artikel als je geïnteresseerd bent in Agile en defect scrumboard.

Onlangs heb ik James Bach, bedenker van Context Driven Testing, gehoord over software testing (testnet meeting 18 januari j.l). Hij heeft mij op een bijzonder wijze geïnspireerd. Op dit moment ben ik bezig om zijn youtube filmpjes te verslaan. En ik moet zeggen ik word hier erg enthousiast van.

James Bach is een mislukte scholier, zegt hij zelf ook in een van zijn filmpjes maar via Apple heeft hij zich toegelegd op het testen van software en hij doet dat op een enthousiaste wijze. Als James Bach in een testteam zit stelt hij zelfs de requirements aan de kaak. Hij gaat niet zo maar testen. Hij heeft bij elk requirement minimaal één maar waarschijnlijk meerdere vragen. Zo is hij tot het Context Driven Testing gekomen. (meer...)

Ken je dat gevoel? Kom je binnen als projectmanager, krijg je een zelfsturend team die het werk doet. Maar wat moet jij dan doen? Met een beetje mazzel speelt ook al iemand de rol van Scrummaster, dus blijft er niet veel over. Dan ga je je maar bezighouden met de besturing van de inputzijde, want de Product Owner heeft te weinig tijd en, voor je het weet, ben je een proxy Product Owner. Dan heb je niet de besturing terug gekregen, maar zit je eigenlijk op de stoel van de opdrachtgever. (meer...)

Waar gaat het om bij het inzetten en maken van ICT hulpmiddelen: dat ze gebruikt worden. Als ze niet gebruikt worden leveren ze geen rendement op, sterker nog het zit alleen maar in de weg. Maar al te vaak kom ik hele mooie (standaard) ICT-producten tegen die niet gebruikt worden in de organisatie. Met ambitieuze plannen is de organisatie gestart, maar het landt gewoonweg niet. Een belangrijk probleem is dat mensen die met de oplossingen moeten werken het niet in hun huidige werk kunnen plaatsten. Een training of handboek is leuk, maar dat is niet genoeg. (meer...)

Na de inspirerende woorden van Agile Manifesto schrijver Arie van Bennekum over “10 jaar Agile Manifesto… en wat nu?” op 7 december bij Ordina was er keuze uit 3 tracks met uiteenlopende onderwerpen, verzorgd door Ordina consultants.

De presentatie  over organisatieopstellingen “Creëer een voedingsbodem voor Agile transformatie” (van Remi-Armand Collaris en Rik Hurkmans) kun je hier bekijken.
As je wil na wilt zoeken waarom de Agile manier van werken goed aansluit op het Rijnlandse model (volgens Patrick van Burgel) dan kun je die hier vinden.Van de track om spelenderwijs tot betere (agile!) contractvoorwaarden te komen (door Dick van der Sar) zijn deze slides beschikbaar. (meer...)

In een waterval ontwikkeltraject is in detail uitgewerkt ontwerpdocumentatie een belangrijke vereisten om met bouw en test te kunnen starten. Binnen een agile traject niet, want het Agile Manifesto zegt het volgende over documentatie:  “We value working software over comprehensive documentation”, of te wel “Wij waarderen werkende software boven uitgebreide documentatie”. Vanuit dit principe is er een spanningsveld tussen ontwerpen in traditionele omgeving en ontwerpen in een  agile omgeving. Dit artikel beschrijft  hoe je als team hiermee om kunt gaan. (meer...)