Câte erori deschise aveți în stoc? 100? 1000?
Cât timp stau acolo? O săptămână? Lună? Ani?
De ce se întâmplă asta? Nu este timp? Trebuie să faceți mai multe sarcini prioritare? „Acum vom implementa toate funcțiile urgente și apoi cu siguranță vom avea timp să rezolvăm erorile”?

... Unii folosesc Politica Zero Bug, unii au o cultură bine dezvoltată de lucru cu erori (actualizează în timp util restanțele, revizuiesc erorile atunci când funcționalitatea se schimbă etc.), iar unii cultivă vrăjitori care scriu deloc fără erori. (putin probabil, dar, poate se întâmplă acest lucru).

Astăzi vă voi spune despre soluția noastră pentru curățarea restanțelor de erori - proiectul Bagodelnya.

Cum a început totul?

Încă o dată, căutând prin acumularea tot mai mare de bug-uri deschise, am ajuns la punctul de fierbere. Era imposibil să mai trăiești așa, au decis să o reducă cu orice preț. Ideea este evidentă, dar cum se face? Am convenit că cea mai eficientă modalitate ar fi un eveniment similar cu un hackathon: îndepărtați echipele de sarcinile de zi cu zi și alocați o zi lucrătoare pentru a gestiona numai erorile.

Au notat regulamentul, au sunat și au început să aștepte. Au existat temeri că vor fi puțini solicitanți, foarte puțini, dar rezultatul a depășit așteptările noastre – s-au înscris până la 8 echipe (totuși, în ultimul moment s-au fuzionat 3). Am alocat o zi întreagă de lucru vineri pentru eveniment și am rezervat o sală mare de ședințe. În cantina de la birou s-au organizat prânzuri, iar pentru gustări s-au adăugat prânzuri.

punerea în aplicare

În dimineața zilei X, toată lumea s-a adunat într-o sală de ședințe și a ținut un scurt briefing.

Reguli de bază:

• o echipă este formată din 2 până la 5 persoane, cel puțin una dintre ele este QA;
• bug-urile trebuie să fie închise de un membru al echipei conform tuturor standardelor interne de producție;
• Fiecare echipă trebuie să aibă cel puțin un bug închis care necesită corecții în cod;
• Puteți remedia numai erorile vechi (data a fost creată bug-ul < data de începere a casei de bug - 1 lună);
• pentru bug-urile corectate, se acordă puncte (de la 3 la 10) în funcție de criticitate (pentru a evita trișarea, criticitatea nu poate fi schimbată după anunțarea datei Bug Day);
• pentru închiderea erorilor irelevante, ireproductibile, se acordă 1 punct;
• Respectarea tuturor regulilor este monitorizată de echipa de audit, care anulează punctele pentru erorile redescoperite.

Alte detalii

• Nu am limitat pe nimeni în alegerea locației: puteau să stea la locul de muncă sau să stea cu toată lumea într-o întâlnire în care băieții nu erau distrași și se puteau simți pasiunile.

• Pentru a menține spiritul competitiv, pe marele ecran a fost afișat un tabel de rating, iar o transmisie text a bătăliei a fost difuzată constant pe canalul slack. Pentru a calcula punctele, am folosit un clasament care a fost actualizat prin webhook-uri.

clasament

• Respectarea tuturor regulilor a fost monitorizată de echipa de audit (din experiență, 1-2 persoane sunt suficiente pentru asta).
• La o oră după încheierea Bagodelnyului, au fost anunțate rezultatele reverificate.
  Câștigătorii au primit un certificat cadou la bar, iar toți participanții au primit un suvenir (brelocuri cu „bugs”).

Constatări

În ultimele șase luni, am ținut deja trei case de pomană. Cu ce ​​am ajuns?

• Numărul mediu de echipe este de 5.
• Numărul mediu de erori procesate este de 103.
• Numărul mediu de bug-uri irelevante/ireproducibile este de 57% (și acest gunoi era în mod constant o bătaie de vedere și speriat de cantitatea lui).

Momentul anunțării rezultatelor

Și acum răspunsul la cea mai dificilă întrebare pe care toată lumea adoră să o pună: „Câte bug-uri noi ai găsit?”
Răspuns: nu mai mult de 2% din totalul procesat.

Review-uri

După Bagodelen, am colectat feedback de la participanți. Iată răspunsurile la întrebarea „Ce ți-a plăcut cel mai mult la procesul de participare?”:

• Este foarte tare să rezolvi restanța cu atâta motivație! De obicei, acesta este un proces foarte plictisitor, trebuie făcut periodic).
• Emoție, fursecuri.
• Aceasta este o oportunitate mult așteptată de a corecta acele lucruri mici care nu sunt critice, dar pe care doriți să le corectați.
• Mi-a plăcut că în sfârșit puteți remedia erori vechi, neplăcute în afara sprintului, nu va fi niciodată timp pentru acestea, deoarece vor exista întotdeauna sarcini cu prioritate mai mare. Am reușit să adunăm toți oamenii necesari într-un singur loc (echipa noastră avea un dba, de exemplu) și am discutat colectiv despre relevanța bug-urilor identificate și posibilitatea tehnică de remediere a acestora.

Concluzie

Magazinul de erori nu este un panaceu, dar este o opțiune viabilă pentru reducerea stocului de erori (în echipe diferite de la 10 la 50%) într-o singură zi. Pentru noi, acest eveniment a luat amploare doar datorită băieților motivați care susțin produsul și le pasă de fericirea utilizatorilor noștri.

Toate cele bune și mai puține bug-uri!

Sursa: www.habr.com