Voorbeelden van een Definition of Done

Regelmatig wordt ons gevraagd om voorbeelden te geven van een Definition of Done. In een Definition of Done worden exit- en acceptatiecriteria van een story, een iteratie of een release samengevat. In een eerdere blog post hebben we aangeven, dat in onze visie en ervaring een Definition of Done meerdere niveaus behoort te onderkennen voor de activiteiten. In dit artikel leggen we uit hoe je dat in de praktijk kunt vormgeven.

Een Iteratie wordt afgesloten met een potentieel productierijp systeem; alle stappen in het proces van softwareontwikkeling moeten “in een keer goed zijn” om dat te kunnen garanderen. Daarom is het goed om exact te weten wat de eindstaat moet zijn. In zo’n iteratie worden meerdere user stories (demonstreerbare brokjes functionaliteit met waarde voor de klant) gerealiseerd, welke kunnen worden opgedeeld naar taken. Het Taak-niveau is optioneel en bijzonder. Een team zal dit in de regel gebruiken om het werk te verdelen over personen. Een taak staat in dienst van het voltooien een story; als zodanig zijn de resultaten van een taak zijn niet noodzakelijk toonbaar in termen van business value. Wel moet geëist kunnen worden dat het getest c.q. verifieerbaar correct is uitgevoerd.

Hoewel iedere iteratie wordt afgesloten met een potentieel productierijp systeem, is het mogelijk dat het team toch aanvullende stappen wil ondernemen wanneer de business daadwerkelijk de intentie heeft om met een Release naar productie te gaan.

De Definition of Done bevat handvatten om op ieder niveau te kunnen controleren of het werk correct is uitgevoerd. In de tabel hieronder staat een voorbeeld van hoe dat er uit kan zien:

De uitvoer is parallel
De opdeling van de Definition of Done in verschillende lagen versterkt de werking van het principe van werken naar eindstaten toe. Je begint met het einde in zicht. Als er werk gedaan moet worden bovenop het “Done” krijgen van de afzonderlijke stories, dan is het de bedoeling dat alle aspecten van de Definition of Done wel degelijk parallel worden gerealiseerd. Uitvoer van de verschillende controles mag zo min mogelijk op elkaar wachten, het moet geen mini waterval worden.
De Definition of Done zal met het team meegroeien. Men kan de Definition of Done interpreteren als een checklist, die het huidige niveau (qua ambitie, en technische volwassenheid) van het team weergeeft.
In de ideale situatie heeft het team alles zo goed onder controle, dat de correctheid op een willekeurig moment aangetoond kan worden, en men in feite ook op ieder gewenst moment een release kan uitbrengen naar productie. Het groeiproces naar zo’n ideale situatie zal later worden besproken.

Het opstellen van de Definition of Done
Het moment waarop de Definition of Done wordt opgesteld is: zo vroeg mogelijk. Het liefst voordat het budget is vastgesteld, want dan kan de realisatie van de beoogde kwaliteit nog meegerekend worden.  Bedenk dat er in dat stadium vaak nog geen team is geformeerd. Dat houdt weer in dat er hooguit sprake kan zijn van een voorlopige Definition of Done. De uitvoerenden werken dit nader uit door gesprekken te voeren met de belanghebbenden van de business. Naast de product owner betreft dat in het bijzonder ook de beheerders, omdat deze laatste groep doorgaans richtlijnen stelt voor het in gebruik c.q. in beheer nemen van systemen.

Wanneer een organisatie het opstellen van de Definition of Done een aantal malen heeft uitgevoerd, dan is de logische volgende stap om de geleerde lessen om te zetten in beleid. Zo kan er gewerkt worden vanuit een gezamenlijk kader van kwaliteit. En met dat kader kan men naar buiten treden – bijvoorbeeld door de kwaliteit van een product te benadrukken in plaats van de prijs waarvoor het wordt gerealiseerd.

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, Algemeen, Implementatie van agile 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