Mitu avatud viga on teie backlogis? 100? 1000?
Ja kui kaua need seal on olnud? Nädal? Kuu? Aastad?
Kuidas see juhtus? Pole aega? Tuleb tegeleda prioriteetsemate ülesannetega? "Hetkel viime ellu kõik kiiresti vajalikud funktsioonid ja siis kindlasti on aega vigade lahendamiseks"?

... Mõned kasutavad Zero Bug Policy't, teistel on hästi välja arendatud vigade haldamise kultuur (ajakohastavad backlogi õigeaegselt, vaatavad vead üle funktsionaalsuse muutumisel jne), aga mõned kasvatavad nõidu, kes kirjutavad täielikult ilma vigadeta (kuigi see on ebatõenäoline, võib see siiski juhtuda).

Täna räägin teile meie lahendusest vigade backlogi puhastamiseks - projekt "Buginurg".

Kust kõik algas?

Vaadates jälle kasvavat avatud vigade backlogi, jõudsime keemisteni. Polnud enam võimalik nii jätkata, soovisime seda igal moel vähendada. Idee on ilmne, aga kuidas seda teha? Kokku lepitud, et kõige tõhusam viis on korraldada midagi, mis meenutab hackathon'i: võtta meeskonnad igapäevastest ülesannetest eemale ja eraldada 1 tööpäev vaid vigade lahendamiseks.

Kirjutasime reglemendi, kutsusime üles ja hakkasime ootama. Oli mure, et osalejaid on vähe, väga vähe, aga tulemus ületas meie ootusi - registreerus lausa 8 meeskonda (kui tõsi, siis viimase hetke tõttu langes 3 välja). Üritusele määrati terve tööpäev reedel, suur nõupidamisruum broneeriti. Lõunad korraldati kontori kohvikus, suupisteteks lisati küpsiseid.

Rakendamine

Hommikul päev X kogusime kõik soovijad nõupidamisruumis ja viisime läbi lühikese briifingu.

Peamised reeglid:

• ühes meeskonnas võitleb 2 kuni 5 inimest, vähemalt üks neist - QA;
• vead peavad olema suletud meeskonna liikme poolt vastavalt kõigile sisemistele tootmisstandarditele;
• iga meeskond peab sulgema vähemalt ühe vea, mis vajab koodis parandamist;
• saab parandada ainult vanu vigu (vea loomise kuupäev < buginurga alguse kuupäev - 1 kuu);
• parandatud vigade eest antakse punkte (3 kuni 10), sõltuvalt kriitilisusest (et vältida vale mängu, ei tohi muuta kriitilisust pärast buginurga toimumise kuupäeva kuulutamist);
• aktuaalsete, reprodutseerimata vigade sulgemise eest antakse 1 punkt;
• Kõiki reegleid jälgib auditimeeskond, mis tühistab punktid uuesti avatud vigade eest.

Muud üksikasjad

• Me ei piiranud kedagi asukoha osas: võis jääda töökohale või istuda koos kõigi teistega koosolekutoa puhul, kus mehi ei segatud ja tundus, et emotsioonid olid laes.

• Konkureerimise vaimu toetamiseks kuvati suurel ekraanil edetabel, ja slack-kanalis käis pidev tekstiline ülekanne lahingust. Punktide arvestamiseks kasutati liidrit, mis uuendati veebihookide kaudu.

Liider

• Kõiki reegleid jälgis auditimeeskond (kogemuste põhjal piisab 1-2 inimesest).
• Tunni pärast Bagarite lõpetamist kuulutati välja ülevaatud tulemused.
  Võitjad said kinkekaardi baari, ja kõik osalejad said meenutuseks suveniire (avariidega võtmehoidjad).

tulemused näitasid ainult nelja ebaolulise koodibloki kattuvust, mis olid tingitud POSIX ja ANSI C nõuetest.

Viimase kuue kuu jooksul oleme korraldanud juba kolm Bagari. Mida me lõpuks saavutasime?

• Keskmine meeskondade arv on 5.
• Keskmine töödeldud vigade arv on 103.
• Keskmine mitteaktuaalsete/taaskasutatavate vigade arv on 57% (ja see prügi segas pidevalt silma ja hirmutas oma koguse poolest).

Tulemuste kuulutamise hetk

Ja nüüd vastus kõige keerulisemale küsimusele, mida kõik armastavad küsida: „Kui palju uusi vigu te tekitasite?”.
Vastus: mitte rohkem kui 2% kõigist töödeldud.

Tagasiside

Pärast Bagodede läbiviimist kogusime osalejatelt tagasisidet. Siin on vastused küsimusele „Mis meeldis osalemise protsessis kõige rohkem?”:

• On väga äge arutada backlogi sellise motivatsiooniga! Tavaliselt on see väga igav protsess, selliseid tuleks korra teha).
• Ahnus, küpsised.
• See on kauaoodatud võimalus parandada neid pisiasju, mis ei ole kriitilised, aga mida on soov teha.
• Meeldis, et lõpuks on võimalik parandada vanu, ebameeldivaid vigu sprintide vahel, kuna selliste jaoks ei jää kunagi aega, sest alati on kõrgema prioriteediga ülesandeid. Õnnestus kokku tuua kõik vajalikud inimesed (näiteks meie meeskonnas oli dba), arutasime koos korraldatud vigade asjakohasust ja nende parandamise tehnilist võimalust.

Kokkuvõte

Bugihaldus ei ole panacea, kuid täiesti elujõuline variant veaparanduste järjekorra vähendamiseks (erinevates meeskondades 10 kuni 50%) vaid ühe päevaga. Meil on see üritus õnnestunud ainult tänu motiveeritud inimestele, kes hoolivad tootest ja meie kasutajate õnnest.

Soovin kõigile head ja vähem vigu!

Allikas: habr.com