I modi migliori per inserire la correzione dei bug in un processo Scrum? [chiuso]

Negli ultimi giorni ho studiato e letto di Scrum e ho letto di Sprint Planning e delle attività. Un problema che mi è venuto in mente è come affrontare i bug in Scrum. Henrik Kniberg elenca alcuni modi per affrontare questo problema nel suo bellissimo libro Scrum and XP from the Trenches :

1. Il product owner stampa gli elementi Jira con la priorità più alta, li porta allo sprint planning meeting e li mette sul muro insieme alle altre storie (specificando così implicitamente la priorità di questi elementi rispetto alle altre storie).
2. Il proprietario del prodotto crea storie che fanno riferimento agli articoli Jira. Ad esempio "Risolvi i bug di segnalazione back office più critici, Jira-124, Jira-126 e Jira-180".
3. La correzione dei bug è considerata al di fuori dello sprint, ovvero il team mantiene un fattore di concentrazione sufficientemente basso (ad esempio il 50%) per assicurarsi di avere il tempo di correggere i bug. Si presume quindi semplicemente che il team impiegherà una certa quantità di tempo a ogni sprint per correggere i bug segnalati da Jira
4. Metti il ​​backlog del prodotto in Jira (cioè fosso Excel). Tratta gli insetti come qualsiasi altra storia.

È davvero qualcosa che deve essere deciso in base al progetto o ci sono soluzioni migliori? Posso pensare a problemi con ciascuno di questi approcci. C'è un ibrido proveniente da quegli approcci che funziona meglio? Come gestisci questo nei tuoi progetti?

Questa è un'ottima domanda e ho alcune osservazioni quando si tratta di approcci diversi a questo problema.

1. Trattare tutti i bug allo stesso modo con gli elementi del backlog potrebbe sembrare una buona idea in teoria (lavoro tracciato in un unico posto) ma non funziona bene nella pratica. I bug sono generalmente di basso livello e più numerosi, quindi se crei una storia utente individuale per ogni bug, le storie "reali" verranno presto oscurate.
2. Il tempo esplicito in ogni sprint riservato alle correzioni va bene se fatto in modo visibile per il proprietario del prodotto. I bug dovrebbero essere menzionati durante la mischia quotidiana e la discussione sui bug corretti dovrebbe verificarsi durante la revisione dello sprint. Altrimenti il ​​proprietario del prodotto non sarà a conoscenza di cosa sta succedendo nel progetto.
3. Mettere l'intero backlog nello strumento di tracciamento dei bug porta alla stessa serie di problemi come in 1. Inoltre la maggior parte dei tracciatori di bug non sono progettati con Scrum in mente e usarli per questo scopo può essere doloroso.

La soluzione che abbiamo trovato più soddisfacente è stata quella di inserire una singola user story chiamata "Ticket" o "Bugs" in ogni sprint. Quindi una storia del genere può essere suddivisa in attività di basso livello che descrivono un bug particolare (se noto durante la pianificazione) o in meta-attività riservando un determinato numero di ore per la correzione generale di bug. In questo modo il proprietario del prodotto ha visibilità nel processo e il grafico di burndown riflette l'avanzamento.

Ricorda solo di chiudere senza pietà tutti i "bug" che in realtà sono nuove funzionalità e creare nuovi elementi di backlog per loro. Assicurati anche di correggere tutti i bug segnalati rispetto allo sprint corrente prima che lo sprint sia finito, in modo da considerare lo sprint come fatto.

In realtà penso che la risposta migliore sia jpeacock a questa domanda. Conti le ore spese per la correzione dei bug verso lo scrum?

Lasciatemelo citare:

• Se il bug è facile / veloce da risolvere (una riga, ecc.), Risolverlo.
• Se il bug non è banale e non è un blocco, aggiungilo al backlog.
• Se il bug è un blocco, aggiungi un'attività (allo sprint corrente) per acquisire il lavoro richiesto per risolverlo e inizia a lavorarci. Ciò richiede che qualcos'altro venga spostato (dallo sprint corrente) al backlog per tenere conto delle nuove ore perché le ore totali disponibili non sono cambiate.

Il primo passo è definire cos'è un bug. Insegno che un bug è un bug solo se è una funzionalità che non funziona in produzione come è stato inteso / progettato. Questi diventano PBI di tipo bug a cui dare la priorità rispetto al nuovo sviluppo. La funzionalità mancante nella produzione è una caratteristica e diventa un normale elemento del backlog di prodotto. Qualsiasi codice difettoso rilevato durante uno sprint è considerato lavoro incompleto e poiché non si passa alla storia successiva fino a quando non si è terminato quello corrente; non è necessario tenere traccia di questi difetti nello sprint poiché il team lavora sempre sul codice offensivo. I post-it possono essere molto utili qui per rapidi promemoria tra i compagni di squadra. La correzione del codice danneggiato ha sempre la precedenza sulla scrittura di nuovo codice.

