Zilverline geeft al meer dan 10 jaar gecertificeerde Scrum trainingen. Scrum is al lang niet meer iets nieuws en inmiddels gemeengoed geworden. Toch zijn er vragen die tijdens onze Scrum trainingen al jarenlang terugkomen. Een daarvan is “hoe ga je om met bugs in een Scrum project?”. Naast Scrum trainingen ontwikkelen we ook software bij Zilverline. Hierdoor kunnen we deze vragen niet alleen vanuit de theorie beantwoorden maar juist vanuit de praktijk.

HOE GA JE OM MET BUGS IN EEN SCRUM PROJECT?

Er zijn grofweg 3 manieren om met bugs om te gaan:

Bugs op de backlog zetten. In overleg met de Product Owner worden de bugs opgepakt of niet. Om de huidige Sprint niet te verstoren wordt dit meestal in een volgende Sprint gedaan (behalve als productie eruit ligt natuurlijk). Groot nadeel van deze aanpak is dat bugs hierdoor lage prioriteit krijgen en er dus nieuwe functionaliteiten worden gebouwd op iets wat bugs bevat. Deze aanpak raden we dan ook af.

Een aparte "swimlane" introduceren voor bugs. Sommige teams maken een aparte swimlane op het Scrumbord om de bugs inzichtelijk te maken. Ook hiervoor geldt dat de prioriteit van deze swimlane vaak onduidelijk is er er vaak maar 1 iemand aan werkt.

Meteen oplossen. Dit is de aanpak die waar wij voorstaan en komt erg overeen met de “Stop the line” mentaliteit van Toyota. Door de jaren ben ik erachter gekomen dat dit de beste (of enige) manier is om de kwaliteit van je product te kunnen garanderen en de snelheid van ontwikkelen vol te kunnen houden. In de Scrum community is er een naam voor de manier van werken: Whack the Mole.

METEEN OPLOSSEN

Bij Jortt, het boekhoudsysteem gericht op ZZP'ers en kleine ondernemingen, passen we dit als volgt toe. Als er een bug binnenkomt, via onze monitoring systemen of via onze helpdesk, vindt er triage plaats:

• Is dit een bug en moet dit meteen worden opgelost? Zo ja, dan stoppen we met waar we mee bezig zijn en lossen dit op. Achteraf of tijdens brengen we onze Product Owner op de hoogte. Het Development team weet over het algemeen het beste of dit meteen moet worden opgelost of niet. De meeste fouten vallen in deze categorie. Als je deze manier van werken goed toepast ga je merken dat deze categorie steeds minder vaak voorkomt.

• Kan deze bug even wachten? Zo ja, dan maken we de taak af waar we mee bezig en pakken het op zodra we klaar zijn waar we mee bezig waren. De bug komt dan dus bovenaan de Sprint backlog te staan.

• Was het helemaal geen bug maar bijvoorbeeld een verstoring in een extern systeem? Dan melden we dit bij de externe provider zodat zij ook op de hoogte zijn. We zorgen er dan natuurlijk wel voor dat onze klanten geen lelijke foutpagina te zien krijgen, maar een melding dat dit gedeelte van de applicatie het even niet doet door een externe verstoring.

Om dit goed te kunnen doen heb je het volgende nodig: ** **Afstemming in het Scrum Team hoe er met bugs wordt omgegaan. De Product Owner is er van op de hoogte dat het Development team zelfstandig deze beslissing neemt.

Een robuuste foutafhandeling in je systeem. Maak een onderscheid tussen verwachte fouten (zoals ongeldige waarden in een input formulier) en onverwachte fouten (zoals programmeer fouten). Verwachte fouten hoef je over het algemeen niet te loggen, dit geeft veel te veel ruis in je monitoringsysteem.

Een goed monitoring systeem, zoals bijvoorbeeld het Nederlandse Appsignal. Wij gebruiken Appsignal en zodra er iets fout gaat in Jortt krijgen we een email en een bericht via Slack. We kijken dan meteen wat voor een fout het is (triage) en hoe vaak die voor is gekomen. Indien nodig maken we een issue aan in onze digitale backlog (Pivotal Tracker) en gaan er dan zoals al gezegd direct meteen mee aan de slag of parkeren hem om als volgende taak op te pakken.

Monitor niet alleen je server code. Monitor je browser code, je code van je mobiele applicaties, je servers, je database, je alles. Dit hangt natuurlijk erg af van je applicatie, maar het is belangrijk niet alleen op bugs in code te letten. Hoe groter je applicatie hoe meer bewegende delen. Zorg ervoor dat je van elk component onder je hoede monitort of dat het gemonitord wordt.

Een goede CI/CD pipeline met een goede set van tests. Alleen hiermee kun je vol vertrouwen je bug fixen (vergeet niet eerst een test te schrijven die je bug bewijst) en meteen in productie zetten.

Deze manier van werken draagt enorm bij aan de kwaliteit en stabiliteit van je applicate. Uiteraard gaat er af en toe wat mis, we krijgen ongeveer 1 à 2 meldingen per dag binnen van onze monitoring systemen, maar na triage blijken daarvan maar weinig echte bugs te zijn. En zijn er echte verstoring dan zijn deze ook in een paar minuten gefixed en staan live in productie.