Gestione dei bug in Scrum

Tutte le domandeCategoria: Gestione progettoGestione dei bug in Scrum
Luca G chiesta 4 mesi fa

Forse è una domanda stupida… Ma se arrivano dei bug nel mezzo dello sprint, che cosa si fa? Qual è il modo migliore per gestirli?

Saluti.

4 Risposte
Franco Staff risposta 4 mesi fa

Ciao! Figurati, non è per niente una domanda stupida, anzi è un argomento molto discusso e per cui non è semplice trovare un equilibrio.

Scrum non dà alcuna indicazione precisa su come gestire i defect, ma sulla guida ufficiale viene detto chiaramente che tutto ciò che ha un impatto sul prodotto deve essere aggiunto al product backlog. Il problema però resta. Quanto è urgente il bug? Che impatto ha sul prodotto e sugli utenti? Deve essere risolto subito?

In linea di principio, ogni bug dovrebbe essere aggiunto al product backlog e priorizzato. Ma come già detto, e come spesso accade in Scrum… Dipende!

Il mio suggerimento di buon senso è di risolvere un defect il prima possibile. Se fattibile, durante l’iterazione in corso, se non impatta e non compromette lo Sprint Goal. Altrimenti, è una valutazione che il product owner deve effettuare in base a parametri di business. Per esempio: ha un "costo" maggiore ritardare la risoluzione del bug, oppure ha un "costo" maggiore rivedere lo scope dello sprint in corso?

Spero di non averti messo ulteriori dubbi

Saluti,

Franco

Aardvark risposta 4 mesi fa

Nella mia vecchia azienda, oltre al normale backlog, avevamo una kanban board dedicata ai bug. Se il cliente trovava un bug lo gestivamo con kanban, così da lavorare sia sullo sprint che sui bug. Solo una parte del team lavorava a tempo pieno su kanban.

Magari anche questo potrebbe essere un approccio? Per noi funzionava e il cliente era contento!

Franco Staff risposta 4 mesi fa

Se funziona nel tuo contesto e il cliente è soddisfatto, perché no. Ma c’è il rischio che diventi una scorciatoia per aggiungere lavoro non pianificato allo sprint.

Solo una curiosità, perché così tanti bug da giustificare la creazione di un sub-team e di un processo a parte?

Aardvark risposta 4 mesi fa

Una pessima qualità del software e la quasi inesistenza di pratiche di test automatizzati e deploy. Ogni volta che rilasciavamo incrociavamo le dita, roba da infarto!