Follow Us on Twitter

Agile bevindingen oplossen

Gepubliceerd in

November 2013 – "Vroeger was alles beter". Je plande je project met een analysefase, bouwfase, testfase en daarna ging alles naar productie. Simpel en efficiënt. Tijdens de bouwfase zette je vol vermogen ontwikkelteams in en tijdens de testfase hield je een paar ontwikkelaars standby om die "paar bevindingen" op te lossen. Fast forward naar 2013 en het is alles agile wat de klok slaat. Analyse, bouw en test worden in korte iteraties van ca. 2 weken doorlopen. Bevindingen komen tijdens en na elke iteratie en moeten op een zinnige manier gemixt worden met de rest van het werk.

In dit Whitebook zullen we enkele praktische handreikingen doen hoe je in een agile project met bevindingen om kan gaan.

Bug of Change Request?

Voor elke bevinding zou je aan kunnen geven of deze een bug of een change request is. Het kenmerkende verschil is dat een bug een afwijking is tussen het ontwerp en de implementatie, terwijl een change request een wijziging op zowel het ontwerp als de implementatie is. Voor dit Whitebook is dit onderscheid niet relevant. In beide gevallen gaat het namelijk om werk wat door het team gedaan moet worden. Welke producten daar precies voor gewijzigd moeten worden doet niet ter zake.

Binnen of buiten de iteratie?

Bevindingen kunnen zowel tijdens de iteratie als na de iteratie-oplevering gedaan worden. In dit geval gaan we ervan uit dat bevindingen die tijdens de iteratie gedaan worden, ook tijdens de iteratie door het team opgelost worden. Dit hoort namelijk bij een regulier agile proces van samenwerken en samen een werkende oplossing maken. We gaan in dit Whitebook dus kijken naar bevindingen die buiten de iteratie gedaan worden.

Welke testen en wanneer?

Welke bevindingen je nog buiten je iteratie om kunt krijgen is grotendeels afhankelijk van de "Definition of Done": hoeveel werk doe je binnen de iteratie en hoeveel gebeurt er nog ná de iteratie?

Het spreekt voor zich dat het beter is om zoveel mogelijk werk binnen de iteratie te verzetten, zodat een goedkeuring op de iteratie-oplevering idealiter betekent dat deze direct door kan naar productie. In dat geval komen bevindingen uitsluitend uit productie. Er zijn echter ook projecten (en dat zijn geen uitzonderingen) die een wat beperktere Definition of Done hanteren, waardoor er tussen een iteratie-oplevering en een oplevering naar productie nog aanvullende (acceptatie-)testen plaatsvinden.

Plain vanilla Scrum

Scrum "by the book" zegt, dat het team uitsluitend commitment gegeven heeft op de sprint backlog. Eventuele bevindingen van buiten de sprint komen op de product backlog en zullen op zijn vroegst in de eerstvolgende sprint planning ingepland worden.

Dit is een heel transparante manier van werken, zowel voor het team als voor de product owner, maar ook nogal rigide. Het duurt maximaal 2 sprints voor de bevinding in een iteratie-oplevering opgenomen is. Afhankelijk van de ernst van de bevinding en de lengte van de sprint kan dat een onwenselijke situatie creëren. Bij sprints van 3 weken kan het namelijk tot 6 weken duren voordat een bevinding gepland en opgeleverd is.

Planningstechnisch zijn bevindingen product backlog items die regulier een inschatting in story points krijgen. Ze kunnen dan regulier ingepland worden, samen met de rest van het werk op basis van de velocity van het team.

Plain vanilla Scrum
Plain vanilla Scrum

"Fix morning"

Een andere aanpak is om op een vast moment tijdens een iteratie een timebox in te lassen om bevindingen op te pakken. Dat kan bv. aan het begin van een iteratie zijn. Op dat moment pakt het team alle openstaande bevindingen op en werkt ze weg. Dit verkort de oplostijd van bevindingen naar ruwweg 1 iteratie.

Deze aanpak werkt vooral goed bij een relatief klein aantal bevindingen. Als het aantal bevindingen de timebox overstijgt, dan introduceer je in feite een tweede product backlog (één met "echt" werk en één met bevindingen), waarop weer eigen prioritering noodzakelijk is. Dit is onwenselijk.

