Hoeveel openstaande bugs heeft u in uw backlog? 100? 1000?
Hoe lang liggen ze daar? Een week? Maand? Jaren?
Waarom gebeurt dit? Geen tijd? Moet u meer prioritaire taken uitvoeren? "Nu zullen we alle urgente functies implementeren, en dan hebben we zeker tijd om de bugs op te lossen"?

... Sommigen gebruiken Zero Bug Policy, sommigen hebben een goed ontwikkelde cultuur van het werken met bugs (ze werken de backlog tijdig bij, herzien fouten wanneer de functionaliteit verandert, enz.), en sommigen cultiveren tovenaars die helemaal zonder bugs schrijven (onwaarschijnlijk, maar misschien gebeurt dit).

Vandaag zal ik je vertellen over onze oplossing voor het opruimen van de bugachterstand: het Bagodelnya-project.

Hoe is het allemaal begonnen?

Als we opnieuw door de steeds groter wordende achterstand aan openstaande bugs kijken, hebben we het kookpunt bereikt. Het was onmogelijk om nog langer zo te leven, ze besloten het koste wat het kost te kappen. Het idee ligt voor de hand, maar hoe doe je dat? We waren het erover eens dat de meest effectieve manier een evenement zou zijn dat lijkt op een hackathon: haal teams weg van alledaagse taken en wijs één werkdag toe om alleen bugs op te lossen.

Ze schreven de voorschriften op, riepen en begonnen te wachten. Er was de vrees dat er weinig kandidaten zouden zijn, heel weinig, maar het resultaat overtrof onze verwachtingen - maar liefst 8 teams schreven zich in (op het laatste moment fuseerden er echter 3). We hebben vrijdag een hele werkdag uitgetrokken voor het evenement en een grote vergaderruimte geboekt. In de kantoorkantine werden lunches georganiseerd en als tussendoortje werden er koekjes toegevoegd.

uitvoering

Op de ochtend van dag X verzamelde iedereen zich in een vergaderruimte en hield een korte briefing.

Basisregels:

• één team bestaat uit 2 tot 5 personen, waarvan minimaal één QA;
• bugs moeten door een teamlid worden gesloten volgens alle interne productienormen;
• Elk team moet ten minste één gesloten bug hebben waarvoor correcties in de code nodig zijn;
• Je kunt alleen oude bugs repareren (de datum waarop de bug is gemaakt < de startdatum van het bughuis - 1 maand);
• voor gecorrigeerde bugs worden punten (van 3 tot 10) toegekend afhankelijk van de kriticiteit (om bedrog te voorkomen kan de kriticiteit niet worden gewijzigd nadat de datum van de Bug Day is aangekondigd);
• voor het sluiten van irrelevante, niet-reproduceerbare bugs wordt 1 punt toegekend;
• De naleving van alle regels wordt gecontroleerd door het auditteam, dat punten annuleert voor herontdekte bugs.

Andere details

• We hebben niemand beperkt in de keuze van de locatie: ze konden op hun werkplek blijven of met iedereen in een vergadering zitten waar de jongens niet werden afgeleid en passies voelbaar waren.

• Om de competitieve geest te behouden, werd er een beoordelingstabel op het grote scherm weergegeven en werd er voortdurend een tekstuitzending van de strijd uitgezonden op het slack-kanaal. Om punten te berekenen, gebruikten we een scorebord dat werd bijgewerkt via webhooks.

Scorebord

• De naleving van alle regels werd gecontroleerd door het auditteam (uit ervaring zijn 1-2 personen hiervoor voldoende).
• Een uur na het einde van de Bagodelny werden de opnieuw gecontroleerde resultaten bekend gemaakt.
  De winnaars ontvingen een cadeaubon voor de bar en alle deelnemers ontvingen een souvenir (sleutelhangers met "beestjes").

Bevindingen

Het afgelopen half jaar hebben we al drie Godshuizen gehouden. Waar zijn we mee geëindigd?

• Het gemiddelde aantal teams is 5.
• Het gemiddelde aantal verwerkte bugs is 103.
• Het gemiddelde aantal irrelevante/onreproduceerbare bugs is 57% (en dit afval was voortdurend een doorn in het oog en bang voor de hoeveelheid ervan).

Moment van bekendmaking van de uitslag

En nu het antwoord op de lastigste vraag die iedereen graag stelt: “Hoeveel nieuwe bugs heb je gevonden?”
Antwoord: niet meer dan 2% van alle verwerkte bedragen.

beoordelingen

Na de Bagodelen hebben we feedback verzameld van de deelnemers. Hier zijn de antwoorden op de vraag “Wat vond je het leukst aan het participatieproces?”:

• Het is heel gaaf om met zo’n motivatie de achterstand weg te werken! Meestal is dit een erg saai proces, het moet periodiek worden gedaan).
• Opwinding, koekjes.
• Dit is een langverwachte kans om die kleine dingen te corrigeren die niet kritisch zijn, maar die je wel wilt corrigeren.
• Ik vond het leuk dat je buiten de sprint eindelijk oude, vervelende bugs kunt oplossen; daar zal nooit tijd voor zijn omdat er altijd taken met een hogere prioriteit zullen zijn. We zijn erin geslaagd alle benodigde mensen op één plek te verzamelen (ons team had bijvoorbeeld een database) en hebben gezamenlijk de relevantie van de geïdentificeerde bugs besproken en de technische mogelijkheid om deze op te lossen.

Conclusie

De bugshop is geen wondermiddel, maar wel een haalbare optie om de bugachterstand (in verschillende teams van 10 naar 50%) in slechts één dag terug te dringen. Voor ons is dit evenement alleen van start gegaan dankzij gemotiveerde jongens die het product ondersteunen en zich bekommeren om het geluk van onze gebruikers.

Het allerbeste en minder bugs!

Bron: www.habr.com