Sharing IT Best Practices with youSharing IT Best Practices with you
Wanneer is het klaar? Deze vraag is moeilijke te beantwoorden als niemand het eens is over wat ‘klaar’ precies is. Het is van cruciaal belang om overeenstemming te bereiken over wat wij de “Definition of Done” noemen. Het bereiken van een consensus over wanneer projecten en functies daadwerkelijk zijn voltooid. En dit geldt niet alleen voor Agile-SCRUM.
Het begint allemaal met een gemeenschappelijk vocabulaire – als mensen niet dezelfde taal spreken, is er voldoende ruimte voor verwarring en frustratie. Om dit scenario te vermijden, moeten gebruikers de tijd nemen om samen met hun technische tegenhangers af te spreken wat we in verschillende gevallen als “done” beschouwen.
De Defination of Done (DoD) is een lijst met items, die we gebruiken om een User Story te valideren. Deze lijst moet ervoor te zorgen dat het ontwikkelteam het onderling eens is over de kwaliteit van het werk. Het dient als een checklist die wordt gebruikt om elk Product Backlog Item (ook bekend als PBI) of User Story op volledigheid te controleren. Items in de Definition of Done zijn van toepassing op alle items in de Product Backlog, niet op slechts één User Story. We kunnen dit als volgt samenvatten:
De Definition of Done kunnen we consequent toepassen en dient als een officiële poort die dingen scheidt van ‘in uitvoering’ tot ‘Done’. Hoewel de details per organisatie verschillen, bestaat een typische Defination of Done uit een checklist met items zoals:
Ieder bedrijf zal zijn eigen variant bedenken, maar iedereen heeft hetzelfde ideaal: de code doet wat hij moet doen en niets anders. Om consistente kwaliteit en volledigheid te kunnen garanderen is het belangrijk dat iedere functie, release of sprint deze stappen ondergaat.
Deze werkwijze levert ook transparantie op. Als voor een release of functie niet alle vakjes zijn aangevinkt, kunnen we die niet vrijgeven en weet iedereen waarom.
Aangezien veel elementen van de DoD dienen om te garanderen dat alles goed werkt en voldoet aan de technische basisvereisten, is de systeembeheerder de hoofdrolspeler bij het definiëren van de Definition of Done. In het hele proces is de ScrumMaster echter leidend. Dit proces is een gezamenlijke oefening om het eens te worden over wat we kwalificeren als ‘Done’. Zonder goedkeuring en kwaliteitsborging van het product, zal er geen brede acceptatie zijn of iets daadwerkelijk is gedaan.
Bij het maken van de DoD moeten we denken aan alle taken die we moeten doen om de User Story in productie te brengen. We moeten fantasierijk zijn en alles opnemen, zelfs taken die buiten het team vallen. Na deze ideale visie van “done” kunnen we het terugbrengen tot een meer realistische definitie.
Het definiëren van “Done” is op de lange termijn een tijdwinst, omdat het onnodige herzieningen nadien vermindert. Als de code aan de definitie voldoet, heeft iedereen de verzekering dat deze klaar is voor vrijgave.
De Definition of Done (DoD) is gehaald als aan alle voorwaarden waaraan een softwareproduct moet voldoen, is voldaan. Het staat klaar voor de gebruiker, klant, team of API om te accepteren.
We moeten wel voldoen aan de Defination of Done om kwaliteit te garanderen. Zo voorkomen we productiefouten omdat User Stories die niet aan de definitie voldoen, niet kan promoveren naar omgevingen op een hoger niveau. Het voorkomt dus aflevering van functies die niet aan de definitie voldoen, aan de gebruiker.
Als de definitie eenmaal is ingevoerd, is deze van toepassing op alle software en zorgt het voor consistentie en kwaliteit.
Deze regels zijn van toepassing op elk afzonderlijk werkitem op onze SCRUM-borden, zolang het maar om code gaat. Of het nu een grote User Story is met meerdere afhankelijkheden of een kleine bugfix, van de persoon die het werk doet mogen we verwacht dat hij deze checklists doorloopt. Dat betekent echter niet dat alles op de checklist voor elk werkitem kunnen aanvinken – voor een kleine technische aanpassing zal er waarschijnlijk geen marketingmail nodig zijn. Het ontslaat ons er echter niet van dat we bij elk werkitem alles op de checklist in overweging moeten nemen.
De User Stories zijn het belangrijkste onderdeel van Agile development. Scrum eist echter niet van ons dat we expliciet ofwel User Stories ofwel Acceptatiecriteria gebruiken. Als we een backlog-item als te groot beschouwen om in een sprint te stoppen, splitsen we dit normaal gesproken op in meerdere User Stories en vervolgens in een reeks taken.
User Stories bevatten acceptatiecriteria, dus zien we vaak de Definition of Done en acceptatiecriteria naast elkaar bestaan in ons scrum-proces. User Stories bieden de context van de functionaliteit die het Scrum team moet leveren. De acceptatiecriteria geven richtlijnen over de details van genoemde functionaliteit en hoe de klant deze accepteert. De twee zorgen samen voor het hele product.
Sommige van de acceptatiecriteria ontdekken we gedurende de doorlopende backlog-verfijningsacties voordat de sprint begint. Andere ontdekken we direct na de Sprintplanning wanneer we gaan zitten om een gesprek te voeren over de User Story. Acceptatiecriteria zijn dus attributen die uniek zijn voor de User Story of het Product Backlog Item.
Het feit of iets gedaan is open laten voor interpretatie kan leiden tot conflicten en misverstanden. Het kan leiden tot negatieve gebruikerservaringen en kan gevolgen hebben voor de omzet, wat een goede reden is om aan die criteria te voldoen. Het delen van een gemeenschappelijke visie over wat het eindresultaat zou moeten zijn, is een goed startpunt voor ieder project. Het creëert een consensus en is een onderdeel van het verwachtingen management betreffende het project.
Een bijkomend voordeel van het feit dat niet elk afzonderlijk project zijn eigen maatstaf heeft, bespaart veel tijd. Het stelt mensen in staat zich te concentreren op de ontwikkel en de uitvoering. Als de dubbelzinnigheid is weggenomen, kan iedereen zich bezig houden met zijn kernverantwoordelijkheden in plaats van later in het proces ruzie te maken over de vrijgave van het product.
Technische schuld heeft de vervelende gewoonte om op te lopen. Zonder te zien hoeveel inspanning er werkelijk overblijft, kan het tekort snel uit de hand lopen. De tirannie van het werk dat bijna klaar is, maar niet echt “Done”, zal leiden tot nog meer technische schuld. De Product Owner, die formeel de acceptatie doet heeft hierin een belangrijke rol.
Als je je begint af te vragen waarom dit een kwestie van de Product Owner is en niet van de kwaliteitscontrole van systeembeheer, dan is dat deels te wijten aan het verschil tussen een algemene Definition of Done en de specifieke acceptatiecriteria voor een bepaalde User Story.
DoD wordt universeel toegepast op alles wat systeembeheer probeert vrij te geven. Dit is het een vrij algemene definitie.
Acceptatiecriteria zijn echter uniek voor iedere User Story of functie. Daarom moet de Product Owner dit criterium definieren.
Aangezien DoD voor alle deliverals geldt, moet de Product Owner de definitie herzien en ervoor zorgen dat we het erover eens zijn dat deze alomvattend genoeg is. Het eigendom en beheer van de definitie hoeven echter niet per se de verantwoordelijkheid van de Product Owner te zijn. Zolang het ontwikkelteam ervan overtuigd is dat “Done” items de tests zullen doorstaan die in het DoD zijn beschreven, kunnen we de definitie grotendeels ongewijzigd laten.
Een vrijgegeven functie kan de Product Owner soms echter zelf als nauwelijks voltooid beschouwen.
Een Product Owner is nog niet klaar met een product (of functie) als het daadwerkelijk in gebruik is genomen. Zodra het is gelanceerd, beginnen we aan de lange weg van gebruikersondersteuning, bugfixes en updates. De Definition of Done behandelt voornamelijk code en de geschiktheid ervan voor vrijgave. Maar de Product Owner is dan nog niet klaar. Hij zal daarom een definitie moeten maken die veel verder reikt in de levenscyclus van het product.
Het definiëringsproces mag niet in een vacuüm plaatsvinden, het moet een samenwerking zijn tussen belanghebbenden en degenen die het werk daadwerkelijk uitvoeren. Of het nu begint met brainstormen of met iemand van systeembeheer, er moet voldoende gelegenheid zijn voor commentaar en unanieme ondersteuning voor het eindproduct.
De DoD is een contract tussen de Product Owner en het team, dus het is verleidelijk om zoveel mogelijk items in de DoD op te nemen om de kwaliteit van het product te waarborgen. Maar dit kan echter averechts werken. Als we een team confronteren met te veel DoD-items, werken ze ofwel alleen aan een subset of proberen ze ze allemaal niet te doen. Daardoor elimineren we de waarde van de DoD.
Zoals alle goedbedoelde methodologieën, moet een Definition of Done zo eenvoudig en beknopt mogelijk zijn. Het idee is om consistente kwaliteit te creëren en geen bureaucratische hindernissen die de oplevering onnodig vertragen.
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.