Valutazione di un bug senza possibilità di riproduzione
Come valutare un bug per il quale non è possibile riprodurre il problema: non è possibile quantificare la portata della correzione, ma solo quella della ricerca. Come definire un limite di tempo per l’indagine invece di votare su una story che nessuno può vedere.
Se non riuscite a riprodurlo, non potete stimarlo. Potete stimarlo solo cercandolo.
Un bug che non è possibile riprodurre è costituito da due incognite racchiuse in un unico ticket. La prima incognita è la causa: in produzione si manifesta un sintomo, ma non esiste un modo affidabile per riprodurlo localmente, né una traccia dello stack coerente, né una riga nei log che lo preceda sistematicamente. La seconda incognita è la correzione, che dipende interamente dalla prima. Assegnare un punteggio alla correzione prima che se ne conosca la causa equivale a votare una storia che il team non può effettivamente vedere.
Una volta individuata la causa, la soluzione non è sempre difficile: spesso basta modificare una sola riga di codice. La parte costosa è proprio l’individuazione del problema. La stima dei tempi di ricerca è realistica; quella relativa alla soluzione è invece ottimistica.
Ciò che viene detto nella stanza
Ingegnere A: «Credo che si tratti dell’invalidazione della cache.»
Ingegnere B: «Credo che sia una questione di attitudine del lavoratore.»
Introduzione: “Qualcuno è riuscito a realizzarlo su richiesta?”
Domanda: «Abbiamo provato venti soluzioni diverse. Nessuna si è rivelata affidabile.»
Assistenza: «Si tratta di tre utenti alla settimana, sempre il martedì pomeriggio.»
Domande che vale la pena porsi prima di votare
- Qual è il sintomo e con quale frequenza si manifesta?
- Abbiamo già attivato la registrazione sui percorsi sospetti, oppure dobbiamo prima aggiungerla?
- Esiste un cliente con un account notoriamente difettoso su cui possiamo riprodurre il problema?
- Qual è il costo settimanale di questo bug per il cliente? E tale costo giustifica un’analisi approfondita?
- Qual è il termine previsto per l’indagine prima di riesaminare la questione?
Due teorie ben definite e nessuna riproducibilità non sono un dato su cui basarsi: si tratta di una ricerca da finanziare. Assegnatele un budget e fissate una scadenza, quindi rivalutate la situazione una volta che la causa avrà un nome.
Stabilite un budget per la ricerca. Quando la causa ha un nome, valutate autonomamente la soluzione.
Si veda Come stimare un test inaffidabile per lo stesso caso, e Errori comuni nel Planning Poker riguardo alla stima dei bug con precisione a livello di funzionalità. Si consultino gli altri esempi pratici di stima, oppure si avvii una sessione gratuita di Planning Poker quando la causa è nota.