Che cos'è la gestione dei difetti? Severità, priorità e gli stati intermedi

La gestione dei difetti è ciò che accade a un bug tra il momento in cui qualcuno lo nota e quello in cui qualcuno conferma che è sparito. È un processo, non uno strumento: gli stati che un difetto attraversa, chi lo fa avanzare e come il team decide quali correggere per primi.

La maggior parte dei team ne ha uno, che l’abbiano scritto o no. La versione non documentata è di solito “mettilo nel tracker e spera”, e funziona finché i difetti non diventano più di quanti chiunque riesca a tenere a mente - tipicamente una trentina.

Il ciclo di vita

Gli stati hanno nomi diversi nei diversi tracker, e la forma sottostante è la stessa.

• Nuovo. Segnalato, nessuno lo ha ancora guardato.
• Triato. Qualcuno lo ha letto, ha confermato che è reale e ha deciso quanto è urgente.
• Assegnato. Ha un responsabile.
• Corretto. Il responsabile crede che sia fatto. Nessun altro crede ancora niente.
• Verificato. Qualcuno che non è il responsabile lo ha confermato rispetto alla segnalazione originale.
• Chiuso. Finito.

Ci sono altri due finali legittimi e spesso gestiti male. Respinto significa che non è un difetto: il comportamento è voluto, oppure la segnalazione descriveva un fraintendimento. Rimandato significa che è reale e che non viene corretto adesso. Entrambi richiedono una motivazione scritta nel ticket, perché l’alternativa è che lo stesso difetto venga segnalato di nuovo fra sei settimane da qualcuno che non ha modo di sapere che era già stato valutato.

Il passaggio che i team saltano in silenzio è la verifica. Un difetto chiuso dalla persona che lo ha corretto è un difetto chiuso sull’opinione di una persona sola, e la correzione che in realtà non copriva il caso segnalato è un’esperienza abbastanza comune da avere un suo problema di riproduzione.

Severità e priorità non sono la stessa cosa

Questa è la confusione che vale la pena chiarire, perché genera discussioni che sembrano disaccordi sul difetto ma in realtà sono due persone che usano una parola per due idee.

La severità è quanto è grave il comportamento. La perdita di dati è grave. Un’icona disallineata no. È una proprietà del difetto stesso e non cambia perché è cambiato il calendario.

La priorità è quanto presto viene corretto. Questa è una decisione di business, e dipende da chi è colpito, da quanti, dall’esistenza di una soluzione temporanea e da che altro si contende la stessa settimana.

Le due si separano in entrambe le direzioni, ed è questo che rende utile distinguerle:

Severità alta, priorità bassa

Un crash in una schermata di amministrazione usata due volte l'anno da una persona che conosce la soluzione temporanea

Severità bassa, priorità alta

Il nome dell'azienda scritto male sulla pagina dei prezzi, visto da tutti, corretto stamattina

I tracker che offrono un solo campo costringono a mediare le due cose in un numero che non significa nessuna delle due. Se il vostro fa così, dite quale delle due intende e mettetelo per iscritto, perché altrimenti metà del team ordina per danno e l’altra metà per urgenza.

Chi fa il triage, e ogni quanto

Il triage è una decisione, quindi serve qualcuno a cui è permesso prenderla. In un team piccolo è una persona che ogni mattina scorre la coda dei nuovi. In uno più grande è un breve incontro ricorrente con uno sviluppatore, un tester e qualcuno che parla per il prodotto.

Più del formato conta che sia regolare. Una coda triata quando qualcuno se ne ricorda accumula una coda di difetti che nessuno ha letto, e il costo non è la coda intoccata: è che nessuno si fida più della coda, così quelli veri vengono segnalati in chat.

Il triage richiede tre risposte per difetto, e non di più: è reale, quanto è grave, di chi è. Qualsiasi cosa più lunga è lavoro di progettazione che avviene nella riunione sbagliata.

Le segnalazioni decidono la velocità del processo

Ogni stato dopo “nuovo” dipende da quanto era buona la segnalazione.

Il triage non può giudicare la severità senza sapere cosa è successo davvero. Il responsabile non può correggere ciò che non riesce a riprodurre. La verifica non può confermare nulla se i passi originali non sono più scritti. Una segnalazione vaga non costa semplicemente i cinque minuti di chi la scrive: costa un giro di andata e ritorno a ogni fase, e ogni giro è un giorno.

È qui che se ne va la maggior parte del tempo. Non nel correggere, nel chiedere di nuovo.

La nostra guida alla segnalazione di bug ha la forma che sopravvive al triage: cosa è successo, cosa ci si aspettava, i passi e l’ambiente. Chiedete queste quattro cose e la maggior parte dei giri di andata e ritorno smette di accadere.

Metriche che ingannano

Tre numeri vengono contati perché sono facili da contare, e ognuno va letto con attenzione.

• Numero di difetti aperti. Sale quando il testing migliora, che è l’opposto di quello che sembra. Se scende a zero, più spesso significa che le persone hanno smesso di segnalare, non che il software sia migliorato.
• Difetti per sviluppatore. Premia chi tocca meno codice. Non fatelo.
• Tempo di chiusura. Utile, ma misura il processo tanto quanto il lavoro: una settimana passata ad aspettare che chi ha segnalato risponda a una domanda conta come una settimana di debug.

Quella che vale la pena guardare è invece il tasso di riapertura: i difetti segnati come corretti che sono tornati. È una misura diretta di quanto “corretto” significhi qualcosa nel vostro team e, a differenza delle altre, è difficile da aggirare.

La versione breve

Sei stati, una motivazione scritta per tutto ciò che è respinto o rimandato, e una verifica fatta da qualcuno diverso da chi ha corretto. La severità è quanto è grave, la priorità è quanto presto, e sono campi diversi. Triage a intervalli fissi invece che quando qualcuno se ne ricorda. E la maggior parte del tempo risparmiato si risparmia all’inizio, nella segnalazione: un difetto che arriva completo attraversa tutto il processo senza che nessuno debba fare una domanda.