Hvor mange åpne feil har du i etterslepet? 100? 1000?
Hvor lenge ligger de der? En uke? Måned? år?
Hvorfor skjer dette? Ingen tid? Trenger du å gjøre flere prioriterte oppgaver? "Nå skal vi implementere alle de presserende funksjonene, og da vil vi definitivt ha tid til å sortere ut feilene"?

... Noen bruker Zero Bug Policy, noen har en velutviklet kultur for å jobbe med feil (de oppdaterer etterslepet i tide, reviderer feil når funksjonalitet endres osv.), og noen dyrker veivisere som skriver uten feil i det hele tatt. (usannsynlig, men kanskje dette skjer).

I dag vil jeg fortelle deg om løsningen vår for å rense bug-etterslepet - Bagodelnya-prosjektet.

Hvordan begynte alt?

Nok en gang ser gjennom den stadig økende etterslepet av åpne feil, har vi nådd kokepunktet. Det var umulig å leve slik lenger, de bestemte seg for å kutte det ned for enhver pris. Tanken er åpenbar, men hvordan gjør man det? Vi ble enige om at den mest effektive måten ville være en begivenhet som ligner på et hackathon: ta teamene vekk fra hverdagslige oppgaver og bevilge 1 arbeidsdag til kun å håndtere feil.

De skrev ned regelverket, ropte ut og begynte å vente. Det var frykt for at det skulle bli få søkere, svært få, men resultatet gikk over forventningene våre – hele 8 lag meldte seg på (men i siste øyeblikk slo 3 seg sammen). Vi bevilget en hel arbeidsdag på fredag ​​til arrangementet og bestilte et stort møterom. Det ble organisert lunsj i kantinen på kontoret, og småkaker ble lagt til snacks.

implementering

Om morgenen dag X samlet alle seg i et møterom og holdt en kort briefing.

Grunnleggende regler:

• ett team består av 2 til 5 personer, minst en av dem er QA;
• feil må lukkes av et teammedlem i henhold til alle interne produksjonsstandarder;
• Hvert lag må ha minst én lukket feil som krever korrigeringer i koden;
• Du kan bare fikse gamle feil (datoen feilen ble opprettet < startdatoen for feilhuset - 1 måned);
• for korrigerte feil tildeles poeng (fra 3 til 10) avhengig av kritikaliteten (for å unngå juks kan ikke kritikaliteten endres etter at datoen for feildagen er annonsert);
• for å lukke irrelevante, irreproduserbare feil, gis 1 poeng;
• Overholdelse av alle regler overvåkes av revisjonsteamet, som kansellerer poeng for gjenoppdagede feil.

Andre detaljer

• Vi begrenset ingen i valg av sted: de kunne bo på arbeidsplassen sin eller sitte sammen med alle i et møte hvor gutta ikke ble distrahert og lidenskaper kunne merkes.

• For å opprettholde konkurranseånden ble det vist en ratingtabell på storskjerm, og det ble hele tiden sendt en tekstsending av slaget i den slakke kanalen. For å beregne poeng brukte vi en ledertavle som ble oppdatert via webhooks.

ledertavle

• Overholdelse av alle regler ble overvåket av revisjonsteamet (erfaringsmessig er 1-2 personer nok for dette).
• En time etter slutten av Bagodelny ble de re-sjekkede resultatene annonsert.
  Vinnerne fikk et gavekort til baren, og alle deltakerne fikk en suvenir (nøkkelringer med "bugs").

Funn

I løpet av det siste halvåret har vi allerede holdt tre Almuhus. Hva endte vi opp med?

• Gjennomsnittlig antall lag er 5.
• Gjennomsnittlig antall behandlede feil er 103.
• Gjennomsnittlig antall irrelevante/irreproduserbare insekter er 57% (og dette søppelet var hele tiden et sårt øye og skremt med mengden).

Øyeblikk for kunngjøring av resultater

Og nå er svaret på det vanskeligste spørsmålet som alle elsker å stille: "Hvor mange nye feil har du funnet?"
Svar: ikke mer enn 2 % av alt behandlet.

anmeldelser

Etter Bagodelen har vi samlet inn tilbakemeldinger fra deltakerne. Her er svarene på spørsmålet "Hva likte du best med deltakelsesprosessen?":

• Det er veldig kult å sortere i etterslepet med en slik motivasjon! Vanligvis er dette en veldig kjedelig prosess, den må gjøres med jevne mellomrom).
• Spenning, informasjonskapsler.
• Dette er en etterlengtet mulighet til å rette opp de små tingene som ikke er kritiske, men du ønsker å rette.
• Jeg likte at du endelig kan fikse gamle, ubehagelige feil utenfor sprinten; det vil aldri være tid til disse fordi det alltid vil være oppgaver med høyere prioritet. Vi klarte å samle alle de nødvendige menneskene på ett sted (teamet vårt hadde for eksempel en dba), og diskuterte i fellesskap relevansen av de identifiserte feilene og den tekniske muligheten for å fikse dem.

Konklusjon

Feilbutikken er ikke et universalmiddel, men det er et levedyktig alternativ for å redusere etterslepet (i forskjellige team fra 10 til 50%) på bare én dag. For oss tok denne begivenheten av kun takket være motiverte gutter som støtter produktet og bryr seg om brukernes lykke.

Alt det beste og mindre feil!

Kilde: www.habr.com