Is Agile / Scrum hetzelfde als Bug fixing?

Was bug fixing in watervalperiode niet Agile avant la lettre? Deze vraag van Harm Plekenpol naar aanleiding van mijn artikel “10 Belangrijke verschillen tussen Agile en Waterfall methodology”, overviel mij. Ik had daar nooit bij stil gestaan en in eerste instantie denk je ja, natuurlijk is Bug fixing Agile.

1. De backlog bestaat uit een aantal Products, namelijk de bugs.
2. De sprint bestaat uit één of enkele bugs.
3. Testen en naar productie, klaar.

Bovendien moet je behoorlijk lenig zijn om de bugs snel te kunnen fixen.
Maar als we inzoomen is bug fixing dan nog steeds Agile / Scrum?

De 6 Bug fix stappen

Als we het fixen van bugs uit elkaar rafelen kunnen we 6 stappen onderscheiden. Deze stappen kunnen we vergelijken met Agile / Scrum stappen en kijken of er overeenkomsten zijn.

1. We moeten de bug echt begrijpen

Als we informatie ontvangen over een nieuwe bug, moeten we niet zomaar aannames doen over de oorzaak. We moeten het probleem analyseren door alleen maar van de feiten uit te gaan. Er is waarschijnlijk een hele reeks code betrokken bij de bug, dus het is belangrijk om precies vast te stellen waar in de code de bug zich bevindt.

Ook als we de bug op een solide manier kunnen repliceren, betekent dit niet dat we de bug ook begrijpen. Ga niet uit van aannames, zelfs als het toevallig juist is.

Vergelijkbaar met User Stories in Scrum

Om de user-requirements goed te kunnen begrijpen maken we user stories in Scrum. We verifieren deze user stories bij de user om ze controleren en aannames uit te bannen.

2. Repliceer de bug

We moeten de tijd nemen om de bug zelf te repliceren, ook als iemand anders dit al voor ons heeft gedaan. We noteren vervolgens de replicatieworkflow die we hebben gevonden, deze hebben we later nodig om de details met het team te communiceren.

Bovendien verzamelen we zo bewijzen die we later nodig hebben om aan te tonen dat de bug is opgelost.

Welke stap is dit in Agile? Prototyping!

Veel Scrum teams maken gebruik van prototyping. Een prototype is een stukje software dat de ontwikkelaar maakt om aan de gebruiker te laten zien hoe de applicatie er uit komt te zien. Er is nog geen werkend programma, alleen de opzet en de mogelijke werking worden getoond. In feit repliceert de ontwikkelaar de requirements van de gebruiker.

3. Bug fixing, Los de bug op

We weten wat het probleem is en we kunnen het nu in de code herstellen.

De Scrum sprint start

In Agile / Scrum komt het product nu in de sprint. Het feitelijk coderen van de software is daar een onderdeel van.

4. Test de oplossing

We hebben de bug opgelost. Nu kunnen we testen of de bug daadwerkelijk niet meer bestaat. Als programmeur test je zelf de module op zijn werking voor je de gebruikers laat testen.

Niet anders in Agile Scrum

Binnen het Scrum team test de ontwikkelaar ook of zijn modules doen wat er van ze wordt verwacht.

5. Probeer de bugfix te breken.

Testen is op zichzelf een vaag begrip.

Het testen van een fix in een digitaal product kan van alles betekenen, simpelweg bewijzen dat de bug niet meer bestaat in het oorspronkelijke scenario. Het kan ook betekenen dat we de hele applicatie opnieuw moeten testen.

Zelfs als we een testsuite hebben met 100% codedekking, kunnen we nog steeds een vitaal scenario missen. Als we proberen om de module te breken hebben we meer kans om nog fouten te vinden en zwakke punten te verbeteren.

Integratietest in Scrum

Het is gevaarlijk om nieuwe software uit een sprint in productie te nemen. In productie draaien al modules en die hadden niet eerder te maken met deze nieuwe software. Voer dus altijd eerst een integratietest uit waaruit blijkt dat de oude en nieuwe modules goed samenwerken. Deze activiteit is een onderdeel van de sprint.

6. Hertesten tijdens Bug fixing

Is het gelukt om de bugfix te breken? Zo ja, dan moeten we terug naar stap 1 van Bug fixing en opnieuw beginnen.

Agile Scrum

In Scrum hoeven we niet terug naar de backlog of een prototype te maken als de integratietest faalt. We blijven binnen de Sprint en duiken opnieuw in de code.

Is Agile Scrum analoog aan Bug fixing?

We hebben wel een paar analogiën gevonden, maar het gaat te ver om Agile Scrum gelijk te stellen aan Bug Fixing.

Het begint al met het simpele feit dat Bug Fixing altijd alleen maar gaat over bestaande software. Agile Scrum daar en tegen gaat over nieuwbouw van software of grote releases. Dat vraagt om meer organisatie van het proces. Denk aan:

Deze zaken ontbreken bij Bug fixing. Anderzijds is de bug waarschijnlijk opgenomen in een ticket of call bij de helpdesk. We kunnen wel stellen dat Agile Scrum niet hetzelfde is als Bug Fixing.

Is Bug fixing Agile?

Dat was eigenlijk de vraag van Harm. Als we het Bug fixing proces nu eens tegen het Agile Manifesto houden…

De vier kernwaarden van Agile software-ontwikkeling zoals vermeld door het Agile Manifesto zijn:

• Individuen en interacties gaan voor processen en hulpmiddelen.
• Werkende software gaat voor uitgebreide documentatie.
• Samenwerking met de klant is belangrijker dan contractonderhandelingen.
• Reageren op verandering is belangrijker dan het volgen van een plan.

Volgens mij hoeven we hier niet lang bij stil te staan, Bug fixing voldoet glansrijk aan alle vier de kernwaarden. Bug fixing is Agile avant la lettre. Je zou bijna gaan twijfelen of Scrum wel Agile is :-) .

Discussieer mee op LinkedIn.