Stima della affidabilità di un test instabile
Come stimare un test instabile: perché occorrono due stime, anziché una sola, e perché fissare un limite di tempo è preferibile a discutere sui punti quando la risposta dipende da ciò che si riscontra.
Un test inaffidabile consiste in due stime. Non si sa ancora quale delle due sia quella corretta.
Una versione prevede una correzione di una sola riga: un’ipotesi relativa alla temporizzazione, una dipendenza dall’ordine dei test, un elemento mancanteawait. L’altra versione richiede tre giorni di analisi approfondita di una condizione di competizione nel codice di produzione che il test è riuscito a individuare per caso. Quando le carte vanno dal numero 2 al 13, il team non è in disaccordo sulla dimensione. È in disaccordo su che tipo di bug si tratti, che è l’effettiva incognita.
Fare una stima per capire quanto sia grande un problema, anziché farlo a posteriori, è il motivo per cui questa storia si è conclusa con il numero 5 nella prima settimana e con il numero 13 nella terza. La soluzione non sta in un dato più preciso, ma in un approccio diverso al lavoro. Definite un intervallo di tempo per l’analisi, quindi stimare la soluzione effettiva una volta che ne si conosca la portata.
Ciò che viene detto nella sala
Ingegnere A: «Se il problema è dovuto al motivo che immagino, questo è un 2.»
Ingegnere B: “Se il problema è dovuto al motivo che io immagino, è un 13.”
Introduzione: “Qualcuno l’ha effettivamente eseguito in locale con il seme fissato?”
QA: “Il test fallisce solo nella CI. Mai su una macchina di sviluppo.”
Domande da porsi prima di votare
- Il problema si ripresenta in ambiente locale o solo nell’ambiente di integrazione continua (CI)?
- Con quale frequenza si verifica un guasto: 1 volta su 50, 1 volta su 5, una volta su due?
- Quando ha iniziato a non funzionare più? In quale commit?
- Il test è errato, oppure sta rilevando qualcosa di reale?
- C’è qualcuno che nel frattempo lo sta disattivando, e a quale costo?
Il divario tra l’ingegnere A e l’ingegnere B non è una divergenza sui story-points che si possa appianare calcolando una media. Si tratta di un’incognita da approfondire. Un breve spike con limite massimo lo colma; una discussione più accesa no.
Stabilite un intervallo di tempo, non una soluzione definitiva. Mezza giornata per indagare, poi un articolo vero e proprio su qualunque cosa scopriate.
Si veda la stima di un bug non riproducibile per un caso analogo e gli errori comuni nel Planning Poker per la stima dei bug con precisione a livello di funzionalità. Si consultino gli altri esempi di stime già elaborati oppure si avvii una sessione gratuita di Planning Poker una volta ottenuto il risultato dell’analisi.