Definition of Done: Simpel en toch complex
De Definition of Done (DoD) is een belangrijk agile instrument dat teams helpt om werk te plannen en uit te voeren. In principe is de Definition of Done niets meer dan een reeks criteria waaraan het product moet voldoen om als af te worden beschouwd. Maar hoewel het concept zo eenvoudig klinkt, is de uitvoering in de praktijk niet altijd even simpel. De context en de verschillende interpretatiemogelijkheden zorgen namelijk voor een grijs gebied.
Context en acceptatiecriteria
Het eerste niveau van complexiteit bestaat eruit dat de Definition of Done altijd in de context van de omgeving moet worden gezien, wat betrekking heeft op de technische en functionele volledigheid en de acceptatie door de Product Owner . Het feit dat de Product Owner het product accepteert, staat symbool voor de waarde van het product. Acceptatiecriteria – of hoe ze ook genoemd mogen worden – weerspiegelen of de code een bepaald bedrijfsprobleem kan oplossen dat door de User Story of een requirement is gedefinieerd. Acceptatiecriteria moeten bevestigen dat de Story werkelijk doet waarvoor ze bedoeld was, en ze kunnen worden gebruikt voor het opstellen van acceptatietests.
Formeel gezien is de Definition of Done vaak een weerspiegeling van de technische en procesgerelateerde standaarden van een organisatie. Organisaties hebben bijvoorbeeld vaak standaarden voor het schrijven van code en unit tests, en daarom kan de Definition of Done eisen bevatten voor de structuur van de code, de documentatie en het testen. Ze kan ook componenten bevatten die met functionaliteit te maken hebben. De functionaliteit is echter in principe al opgenomen via de acceptatiecriteria in de definitie. In sommige gevallen heb ik al uitspraken in de Definition of Done gezien die aangeven dat de acceptatiecriteria moeten worden nageleefd. Nadat de dubbele horde van Definition of Done en acceptatiecriteria is genomen, moet de Product Owner de beoordeling van de geleverde waarde van de oplossing geven. Daarna volgt de finale beoordeling, waarbij hij de oplossing accepteert of afwijst. Het resultaat van dit proces wordt ook wel beschreven als done-done of zelfs done-done-done.
Drempels en belangrijke vragen bij de DoD
Om het concept van "Done" op een solide manier toe te passen, moet je drie horden overwinnen: de criteria van de Definition of Done, de acceptatiecriteria (als onderdeel van een User Story) en de acceptatie door de Product Owner. Daarnaast hoort daar ook het afwegen van een aantal vragen bij, die het anders relatief eenvoudige proces wat lastiger maken. Denk hierbij aan:
Wie beslist wat Done betekent?
In veel organisaties worden de Done-criteria vaak aan de individuele teams overgelaten. Dat gebeurt meestal binnen de grenzen van de technische en procesmatige standaarden die door de organisatie zijn vastgesteld. Een paar jaar geleden werd ik bijvoorbeeld door een ontwikkelteam met strenge standaarden voor coding en unit tests gevraagd of ze de unit-testvereisten voor hun code mochten weglaten. Unit tests waren een criterium in hun Definition of Done. Hun redenering was dat de testers later in het proces wel zouden ontdekken of het werkt, en dat de Product Owner de tests van de programmeurs niet op prijs stelde. Het team moest zich echter houden aan de door de organisatie vastgestelde standaarden, en het was geen optie om de vereisten voor unit tests zomaar weg te laten.Is het acceptabel als de criteria niet volledig worden vervuld?
Elk team waarmee ik ooit heb gewerkt, heeft zich vroeg of laat de vraag gesteld of het oké zou zijn om de Definition of Done anders te interpreteren en zo te omzeilen. Vaak is het antwoord "Ja". Dat betekent echter meestal een discussie over het grijze gebied, het accepteren van technische schuld en wanneer die schuld moet worden ingelost.Kunnen de behoeften van de organisatie belangrijker zijn dan die van de Product Owner?
Dit is het alter ego van de vorige vraag. Iedereen in het team, inclusief de Product Owner, moet weten wanneer en waar de standaarden en/of behoeften van de organisatie belangrijker zijn dan de acceptatie door de Product Owner. De druk om te moeten leveren kan teams en Product Owners ertoe verleiden om de code door te drukken, om die dan in latere Sprints te herwerken, waardoor de standaarden en de architectuur onder druk komen te staan. De meeste volwassenere organisaties trekken duidelijke grenzen, zodat iedereen weet wanneer de behoeften en standaarden van de organisatie gerespecteerd moeten worden.
Conclusie over de Definition of Done (DoD)
Alle definities van het woord "Done" bevatten een zekere mate van definitief en volledig zijn. Bij softwareontwikkeling, -verbetering en -onderhoud kan het concept van Done zeer gelaagd zijn. Elk van deze lagen kan zijn eigen technische, functionele en waardegerelateerde nuances hebben. Teams leren al snel dat werk echt done, done en done moet zijn om daadwerkelijk af te zijn.
Deze tekst is afkomstig uit de blog van SPaMCAST en is door ons naar het Nederlands vertaald.
