Stima di un bug segnalato da un cliente
Come valutare un bug segnalato da un cliente: è l’account indicato nel ticket a determinare l’entità del problema. Come distinguere una correzione di una sola riga da una risposta che comporta il rinvio dello sprint.
Il problema non è la dimensione. È il cliente che è di quelle dimensioni.
Un bug segnalato da un cliente comporta una portata che il team non è in grado di cogliere solo dal ticket. La correzione tecnica potrebbe consistere in una sola riga di codice. Tuttavia, il lavoro correlato rappresenta spesso la parte più consistente dell’intervento: riprodurre il problema sui dati del cliente, redigere un’analisi post mortem, stendere la risposta, decidere se accreditare l’account, comunicare con gli altri clienti interessati. Nulla di tutto ciò è riportato nel ticket. Tutto ciò rallenta la velocità di elaborazione.
Si devono stimare due aspetti: la correzione e la risposta. La correzione rientra nel normale “planning poker”. La risposta, invece, è un concetto poco familiare ai team di ingegneri e viene sistematicamente sottostimata; ecco perché i bug segnalati dai clienti sembrano protrarsi per tutto lo sprint anche quando il voto sul mazzo di carte è risultato basso.
Ciò che viene detto nella sala
Backend: “La correzione consiste in una sola riga.”
Primo Ministro: «Quale fonte lo ha riportato?»
Assistenza: “Il loro responsabile del servizio clienti (CSM) richiede un’analisi delle cause alla radice (RCA) entro venerdì.”
Responsabile: “Ci sono altri clienti coinvolti? Dobbiamo inviare loro un’e-mail?”
Domanda di controllo qualità: “È possibile riprodurre il problema utilizzando i loro dati, oppure è necessaria un’esportazione con dati anonimizzati?”
Domande da porsi prima di votare
- Chi ha segnalato il problema e quali sono i relativi valori di ARR, SLA o lo stato del contratto?
- È necessario effettuare una valutazione RCA o un’analisi post mortem a livello esterno?
- Ci sono altri account coinvolti e come possiamo scoprirlo?
- È necessario concedere un credito, effettuare un rimborso o prorogare il periodo di prova?
- Chi redige la risposta destinata al cliente, e tale risposta è contenuta in questo ticket?
- Riproduzione: dati del cliente, dump anonimizzato o dati sintetici?
Splitting è utile: la correzione è un ticket, la risposta è un altro. Entrambi passano attraverso il planning poker; solo uno dei due è di natura tecnica.
Si prega di fornire una stima separata per la correzione e per la risposta. È il nome dell’account a determinare l’entità della risposta.
Si veda errori comuni nel Planning Poker per quanto riguarda le modalità di fallimento del voto su attività che non rientrano nelle responsabilità del gruppo. Si consultino gli altri esempi di stime efficaci, oppure si avvii una sessione gratuita di Planning Poker con entrambe le storie pronte.