Hur många öppna buggar har du i din backlog? 100? 1000?
Hur länge ligger de där? En vecka? Månad? år?
Varför händer detta? Ingen tid? Behöver du göra fler prioriterade uppgifter? "Nu ska vi implementera alla brådskande funktioner, och då kommer vi definitivt att ha tid att reda ut felen"?

... Vissa använder Zero Bug Policy, vissa har en välutvecklad kultur att arbeta med buggar (de uppdaterar eftersläpningen i tid, reviderar fel när funktionaliteten ändras etc.), och vissa odlar guider som skriver utan buggar alls. (osannolikt, men kanske detta händer).

Idag kommer jag att berätta om vår lösning för att rengöra buggstocken - Bagodelnya-projektet.

Hur började allt?

När vi återigen tittar igenom den ständigt ökande eftersläpningen av öppna buggar, har vi nått kokpunkten. Det var omöjligt att leva så här längre, de bestämde sig för att skära ner det till varje pris. Tanken är uppenbar, men hur gör man det? Vi kom överens om att det mest effektiva sättet skulle vara ett evenemang som liknar ett hackathon: ta team bort från vardagliga uppgifter och tilldela en arbetsdag för att bara hantera buggar.

De skrev ner föreskrifterna, ropade och började vänta. Det fanns farhågor om att det skulle bli få sökande, väldigt få, men resultatet överträffade våra förväntningar – hela 8 lag anmälde sig (dock i sista stund slogs 3 samman). Vi avsatte en hel arbetsdag på fredagen för eventet och bokade ett stort mötesrum. Luncher anordnades i kontorets matsal och kakor till mellanmål.

genomförande

På morgonen dag X samlades alla i ett mötesrum och höll en kort briefing.

Grundläggande regler:

• ett team består av 2 till 5 personer, minst en av dem är QA;
• buggar måste stängas av en gruppmedlem enligt alla interna produktionsstandarder;
• Varje lag måste ha minst en stängd bugg som kräver korrigeringar i koden;
• Du kan bara fixa gamla buggar (datumet då buggen skapades < startdatumet för bugghuset - 1 månad);
• för korrigerade buggar delas poäng (från 3 till 10) ut beroende på kritikaliteten (för att undvika fusk kan kritikaliteten inte ändras efter att datumet för buggdagen tillkännages);
• för att stänga irrelevanta, irreproducerbara buggar, ges 1 poäng;
• Efterlevnaden av alla regler övervakas av revisionsteamet, som tar bort poäng för återupptäckta buggar.

Andra detaljer

• Vi begränsade inte någon i valet av plats: de kunde stanna på sin arbetsplats eller sitta med alla i ett möte där killarna inte blev distraherade och passioner kunde kännas.

• För att behålla tävlingsandan visades en betygstabell på storbildsskärmen och en textsändning av striden sändes ständigt i den slaka kanalen. För att räkna ut poäng använde vi en leaderboard som uppdaterades via webhooks.

Leaderboard

• Efterlevnaden av alla regler övervakades av revisionsteamet (av erfarenhet räcker 1-2 personer för detta).
• En timme efter slutet av Bagodelny tillkännagavs de omkontrollerade resultaten.
  Vinnarna fick ett presentkort till baren och alla deltagare fick en souvenir (nyckelringar med "buggar").

Resultat

Under det senaste halvåret har vi redan hållit tre Almshouses. Vad slutade vi med?

• Det genomsnittliga antalet lag är 5.
• Det genomsnittliga antalet buggar som behandlas är 103.
• Det genomsnittliga antalet irrelevanta/irreproducerbara buggar är 57% (och detta skräp var ständigt ett öga och skrämt med sin mängd).

Ögonblick för tillkännagivande av resultat

Och nu är svaret på den knepigaste frågan som alla älskar att ställa: "Hur många nya buggar har du hittat?"
Svar: inte mer än 2 % av alla bearbetade.

omdömen

Efter Bagodelen samlade vi feedback från deltagarna. Här är svaren på frågan "Vad gillade du mest med deltagandeprocessen?":

• Det är väldigt häftigt att sortera igenom eftersläpningen med sådan motivation! Vanligtvis är detta en mycket tråkig process, den måste göras med jämna mellanrum).
• Spänning, kakor.
• Det här är ett efterlängtat tillfälle att rätta till de där små sakerna som inte är kritiska, men du vill rätta till.
• Jag gillade att man äntligen kan fixa gamla, obehagliga buggar utanför sprinten, det kommer aldrig att finnas tid för dessa eftersom det alltid kommer att finnas uppgifter med högre prioritet. Vi lyckades samla alla nödvändiga personer på ett ställe (vårt team hade till exempel en dba) och diskuterade gemensamt relevansen av de identifierade buggarna och den tekniska möjligheten att fixa dem.

Slutsats

Buggbutiken är inget universalmedel, men det är ett gångbart alternativ för att minska eftersläpningen (i olika team från 10 till 50%) på bara en dag. För oss tog det här evenemanget fart bara tack vare motiverade killar som stödjer produkten och bryr sig om våra användares lycka.

Allt det bästa och mindre buggar!

Källa: will.com