Quanti bug aperti hai nel tuo backlog? 100? 1000?
E da quanto tempo sono lì? Una settimana? Un mese? Anni?
Perché succede questo? Non c'è tempo? Devi affrontare priorità più alte? «Stiamo realizzando tutte le funzionalità urgenti adesso, e poi ci sarà sicuramente tempo per sistemare i bug»?

… Alcuni utilizzano la Zero Bug Policy, altri hanno una buona cultura del lavoro con i bug (aggiornano tempestivamente il backlog, rivedono gli errori quando cambia la funzionalità, ecc.), e c’è chi forma dei maghi che sviluppano senza bug (improbabile, ma forse accade anche questo).

Oggi ti parlerò della nostra soluzione per pulire il backlog dei bug — il progetto «Bug House».

Come è iniziato tutto?

Dopo aver esaminato ancora una volta il backlog sempre più crescente di bug aperti, siamo arrivati al punto di non ritorno. Non era più possibile vivere così, abbiamo deciso di ridurlo a qualsiasi costo. L'idea è ovvia, ma come farlo? Abbiamo convenuto che il modo più efficace sarebbe stato un evento simile a un hackathon: staccare i team dalle attività quotidiane e dedicare 1 giorno lavorativo solo al trattamento dei bug.

Abbiamo stabilito un regolamento, lanciato un appello e aspettato. C'erano timori che ci sarebbero state poche adesioni, molto poche, ma il risultato ha superato le nostre aspettative: si sono registrate ben 8 squadre (anche se, all'ultimo momento, 3 si sono ritirate). Per l'evento abbiamo riservato un'intera giornata lavorativa di venerdì e prenotato una grande sala riunioni. Per i pranzi ci siamo organizzati con la mensa dell'ufficio e per gli spuntini abbiamo aggiunto dei biscotti.

Implementazione

La mattina del giorno X abbiamo radunato tutti gli interessati nella sala riunioni e abbiamo condotto un briefing breve.

Regole principali:

• in una squadra combattono da 2 a 5 persone, almeno uno di loro deve essere un QA;
• i bug devono essere chiusi da un membro della squadra secondo tutti gli standard interni di produzione;
• ogni squadra deve avere almeno un bug chiuso, che richieda correzioni nel codice;
• si possono correggere solo bug vecchi (data di creazione del bug < data di inizio della Bug-a-thon - 1 mese);
• per i bug corretti vengono assegnati punti (da 3 a 10) a seconda della gravità (per evitare imbrogli, non è possibile modificare la gravità dopo l'annuncio della data della Bug-a-thon);
• per la chiusura di bug non pertinenti e non riproducibili viene assegnato 1 punto.
• Il team di audit si occupa di garantire il rispetto di tutte le regole, annullando i punti per i bug riaperti.

Ulteriori dettagli

• Non abbiamo limitato nessuno nella scelta della posizione: era possibile rimanere al proprio posto di lavoro o sedersi insieme a tutti nella sala riunioni, dove i ragazzi non venivano disturbati e si sentiva la tensione della competizione.

• Per supportare lo spirito competitivo, è stata visualizzata una classifica sul grande schermo, e nel canale Slack si svolgeva costantemente una trasmissione testuale della battaglia. Per il conteggio dei punti è stato utilizzato un leaderboard, aggiornato tramite webhook.

Leaderboard

• Il team di audit si è occupato del rispetto di tutte le regole (in base all'esperienza, bastano 1-2 persone per questo).
• Un'ora dopo la conclusione della Bugathon sono stati annunciati i risultati verificati.
  I vincitori hanno ricevuto un buono per un bar, e tutti i partecipanti un souvenir commemorativo (portachiavi con 'bug').

Risultati

Negli ultimi sei mesi abbiamo già realizzato tre Bugathon. Cosa abbiamo ottenuto alla fine?

• Numero medio di squadre: 5.
• Numero medio di bug elaborati: 103.
• Percentuale media di bug non pertinenti/non riproducibili: 57% (eppure questa spazzatura ci infastidiva costantemente per la sua quantità).

Momento di annuncio dei risultati

E adesso la risposta alla domanda più insidiosa, che tutti amano porre: «Quanti nuovi bug avete introdotto?».
Risposta: non più del 2% di tutti quelli elaborati.

Recensioni

Dopo il Bugathon abbiamo raccolto feedback dai partecipanti. Ecco le risposte alla domanda «Cosa è piaciuto di più nel processo di partecipazione?»:

• È davvero fantastico esaminare il backlog con una tale motivazione! Di solito è un processo piuttosto noioso, bisogna farlo periodicamente).
• Entusiasmo, biscotti.
• È un'opportunità tanto attesa per sistemare quelle piccole cose che non sono critiche, ma si desidera comunque correggere.
• Mi è piaciuto poter finalmente risolvere vecchi bug sgradevoli al di fuori dello sprint, per questi non ci sarà mai tempo perché ci saranno sempre compiti di priorità superiore. Siamo riusciti a riunire tutti i membri chiave (nella nostra squadra c'era un DBA, per esempio), abbiamo discusso collettivamente l'attualità dei bug segnalati e la possibilità tecnica di correggerli.

Conclusione

La Bug Factory non è una panacea, ma è una soluzione praticabile per ridurre il backlog dei bug (tra il 10 e il 50% in diverse squadre) in un solo giorno. Da noi, questo evento ha avuto successo solo grazie a ragazzi motivati che sono appassionati del prodotto e si prendono cura della felicità dei nostri utenti.

A tutti buona fortuna e meno bug!

Fonte: habr.com