Gestione di bug e storie in JIRA

Non sono sicuro che ci sia una "risposta giusta" a questo, ma anche se potresti non sapere quanto tempo ci vorrà per correggere un bug, probabilmente saprai quanto a lungo sarai disposto a spenderlo ( spenderesti 1SP? Sicuramente, spenderesti 100SP? Solo se il bug è "tutti i dati sono andati bene").

Quindi puoi assegnare punti storia che rispondono "da quanto tempo sono disposto a esaminare questo bug fino a quando non viene risolto o ne so di più?". Dì 4SP. I risultati quindi sono:

• Ci sono voluti 4SP: fantastico, tutto è perfetto e tu sei il Guru di tutte le stime

• Ci sono voluti 1SP - ottimo, aggiustare retroattivamente la stima SP o semplicemente tirare avanti un'altra storia per compensare.

  • Dopo 4SPs ti rendi conto che ci vorranno altri 20SP per correggerlo correttamente. Si apre un ticket per la correzione effettiva (che si sa di cosa si tratta) e lo si pone come blocco per il ticket del bug. Quando ciò è fatto, puoi chiudere entrambi. Oppure, se il tuo processo lo consente, puoi regolare gli SP sul bug originale fino a 20 e ricaricare lo sprint dello sviluppatore.

Esistono alcune situazioni di segnalazione che non consentono la regolazione retroattiva dei punti storia, ma a meno che non ci si trovi in una di queste, non vi è alcun motivo per non approfittare della flessibilità.

Ci sono molte opzioni qui. In definitiva, devi scoprire cosa funziona per te e il tuo team.

La mia opinione è che le storie e i bug dovrebbero essere compiti di primo livello. JIRA supporta il possesso di tipi di ticket e la concessione di diversi tipi di ticket a diversi campi associati a loro, nonché a diversi flussi di lavoro. Storie e bug possono avere o meno un flusso di lavoro diverso, ma sospetto che sarebbe simile, se non identico.

Per i bug, avrei un tipo di ticket di Bug o Defect. Questo ticket verrà assegnato a uno sviluppatore per risolvere e testare se necessario. Dopo che è stato corretto, e i test delle unità sono stati aggiornati, ciò che accade dipende dal tuo processo. Se hai un team di test indipendente, quella squadra dovrebbe anche considerare correzioni di bug e nuove storie. Se la nuova funzionalità viene sottoposta a test di accettazione, dovrebbero esserci test di accettazione associati alla correzione del bug.

Il pensiero di riaprire un bug chiuso è sbagliato per me. Una volta che uno sviluppatore ha corretto un bug e la correzione è stata completamente testata, accettata e rilasciata / implementata, il ticket non dovrebbe mai essere riaperto. Se è necessaria un'altra modifica, è necessario aprire un nuovo ticket per rappresentare un problema di funzionalità o nuove funzionalità necessarie.

In situazioni come questa, di solito mi pongo una serie di domande come:

• Come stimeremo una nuova storia aggiunta per un bug?
• Come faremo QA e pubblicheremo un nuovo bug non allegato a una storia?
• Come terremo traccia dei nuovi bug introdotti dalla correzione del bug?

Riferimenti

• I difetti devono essere considerati User Stories ? - Scrum Alliance

• Un caso di studio nella ricerca delle radici architettoniche del debito tecnico