Hoeveel openstaande bugs heeft u in uw backlog? 100? 1000?
Hoe lang liggen ze daar al? Een week? Een maand? Jaren?
Waarom gebeurt dit? Geen tijd? Moeten er belangrijkere taken gedaan worden? 'We zullen nu alle urgente functies implementeren, en daarna hebben we zeker tijd om de bugs op te ruimen'?

… Sommigen gebruiken een Zero Bug Policy, anderen hebben een goed ontwikkelde cultuur voor het omgaan met bugs (actualiseren op tijd de backlog, herbeoordelen van fouten bij wijzigingen in functionaliteit, enzovoort), en weer anderen kweken tovenaars die zonder bugs schrijven (onwaarschijnlijk, maar het kan soms gebeuren).

Vandaag zal ik u vertellen over onze oplossing voor het schoonmaken van de bugbacklog — het 'Bug Atelier' project.

Hoe is het allemaal begonnen?

Toen we weer eens de steeds groter wordende backlog met openstaande bugs bekeken, bereikten we het kookpunt. Zo verder leven was niet mogelijk, we besloten het koste wat het kost te verkleinen. Het idee is voor de hand liggend, maar hoe doe je dat? We kwamen tot de conclusie dat de meest effectieve manier een evenement zou zijn, vergelijkbaar met een hackathon: teams losmaken van dagelijkse taken en 1 werkdag toewijzen voor het verwerken van alleen bugs.

We stelden een regeling op, deden een oproep en wachtten. We hadden angst dat er maar enkele geïnteresseerden zouden zijn, heel weinig, maar het resultaat overtrof onze verwachtingen — er schreven zich maar liefst 8 teams in (hoewel 3 op het laatste moment afhaakten). We reserveerden een hele werkdag op vrijdag voor het evenement en boekten een grote vergaderzaal. De lunches werden georganiseerd vanuit de kantoor cafeteria, en we zorgden voor koekjes voor snacks.

Implementatie

De ochtend van de grote dag verzamelden we alle geïnteresseerden in de vergaderzaal en hielden we een korte briefing.

De belangrijkste regels:

• in één team strijden 2 tot 5 personen, minimaal één daarvan is QA;
• bugs moeten afgesloten worden door een teamlid volgens alle interne productiestandaarden;
• elk team moet minstens één gesloten bug hebben die aanpassingen in de code vereist;
• alleen oude bugs mogen hersteld worden (datum van creatie van de bug < datum van de start van de Bug Atelier — 1 maand);
• voor herstelde bugs worden punten (tussen 3 en 10) toegekend, afhankelijk van de ernst (om valsspelen te voorkomen kan de ernst niet worden gewijzigd na de aankondiging van de datum van het Bug Atelier);
• voor het sluiten van niet-actuele, niet-reproduceerbare bugs wordt 1 punt toegekend;
• de naleving van alle regels wordt gecontroleerd door het auditteam, dat punten annuleert voor heropende bugs.

Andere details

• We hebben niemand beperkt in de keuze van locatie: je kon op je werkplek blijven of met iedereen in de vergaderzaal zitten, waar de mensen niet afgeleid werden en de spanning voelbaar was.

• Om de competitieve geest te ondersteunen, werd er een scorebord op het grote scherm weergegeven en was er constant een live tekstoverdracht van het gevecht in de Slack-kanaal. Voor het tellen van punten werd een leaderboard gebruikt dat via webhooks werd bijgewerkt.

Leaderboard

• Een auditteam hield toezicht op de naleving van alle regels (uit ervaring blijkt dat 1-2 personen hiervoor voldoende zijn).
• Een uur na de afsluiting van de Bugathon werden de gecontroleerde resultaten bekendgemaakt.
  Winnaars ontvingen een cadeaubon voor een bar, en alle deelnemers kregen een aandenken (sleutelhangers met 'bugs').

Resultaten

In de afgelopen zes maanden hebben we al drie Bugathons gehouden. Wat hebben we uiteindelijk bereikt?

• Gemiddeld aantal teams — 5.
• Gemiddeld aantal verwerkte bugs — 103.
• Gemiddeld aantal niet-relevante / niet-reproduceerbare bugs — 57% (en dit afval viel constant op en maakte ons bang door de hoeveelheid).

Moment van de bekendmaking van de resultaten

En nu het antwoord op de meest uitdagende vraag die iedereen graag stelt: "Hoeveel nieuwe bugs hebben jullie gevonden?".
Antwoord: niet meer dan 2% van alle verwerkte.

Feedback

Na de Bugathons verzamelden we feedback van de deelnemers. Hier zijn de antwoorden op de vraag "Wat vond je het leukst aan het deelnameproces?":

• Het is erg leuk om de backlog met zo'n motivatie door te nemen! Gewoonlijk is dit een zeer saaie taak, het zou regelmatig moeten plaatsvinden).
• De spanning, koekjes.
• Dit is de langverwachte kans om die kleine dingen te verbeteren die niet kritiek zijn, maar die je wel wilt corrigeren.
• Ik vond het leuk dat we eindelijk oude, vervelende bugs konden oplossen buiten de sprint; daar is nooit tijd voor, omdat er altijd taken met een hogere prioriteit zijn. We hebben alle benodigde mensen op één plek kunnen verzamelen (in ons team was er bijvoorbeeld een DBA), we hebben gezamenlijk de relevantie van de gesignaleerde bugs en de technische haalbaarheid van het oplossen ervan besproken.

Conclusie

De Bugathon is geen panacee, maar een zeer levensvatbare optie om de backlog van bugs te verminderen (in verschillende teams van 10% tot 50%) in slechts één dag. Dit evenement is alleen gelukt dankzij gemotiveerde mensen die geven om het product en om het geluk van onze gebruikers.

Iedereen alle goeds en minder bugs!

Bron: habr.com