Correggere i bug in modo rapido e semplice

La correzione dei bug era già una sfida nello sviluppo software prima di Scrum. Le iterazioni brevi in Agile non rendono necessariamente più facile per i team decidere quali bug devono essere corretti e quali possono ancora aspettare.

La buona notizia è che uno Scrum Team normalmente ha molti meno bug rispetto a un team che lavora con framework di sviluppo più tradizionali. Ma anche i team agili trovano di tanto in tanto qualche bug, specialmente se parte dello sviluppo risale al periodo precedente all'adozione dell'approccio agile. E per dare priorità a questi difetti, il team ha bisogno di una soluzione efficace.

Prioritizzazione delle correzioni di bug: cosa non fare

All'inizio della mia carriera come programmatore, il mio capo mise l'intero team a lavorare per una settimana per discutere di tutti i difetti conosciuti. Parlammo delle possibili cause, della gravità di ogni singolo bug, della frequenza con cui si verificava, se poteva essere riprodotto, dove nel codice poteva trovarsi l'errore e chi di noi avrebbe dovuto risolvere il problema.

Stimammo persino quanto tempo ci sarebbe voluto per ogni bug. Queste stime nella maggior parte dei casi non solo erano piuttosto inutili, ma ci volle più tempo per fare la stima che per correggere semplicemente il bug.

Quando, dopo queste prime esperienze, iniziai a guidare dei team, cominciai a sperimentare con altri approcci più leggeri.

Oggi voglio presentare il mio metodo preferito per la correzione dei bug.

Linee guida per la prioritizzazione dei bug

Invece di prendersi il tempo per riflettere su ogni singolo bug, è meglio creare delle linee guida che stabiliscano quanto velocemente un bug debba essere corretto e quanto sia alto l'impatto del difetto quando si verifica.

Esempio 1: Una di queste linee guida potrebbe essere che ogni bug che influisce drammaticamente su tutti gli utenti deve essere corretto immediatamente, ovvero che i lavori in corso nello Sprint vengano interrotti. Un'altra linea guida potrebbe stabilire, ad esempio, che i bug che si verificano estremamente di rado e non impediscono all'utente di eseguire le funzioni più importanti vengano documentati e corretti senza fretta quando c'è tempo.

Creare e utilizzare linee guida viene anche chiamato prioritizzazione per policy (prioritization by policy).

Esempio 2: Un esempio più concreto potrebbe essere quando il Product Owner e il suo team concordano che ogni bug che impedisce agli utenti di effettuare ordini sulla loro pagina e-commerce debba essere corretto il prima possibile.

Altre linee guida possono riferirsi a bug che devono essere corretti solo alla fine della giornata, alla fine della settimana o addirittura per nulla.

Definire le linee guida per i difetti

Per formulare le linee guida di correzione dei bug sono utili le seguenti considerazioni:

• Probabilità di un difetto: con che frequenza si verifica il problema?
• Gravità di un difetto: quanto è grave quando il problema si verifica?

Immagina che su Amazon ci sia un bug che impedisce di effettuare ordini con un valore di 1 milione di dollari, perché uno sviluppatore ha presupposto che un ordine non superi mai un valore di 999.999,99 dollari.

È grave quando ciò accade (alta gravità), ma penso che Amazon non riceva molti ordini superiori a 1 milione di dollari (bassa probabilità).

Creazione della matrice delle linee guida per i difetti per prioritizzare i bug

Le due dimensioni – gravità e probabilità – possono essere combinate per stabilire la linea guida di priorità per un difetto. Una matrice come questa può aiutare:

Ci sono molti modi per classificare la probabilità e la gravità dei bug. Nell'esempio della pagina e-commerce, la probabilità viene espressa con la percentuale di transazioni interessate. Tutto ciò che influisce sul 10% o più delle transazioni è piuttosto importante, quindi ho impostato l'intera colonna su priorità alta o molto alta.

Per misurare la gravità di un difetto si può considerare se esiste una soluzione alternativa e se è ovvia o difficile da trovare. Su una pagina e-commerce, ad esempio, potrebbero esserci due pulsanti "Acquista ora" ma solo uno di essi funziona.

Le celle della matrice mostrano quale linea guida si applica per difetti con una determinata probabilità e gravità. In questo esempio ho scelto cinque diversi livelli di priorità – da molto bassa a molto alta. In alcuni casi, tre livelli possono essere sufficienti. Sconsiglio più di cinque, anche se l'ho già visto fare.

Ecco come utilizzo i cinque livelli di priorità:

• Molto alta: Viene inserito immediatamente nell'iterazione in corso, anche se ciò significa che altri lavori restano in sospeso. Potrebbe richiedere più di un membro del team, eventualmente anche l'intero team.

• Alta: Viene inserito immediatamente nell'iterazione in corso, anche se ciò significa che altri lavori restano in sospeso. Il team decide chi può risolvere meglio il problema.

• Media: Può essere inserito nell'iterazione in corso a discrezione del Product Owner.

• Bassa: Viene documentato e discusso nel prossimo Planning Meeting a discrezione del Product Owner.

• Molto bassa: Viene documentato nella lista dei problemi noti. Viene ripreso solo se cambiano la probabilità o la gravità, oppure a discrezione del Product Owner.

Vantaggi della prioritizzazione tramite linee guida

Il principale vantaggio di questo approccio è che si dedica notevolmente meno tempo a discutere cosa fare con ogni singolo difetto. Questo tipo di prioritizzazione dei bug richiede inizialmente un certo impegno per creare le linee guida. Tuttavia, una volta create, la prioritizzazione di nuovi difetti diventa un gioco da ragazzi.

L'obiettivo di questo approccio è rendere la prioritizzazione dei difetti una questione più oggettiva che soggettiva. Naturalmente, qualcuno dovrà decidere con quale frequenza un problema si verificherà probabilmente, ma a parte questo, la prioritizzazione stessa non richiederà più tempo di quanto ne serva per guardare la matrice di prioritizzazione.

Questo articolo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.

Formazione Product Owner

=> Diventa un Product Owner certificato e partecipa a una delle nostre formazioni

Requisiti non funzionali

=> Scopri come trasformare i requisiti non funzionali in User Stories.

Product Scorecard

=> Scopri se il tuo prodotto contribuisce alla strategia aziendale e utilizza la Product Scorecard.