Hvor mange åbne bugs har I i backloggen? 100? 1000?
Hvor lang tid har de været der? En uge? En måned? År?
Og hvorfor sker det? Mangler I tid? Er der mere prioriterede opgaver? "Lige nu implementerer vi alle de presserende funktioner, og så vil der helt sikkert være tid til at rydde op i bugs bagefter"?

… Nogle bruger Zero Bug Policy, andre har en veludviklet kultur omkring bugs (opdaterer backloggen rettidigt, gennemgår fejl når funktionaliteten ændres osv.), og så er der dem, der dyrker magikere, der skriver helt uden bugs (usandsynligt, men det kan ske).

I dag vil jeg fortælle jer om vores løsning til oprydning af backloggen af bugs – projektet "Bug-fabrikken".

Hvordan begyndte det hele?

Efter endnu engang at have kigget på den stadigt voksende backlog af åbne bugs, nåede vi et kogepunkt. Vi kunne ikke leve sådan længere, og besluttede at nedbringe den for enhver pris. Ideen er indlysende, men hvordan gør man det? Vi blev enige om, at den mest effektive måde ville være et arrangement, der minder om et hackathon: at trække teamene væk fra deres daglige opgaver og afsætte én arbejdsdag til kun at arbejde på bugs.

Vi skrev en regulering, sendte et kald ud og begyndte at vente. Der var bekymring for, at der ville være meget få interesserede, men resultatet oversteg vores forventninger – hele 8 teams meldte sig (desværre trak 3 sig i sidste øjeblik). Vi afsatte en hel arbejdsdag om fredagen til arrangementet og bookede et stort mødelokale. Frokoster blev ordnet i den kontorbespisning, og til snacks tilføjede vi småkager.

Implementering

Om morgenen på den store dag samlede vi alle interesserede i mødelokalet og afholdt et kort briefing.

De grundlæggende regler:

• I et team kæmper mellem 2 og 5 personer, minimum én af dem skal være QA;
• Bugs skal lukkes af et medlem af teamet i henhold til alle interne produktionsstandarder;
• Hvert team skal have mindst én lukket bug, der kræver rettelser i koden;
• Kun gamle bugs må rettes (oprettelsesdatoen for buggen < datoen for starten af bug-fabrikken — 1 måned);
• For rettede bugs gives der point (fra 3 til 10) afhængigt af kritikaliteten (for at undgå snyd, kan kritikaliteten ikke ændres efter at datoen for Bug-fabrikken er annonceret);
• For lukning af irrelevante, ikke-reproducerbare bugs gives der 1 point;
• Et audit-team overvåger overholdelsen af alle regler og annullerer point for genåbnede bugs.

Andre detaljer

• Vi begrænsede ikke nogen i valget af lokation: man kunne blive siddende ved sin arbejdsplads eller sidde sammen med alle i mødelokalet, hvor folk ikke blev forstyrret, og spændingen kunne føles.

• For at støtte konkurrencen blev der vist en rangliste på det store skærm, og der var konstant tekstopdatering af kampen i slack-kanalen. Pointene blev talt på en leaderboard, der blev opdateret via webhooks.

Leaderboard

• Overholdelsen af alle regler blev overvåget af auditteamet (efter erfaring kræves der blot 1-2 personer til dette).
• En time efter afslutningen af Bugathonen blev de reviderede resultater offentliggjort.
  Vinderne modtog gavekort til en bar, og alle deltagere fik en mindegave (nøgleringe med "bugs").

Resultater

I løbet af de seneste seks måneder har vi gennemført tre Bugathoner. Hvad fik vi så ud af det?

• Det gennemsnitlige antal teams - 5.
• Det gennemsnitlige antal behandlede bugs - 103.
• Det gennemsnitlige antal irrelevante/ikke reproducerbare bugs - 57% (og denne affald kunne konstant irritere og skræmme med sit antal).

Øjeblikket for offentliggørelse af resultaterne

Og nu svaret på det mest tricky spørgsmål, som alle elsker at stille: "Hvor mange nye bugs fangede I?".
Svar: ikke mere end 2% af alle behandlede.

Anmeldelser

Efter gennemførelsen af Bugathonerne samlede vi feedback fra deltagerne. Her er svarene på spørgsmålet "Hvad kunne du bedst lide ved deltagelsesprocessen?":

• Det er virkelig fedt at gennemgå backloggen med så meget motivation! Normalt er det en meget kedelig proces, dette bør gøres periodisk).
• Spænding, småkager.
• Det er en ventet mulighed for at rette de småting, der ikke er kritiske, men som man gerne vil forbedre.
• Jeg kunne godt lide, at man endelig kunne fikse gamle, irriterende bugs uden for sprinten, da der sjældent er tid til sådanne, da der altid vil være opgaver med højere prioritet. Vi fik samlet alle de nødvendige personer (for eksempel havde vi en DBA i vores team), og vi diskuterede kollektivt relevansen af de angivne bugs og den tekniske mulighed for at rette dem.

Konklusion

Bugathonen er ikke en mirakelkur, men en fuldt levedygtig løsning til at reducere bug backloggen (i forskellige teams fra 10 til 50%) på bare én dag. Denne begivenhed har kun taget fart takket være de motiverede personer, der brænder for produktet og ønsker at sikre vores brugeres tilfredshed.

Ønsker alle det bedste og færre fejl!

Kilde: habr.com