Planningstechnisch blijven bevindingen helemaal buiten de product backlog. De velocity van het team zal netto iets omlaag gaan omdat een gedeelte van de sprint gebruikt wordt voor de bevindingen. Zolang de timebox en het aantal bevindingen relatief klein is, hoeft dat geen enkel probleem te zijn.

Fix Morning
"Fix Morning"

Capaciteit reserveren

Je kunt ook een gedeelte van je capaciteit reserveren om bevindingen op te lossen. Dit lijkt veel op de hierboven beschreven "fix morning", met als kenmerkend verschil dat de bevindingen niet in een timebox opgelost worden, maar naar eigen inzicht over de iteratie uitgesmeerd worden. Zodra een bevinding binnenkomt kan het team bepalen of deze nog past binnen de iteratie en wanneer die dan het beste opgepakt kan worden.

Deze aanpak is erg flexibel vanuit het perspectief van de product owner, bevindingen kunnen op elk moment bij het team neergelegd worden en opgepakt worden. Oplossen van een bevinding duurt ruwweg een halve iteratie. Het vereist echter wel meer discipline van het team. Er ontstaat gemakkelijk veel afleiding, waardoor de rest van het werk in de iteratie te lijden heeft onder de extra bevindingen. Als bevindingen meer uitzondering dan regel zijn, dan kan deze aanpak goed werken.

Planningstechnisch blijven ook in dit geval bevindingen buiten de product backlog. Het team zal op basis van de velocity conservatief de sprint inplannen. Zodoende blijft er een beetje lucht voor eventuele bevindingen.

Capaciteit reserveren
Capaciteit reserveren

Bevindingensprints

Sommige projecten gebruiken bevindingensprints. Een aantal iteraties wordt er dan uitsluitend aan nieuwe functionaliteit gewerkt, waarna er een sprint uitsluitend aan bevindingen gewerkt wordt.

Deze aanpak lijkt op het eerste gezicht aantrekkelijk omdat teams dan lekker "meters kunnen maken". Het is echter de vraag hoeveel werk daadwerkelijk vooruitgeschoven wordt naar een bevindingensprint. Daarnaast wordt de doorlooptijd tussen het moment dat het team iets gemaakt heeft en het moment dat ze een bevinding daarop oplossen groter. Omdat de functionaliteit niet meer "on top of mind" is bij het team, zal het oplossen van de bevinding netto langer duren. Ik zou deze aanpak niet (snel) aanraden.

Planningstechnisch betekent dit dat sprints op basis van de velocity ingepland kunnen worden, zonder rekening te hoeven houden met bevindingen. Op de doorlooptijd van het gehele project moet echter wel degelijk rekening gehouden met de bevindingensprints, tijdens deze sprints is de team velocity namelijk nul.

Bevindingensprint
Bevindingensprint

Evalueren

Als de situatie ontstaat dat het aantal bevindingen structureel te groot is voor de afgesproken timebox, capaciteitsreservering of bevindingensprint , dan is dit ook een goed onderwerp voor de iteratie-evaluatie. Instinctief zal een team geneigd zijn om de timebox wat te vergroten, meer capaciteit te reserveren voor bevindingen of om nóg een extra bevindingensprint in te lassen.

Het is echter ook een uitstekend moment om het eigen proces goed onder de loep te nemen. Wat is namelijk de oorzaak van dat (te) hoge aantal bevindingen? Een effectieve maatregel kan dan bijvoorbeeld zijn om tijdens een iteratie intensiever samen te werken met de product owner, zodat de bevindingen in de eerste plaats niet eens ontstaan.

Conclusie

Er zijn vele mogelijkheden om bevindingen in een agile project te vlechten. In dit Whitebook hebben we een aantal van die mogelijkheden besproken, met hun voor- en nadelen. Feedback is een belangrijke pijler van elk agile project en bevindingen zijn een vorm van feedback. Zoek de juiste manier voor jouw project om bevindingen te verwerken en je kunt grote stappen maken in de kwaliteit van je software. Het is goed om te streven naar nul bevindingen, maar áls ze er zijn, zoek dan een aanpak waarin je de feedback ook weer snel verwerkt hebt.

Referenties

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.