De Definition of Done in Testen3.0

Een goede Definition of Done omvat méér dan alleen de exitcriteria voor de iteratie. Als voorproefje op ‘Testen3.0’ ditmaal een fragment over hoe je de Definition of Done optimaal inzet in jouw agile project.

Definition of Done
In de Definition of Done legt het team vast welke kwaliteitsstappen ze gaan uitvoeren om te komen tot een kwalitatief goede oplevering van een productierijp systeem. Dit principe geeft veel richting aan het werk van het team. Tijdsinschattingen worden hiermee nauwkeuriger en de opdeling van het werk wordt eenvoudiger doordat duidelijk is waar de oplevering aan moet voldoen. Ook worden verwachtingen bij de klant op deze manier expliciet gemanaged: de klant weet wat hij gaat krijgen. Namens de business is het niet alleen de product owner die criteria kan opleggen, waar iedere oplevering aan moet voldoen. Ook een beheerafdeling heeft doorgaans eisen die het team moet overnemen en zal incalculeren bij het inschatten van het werk. De Definition of Done is dus een product van het team en de klant samen!
De Definition of Done is ook mede bepalend voor de benodigde samenstelling van het team. Ontbreekt er een vaardigheid aan het team welke nodig is om alle stappen in de Definition of Done tot een goed einde te brengen, dan is dat een goede aanleiding voor het uitbreiden van het team of het (part time) toevoegen van expertise.
Indien een organisatie beleid heeft aangaande de inhoud van een Definition of Done, dan biedt dat een belangrijke mogelijkheid voor commercieel succes. De kwaliteit van het product kan en moet benadrukt worden, in plaats van de lage prijs waarvoor het wordt gerealiseerd.

Documentatie bij oplevering
De op te leveren documentatie moet onderdeel zijn van de afspraken omtrent de Definition of Done. Het team zal zelf een beeld hebben van de benodigde systeemdocumentatie; een beheerafdeling zal daar specifieke eisen aan stellen. Het is in elk geval noodzakelijk dat op het moment van oplevering de documenten up-to-date zijn met de realisatie van het product. Veel teams werken met gegenereerde systeemdocumentatie die bijvoorbeeld door het gebruik van labels in de code en in het versiebeheersysteem de wijzigingen en de release notes kunnen oplepelen. Doordat het een geautomatiseerd proces betreft, is het team er geen tijd aan kwijt, en worden er geen fouten in gemaakt (anders dan het achterwege laten van de labels). Uiteraard hoor je dat vooraf bij de klant te hebben gecheckt.
Een ander voor de hand liggend minimum om op te leveren, is in termen van de business een formulering van wat er “nieuw” in een release zit. Gelukkig biedt het Scrum proces daar een eenvoudige invulling voor: de lijst van alle user stories die voldoen aan de Definition of Done. Houd die lijst dus goed bij, en let er op dat de user stories zo veel mogelijk geformuleerd zijn in termen van de business. In feite is deze stap gegarandeerd als het team werkwijzen als ATDD (Acceptance Test Driven Development) of het specificeren met voorbeelden heeft ingericht en ingebed in de organisatie.

Vanuit testoogpunt is het belangrijk dat de opgeleverde testware leesbaar is voor alle betrokkenen. Dit is namelijk een valkuil voor veel teams: dat de programmeurs hun zaakjes goed voor elkaar hebben en de code volledig in source control hebben, en dat de testware achter blijft.

Lagen in de Definition of Done
Er zijn ten minste drie lagen of niveaus te onderscheiden in een goede Definition of Done: story, iteratie, en release. Op het laagste niveau, dat van de losse user stories (brokjes functionaliteit), geeft de Definition of Done aan welke stappen het team onderneemt om een story te bouwen en te testen. Denk daarbij bijvoorbeeld ook aan het variëren van de diepgang van een test op basis van de productrisicoanalyse.
Op het niveau van de iteratie komen daar nog een aantal criteria en activiteiten bij. Denk op dit niveau bijvoorbeeld aan het produceren van bijgewerkte systeemdocumentatie, een installatiehandleiding, en een limiet op het aantal openstaande bevindingen. Immers, aan het einde van de iteratie levert het team een potentieel productierijp systeem op.
Wanneer een team een iteratie afrondt in de wetenschap dat de organisatie de intentie heeft om met het resultaat van die iteratie naar productie te gaan, dan worden er veelal nog een aantal aanvullende stappen genomen. Voorbeelden daarvan zijn: performance tuning, het schrijven van instructies voor de eindgebruikers, en het oefenen van de beschreven installatieprocedure.

Kwaliteit leveren
Een team dat een duidelijke Definition of Done heeft geformuleerd en kan naleven, heeft daarmee veel grip op het eigen proces. In de ogen van het management is dat ronduit geweldig: het team levert herhaalbare kwaliteit en geeft realistische tijdsinschattingen. Dergelijk succes is prima verkoopbaar, en vormt de basis voor het hebben van een uitstekende relatie met de opdrachtgever.

In juni geeft Eric een presentatie op de Better Software / Agile Development Practices conferentie in Las Vegas. Van die presentatie (The Value of Defining ‘Done’) is ook een fragment te zien, via deze link.

Over ericjimmink

Eric Jimmink is een testconsultant met een achtergrond als ontwikkelaar / meewerkend voorman. Zijn eerste agile project was al in 2001. Eric geniet bekendheid als co-auteur van het boek 'Testen2.0', als schrijver van artikelen over agile testen, en door het geven van presentaties. Momenteel is Eric bezig met 'Testen3.0', waarvan enkele fragmenten geplaatst worden op de AgileOrdina blog.
Dit bericht werd geplaatst in Agile ontwikkelen, Agile Testen, Presentaties, Testen3.0 en getagged met , , , , , , , , , , , , , , , , , , , . Maak dit favoriet permalink.

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit / Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit / Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit / Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit / Bijwerken )

Verbinden met %s