L'inventario è uno spreco. Il monitoraggio dei bug è l'inventario. Il monitoraggio dei bug è uno spreco.

Trattare tutti i bug allo stesso modo con gli elementi del backlog potrebbe sembrare una buona idea in teoria (lavoro tracciato in un unico posto) ma non funziona bene nella pratica. I bug sono generalmente di basso livello e più numerosi, quindi se crei una storia utente individuale per ogni bug, le storie "reali" verranno presto oscurate.

Se hai molti più bug che funzionalità, devi lavorare sulle tue pratiche di ingegneria. Questo è un odore che qualcos'altro non va e il monitoraggio non è la risposta. Scava più a fondo. In realtà gli insetti sono sempre puzzolenti. Non sono belli e se ne hai molti devi trovare le cause alla radice, eliminarli e smettere di concentrarti sul monitoraggio dei bug.

Non tenere traccia dei difetti in un elenco, trovali e correggili: Mary Poppendieck

Infatti, se l'inventario è uno spreco, che ne dici di un inventario dei difetti ...

Ecco perché cerco sempre di implementare una mentalità Stop-the-Line con sviluppo basato sui test e integrazione continua, in modo da trovare e correggere la maggior parte dei difetti invece di inserirli in un elenco di rilavorazioni.

E quando i difetti passano, li correggiamo prima di scrivere nuovo codice (le storie con bug non vengono fatte comunque). Quindi, proviamo a correggere il nostro processo per renderlo più a prova di errore e rilevare i difetti nel momento in cui si verificano.

Non esiste una soluzione adatta a tutte le dimensioni e ogni progetto è diverso. I bug potrebbero anche essere classificati da mission critical a difficilmente vale la pena risolverli.

A meno che non siano critici per il funzionamento del sistema, preferisco che i bug diventino delle story card. Ciò rende la priorità dello sviluppo delle funzionalità rispetto alla risoluzione dei bug davvero esplicita. In uno scenario in cui le correzioni dei bug sono considerate "al di fuori dello sprint", la correzione dei bug potrebbe spostarsi verso la correzione di bug davvero banali mentre le funzionalità aziendali davvero importanti non vengono sviluppate.

Siamo passati attraverso una serie di permutazioni prima di impostare il bug come approccio alla storia. Prova alcune cose diverse e riproducile alle riunioni retrò della squadra.

Nel nostro caso (sviluppo greenfield, 2-3 sviluppatori) i bug trovati sono scritti, contrassegnati chiaramente come bug e in base alla loro gravità vengono assegnati alla successiva iterazione o lasciati nel backlog. In caso di bug critici e urgenti vengono aggiunti all'iterazione in corso.

Non so perché qualcosa di semplice come correggere i bug è complicato con le regole .. Scrum ha pochissime regole, ricordi? Ogni caratteristica, supporto, raccomandazione o difetto è un problema di backlog in Scrum, non c'è differenziazione. Quindi, come dice la guida Scrum: i compiti in uno Sprint non sono mai limitati a ciò che decidi durante la riunione di pianificazione, il Daily Scrum aiuta le persone a discutere gli "ostacoli" lungo il loro percorso.

Perché?

Quindi discuti e pensi razionalmente come una squadra se vuoi che il problema del difetto, cioè il backlog, vada in PBI o rimanga in questo Sprint e lo consegni ...

La domanda migliore è come smetto di creare bug in fase di sviluppo? vedi -> http://bit.ly/UoTa4n

Se stai identificando e documentando i bug dovrai triage e risolverli in un momento futuro. Questo porta a "sprint di stabilizzazione" cioè uno sprint intero solo per correggere i bug. Oppure puoi aggiungerli di nuovo al backlog e dare loro la priorità come parte di qualche sprint futuro. Significa anche che fornirai e ti aspetti di ottenere un software firmato e rilasciato con bug noti (P3 e P4 aka cosmetici e minori).

Questo non è davvero agile?

Ho presentato l'idea nel nostro progetto di introdurre un breve sprint di correzione di bug ogni terzo sprint. I nostri sprint attuali durano tre settimane.

L'idea è che consentirà a tutti gli sviluppatori di concentrarsi sulla risoluzione dei bug insieme, consentirà di concentrarsi solo su nuove storie in sprint regolari e si concentrerà regolarmente sulla riduzione del debito tecnologico.

Le correzioni di bug verranno raggruppate in storie pertinenti e prioritarie. L'enfasi non è sul dimensionamento prima dello sprint poiché gli sviluppatori faticano a correggere le correzioni dei bug senza rimanere bloccati per comprendere la natura del difetto.

Qualcuno l'ha provato o ha qualche feedback su come pensa che potrebbe funzionare?

Salute, Kevin.