Snel en eenvoudig bugs fixen

Het fixen van bugs was al vóór Scrum een uitdaging in softwareontwikkeling. De korte iteraties in Agile maken het voor teams niet per se makkelijker om te beslissen welke bugs gefixt moeten worden en welke nog even kunnen wachten.

Het goede nieuws is dat een Scrum Team doorgaans aanzienlijk minder bugs heeft dan een team dat met traditionelere ontwikkelframeworks werkt. Maar ook agile teams komen hier en daar een bug tegen, vooral als een deel van de ontwikkeling stamt uit de tijd voordat het team overstapte naar een agile aanpak. En om deze defecten te prioriteren, heeft het team een effectieve oplossing nodig.

Prioritering van Bug Fixes: Wat je niet moet doen

Vroeg in mijn carrière als programmeur zette mijn baas het hele team een week lang apart om over alle bekende defects te praten. We spraken over mogelijke oorzaken, hoe ernstig elke individuele bug was, hoe vaak hij voorkwam, of hij gereproduceerd kon worden, waar in de code de fout zou kunnen zitten en wie van ons het probleem zou moeten oplossen.

We schatten zelfs in hoe lang het voor elke bug zou duren. Die inschattingen waren in de meeste gevallen niet alleen behoorlijk nutteloos, het duurde meestal ook langer om de inschatting te geven dan om simpelweg de bug te fixen.

Toen ik na deze vroege ervaringen teams ging leiden, begon ik te experimenteren met andere, lichtgewichtere aanpakken.

Vandaag wil ik mijn favoriete methode voor het fixen van bugs voorstellen.

Richtlijnen voor het prioriteren van bugs

In plaats van de tijd te nemen om over elke afzonderlijke bug na te denken, kun je beter richtlijnen opstellen die bepalen hoe snel een bug opgelost moet worden, oftewel hoe ernstig het defect – het probleem dat door de bug veroorzaakt wordt – is.

Voorbeeld 1: Een van deze richtlijnen zou kunnen zijn dat elke bug die alle gebruikers op een drastische manier beïnvloedt, onmiddellijk verholpen moet worden – dat betekent dat het lopende werk in de Sprint wordt onderbroken. Een andere richtlijn zou bijvoorbeeld kunnen stellen dat bugs die slechts uiterst zelden voorkomen en de gebruiker er niet van weerhouden de belangrijkste functies te gebruiken, genoteerd worden en zonder druk opgelost worden zodra daar tijd voor is.

Het opstellen en toepassen van richtlijnen noemt men ook wel prioritering door richtlijnen (prioritization by policy).

Voorbeeld 2: Een wat concreter voorbeeld zou zijn wanneer de Product Owner het met zijn team eens is dat elke bug die gebruikers ervan weerhoudt bestellingen te plaatsen op hun eCommerce-site, zo snel mogelijk verholpen moet worden.

Andere richtlijnen hebben misschien betrekking op bugs die pas aan het einde van de dag, aan het einde van de week, of zelfs helemaal niet gefixt hoeven te worden.

Defect-richtlijnen definiëren

Nuttig bij het formuleren van bug-fixing-richtlijnen zijn de volgende overwegingen:

• Waarschijnlijkheid van een defect: Hoe vaak doet het probleem zich voor?
• Ernst van een defect: Hoe erg is het wanneer het probleem zich voordoet?

Stel je voor dat er bij Amazon een bug is die ervoor zorgt dat bestellingen met een waarde van 1 miljoen dollar niet geplaatst kunnen worden, omdat een ontwikkelaar ervan uitging dat een bestelling nooit boven een waarde van 999.999,99 dollar zou liggen.

Het is slecht als dit geval zich voordoet (hoge ernst), maar ik denk dat Amazon niet bijzonder veel bestellingen krijgt die boven de 1 miljoen dollar liggen (lage waarschijnlijkheid).

Opstellen van de Defect-richtlijnenmatrix voor het prioriteren van bugs

Deze twee dimensies – ernst en prioriteit – kunnen gecombineerd worden om het prioriteitenbeleid voor een Defect vast te stellen. Daarbij kan zo'n matrix helpen:

Er zijn veel manieren om de waarschijnlijkheid en ernst van bugs in te delen. Bij het voorbeeld met de eCommerce-site wordt de waarschijnlijkheid bijvoorbeeld uitgedrukt als het percentage getroffen transacties. Alles wat 10% of meer van de transacties beïnvloedt, is behoorlijk belangrijk, dus heb ik de hele kolom op hoge of zeer hoge prioriteit gezet.

Om de ernst van een defect te beoordelen, kun je nagaan of er een workaround bestaat en of die voor de hand ligt of juist moeilijk te vinden is. Op een eCommerce-site zijn er bijvoorbeeld soms twee "Nu kopen"-knoppen, maar werkt er maar één.

De cellen van de matrix laten zien welke richtlijn geldt voor defects met een bepaalde waarschijnlijkheid en een bepaalde ernst. In dit voorbeeld heb ik vijf verschillende prioriteitsniveaus gekozen – van zeer laag tot zeer hoog. In sommige gevallen zijn drie niveaus misschien al voldoende. Ik zou afraden om er meer dan vijf te gebruiken, maar ook dat heb ik al eens gezien.

Zo gebruik ik de vijf prioriteitsniveaus:

• Zeer hoog: Wordt direct opgenomen in de lopende iteratie, ook als dat betekent dat ander werk blijft liggen. Vereist mogelijk meer dan één teamlid, eventueel zelfs het hele team.

• Hoog: Wordt direct opgenomen in de lopende iteratie, ook als dat betekent dat ander werk blijft liggen. Het team beslist wie het probleem het beste kan oplossen.

• Gemiddeld: Kan naar inzicht van de Product Owner worden opgenomen in de lopende iteratie.

• Laag: Wordt gedocumenteerd en in het volgende Planning Meeting naar inzicht van de Product Owner besproken.

• Zeer laag: Wordt gedocumenteerd in een lijst met bekende problemen. Wordt alleen opnieuw besproken als de waarschijnlijkheid of ernst verandert, of naar inzicht van de Product Owner.

Voordelen van prioritering door richtlijnen

Het grote voordeel van deze aanpak is dat je aanzienlijk minder tijd kwijt bent aan discussies over wat er met elke afzonderlijke defect moet gebeuren. Dit soort bugprioritering vraagt in het begin wat inspanning om de richtlijnen op te stellen. Maar zodra deze richtlijnen eenmaal staan, wordt het prioriteren van nieuwe defects een fluitje van een cent.

Het doel van deze aanpak is dat het prioriteren van defects een meer objectieve in plaats van subjectieve aangelegenheid wordt. Natuurlijk zal iemand moeten inschatten hoe vaak een probleem waarschijnlijk zal optreden, maar afgezien daarvan kost het prioriteren zelf niet meer tijd dan een blik op de prioriteringsmatrix.

Dit bericht is afkomstig uit de blog van Mike Cohn en is door ons naar het Nederlands vertaald.

Product Owner Seminar

=> Word gecertificeerd Product Owner en bezoek een van onze Trainings

Niet-functionele eisen

=> Ontdek hoe je niet-functionele eisen omzet in User Stories.

Product Scorecard

=> Ontdek of jouw product bijdraagt aan de bedrijfsstrategie en gebruik de Product Scorecard.