Punti storia per le attività di correzione dei bug: è adatto per Scrum?

Mi chiedo solo se dovremmo assegnare o meno punti storia alle attività di correzione dei bug. JIRA, il nostro software di localizzazione dei problemi, non ha un campo di trama per problemi di tipo Bug (è solo per Story e Epic ).

Dovremmo aggiungere il tipo di problema Bug ai tipi di problema applicabili del campo Punti storia ? Quali sono i pro e i contro? Sarebbe adatto per Scrum?

Idealmente, il tuo software dovrebbe essere privo di bug dopo ogni iterazione e la correzione dei bug dovrebbe far parte di ogni sprint, quindi il lavoro richiesto per correggere i bug dovrebbe essere preso in considerazione quando si assegnano i punti della storia (cioè, un'attività che è più probabile che produca bug dovrebbe avere più punti storia assegnati ad esso).

In realtà, tuttavia, i bug emergono continuamente dopo l'implementazione, non importa quanto rigidi siano i test; quando ciò accade, la rimozione del bug è solo un'altra modifica, una funzione se lo desideri. Non esiste alcuna differenza fondamentale tra una segnalazione di bug e una richiesta di funzionalità in questo contesto: in entrambi i casi, l'applicazione mostra un determinato comportamento e l'utente (o qualche altro stakeholder) vorrebbe vederlo modificato.

Dal punto di vista aziendale, le correzioni e le funzionalità sono uguali, in realtà: o lo fai (scenario B) o no (scenario A); entrambi gli scenari hanno costi e benefici collegati e un uomo d'affari decente li soppeserà e andrà con qualunque cosa gli guadagni più profitto (a lungo o breve termine a seconda della strategia aziendale).

Quindi sì, in ogni caso, assegna i punti della storia ai bug. In quale altro modo darai la priorità ai bug rispetto alle funzionalità e ai bug rispetto ai bug? È necessario un certo sforzo di sviluppo per entrambi, ed è meglio che sia comparabile.

Il problema più grande è che le correzioni di errori sono spesso più difficili da stimare: il 90% o più dello sforzo reale consiste nel trovare la causa; una volta trovato, è possibile elaborare una stima accurata, ma è quasi impossibile giudicare quanto tempo richiederà la ricerca. Ho anche visto una buona dose di bug in cui la maggior parte del tempo è stata spesa solo cercando di riprodurre il bug. D'altra parte, a seconda della natura del bug, è spesso possibile restringere la ricerca con qualche ricerca minima prima di fare una stima.

Stimare i bug con punti è intrinsecamente difficile come già indicato in altre risposte e sì la soluzione ideale è che i bug trovati in una funzione DOPO che lo sprint sia stato accettato dovrebbero essere considerati nuove funzionalità .

Questa difficoltà nella stima puntuale dei bug è tuttavia una delle molte ragioni per cui i pacchetti software Agile PM consentono di stimare attività e bug in ore, perché ci vogliono abilità ed esperienza per diventare esperti alla stima puntuale. Molti progetti incontrano problemi significativi nel determinare correttamente la velocità, quindi molti progetti Agile utilizzano i punti per determinare quali storie fanno parte dello sprint, tuttavia usano le ore per il calcolo del grafico di burndown .

Sembra contro intuitivo ma gestibile fintanto che la stima delle ore non viene utilizzata come fattore nel determinare l'impegno dello sprint. L'eccessivo impegno porterà naturalmente a funzionalità o straordinari mancanti o incompleti, quindi nel tempo tutti i soggetti coinvolti sono costretti a migliorare nella stima puntuale, a quel punto la stima delle ore su attività e bug diventa lentamente una metrica insignificante.

Non dovresti dare punti alla risoluzione dei bug. Considera il fatto che il bug deriva da una storia in cui gli sviluppatori hanno già guadagnato punti per completare la storia. Non dovrebbe ricevere nuovamente punti in cui in realtà non avrebbe dovuto guadagnare i punti per cominciare.

La correzione dei bug dovrebbe avere un effetto negativo sulla velocità. Altrimenti, la caduta della qualità finisce per essere ricompensata con una velocità inalterata o addirittura aumentata!

Forse un link utile:

http://www.infoq.com/news/2011/01/story-points-to-bugs

Consiglierei di trattare il bug come una user story e di assegnargli un numero di punti. Non lo scriverei necessariamente nel formato "Come X, voglio Y in modo che Z" come è comune con le storie degli utenti - lo scriverei più come "Come X, quando accade IY, Z, ma Z 'è il comportamento previsto ".

Il vantaggio è che ti consente di dare la priorità alle correzioni di bug insieme alle nuove richieste di funzionalità. La verità è che a volte una nuova funzionalità è più importante della correzione di un bug. Tuttavia, ti consente anche di dimensionare correttamente il lavoro richiesto, permettendoti di adattarlo a uno sprint quando hai la possibilità di farlo.

Una cosa da tenere presente che potrebbe essere difficile stimare lo sforzo necessario per correggere un bug. Potrebbe coinvolgere più componenti che interagiscono tra loro, richiedendo a qualcuno di acquisire familiarità con le interazioni di grandi parti del sistema o che più persone lavorino alla correzione.

La stima delle storie si basa sull'idea che, con il tempo, una squadra guadagna esperienza nel risolverle. Con esso la precisione è migliorata e la velocità può essere stabilita per misurare la velocità di una squadra. Una metodologia perfetta per stabilire previsioni affidabili per gli sprint futuri.

I bug sono un dato di fatto per un'azienda di sviluppo software. Mentre sono d'accordo sul fatto che tutti i bug dovrebbero essere catturati durante lo sviluppo di una storia, accettando che ciò non può essere raggiunto in ogni momento, dovrebbe essere qualcosa che ogni squadra dovrebbe pianificare. Invece di pensare ostinatamente che il processo dovrebbe governare la squadra, dovrebbe essere il contrario.

Ovviamente, bug o storia, dal punto di vista commerciale non importa con cosa sta trattando il team. Entrambi possono produrre un valore uguale per il proprietario del prodotto.

Nel nostro team abbiamo sperimentato alcune tecniche per stimare i bug:

1. Stima di bug completamente sconosciuti
2. Stimare solo i bug che sono già stati analizzati
3. Tempo di assegnazione per la correzione dei bug e non stima dei bug, ma classificarli invece esclusivamente in base al valore aziendale

Con 1. abbiamo fallito in modo insopportabile. Per la maggior parte dei bug abbiamo riscontrato che il 90% del tempo è dedicato all'analisi dei bug. Dopodiché la correzione dei bug può essere stimata allo stesso modo di una storia. Pianificando gli errori in uno sprint, abbiamo commesso l'errore che la portata sconosciuta ha influenzato la risoluzione della trama fino al punto in cui quasi tutti gli sprint che abbiamo fatto in questo modo hanno fallito.

In base all'opzione 2. della tecnica di stima del rapporto 90/10 (analisi rispetto alla correzione di errori) significava che dovevamo pianificare un'analisi che non era qualcosa che era coperto per la pianificazione dello sprint (avevamo appreso dall'opzione 1, ma non aveva una soluzione reale come procedere con i bug analizzati). Il risultato è stato che l'analisi degli errori non è stata eseguita poiché uno sprint si è concentrato invece sugli elementi pianificati. Il team non ha avuto il tempo di concentrarsi sugli errori dal backlog. Quindi alla fine non hanno nemmeno finito.

Abbracciando l'incertezza, ora abbiamo optato per l'opzione 3. Abbiamo suddiviso l'arretrato di prodotto in una parte storia / attività regolare che può essere stimata dal team utilizzando i punti storia e un arretrato di bug. Nel backlog dei bug il proprietario del prodotto classifica i bug in base al valore aziendale e al giudizio molto approssimativo del team. Il team consente di assegnare un po 'di tempo durante uno sprint che può spendere per concentrarsi sugli errori. Il proprietario del prodotto non conosce il risultato esatto in quanto non è stato possibile pianificarlo comunque prima. Il rapporto tra backlog di bug e backlog regolare può essere regolato per ogni sprint in base allo stato corrente di ciascun backlog e all'importanza e al valore commerciale del contenuto.

Eliminando l'incertezza, ha liberato di nuovo la squadra. Gli sprint non sono stati compromessi da bug sconosciuti. Separando i bug in un arretrato diverso, entrambi hanno aumentato il focus dello sprint regolare del team e ci hanno fatto finire i bug che contenevano anche un valore commerciale significativo.

Quindi dipende se i punti della storia sono adatti a te. Vorrei provare a stimare i bug utilizzando prima i punti trama. Se fallisce, prova la mia opzione 3. Ha fatto di nuovo concentrare il nostro team (oltre 30 sprint) su bug più vecchi che contengono un grande valore commerciale. Ci ha anche liberato dal cercare di consegnare qualcosa che il team semplicemente non può stimare. E 'stato abbracciando l'ignoto che ci ha portato più vicino alla realtà e anche fatto le nostre sprint di nuovo successo , mentre offrendo una grossa fetta (sulla base del bug al rapporto storia) del valore di business attraverso correzioni di bug. Il rapporto che abbiamo usato di recente era 50/50.

Non sono d'accordo con la risposta migliore di assegnare punti storia ai bug. I punti storia dovrebbero essere per la consegna di nuovo valore. Se hai intenzione di assegnare punti al valore del prodotto e articoli non di valore, potresti anche solo stimare e tenere traccia delle ore.

I bug sono il sovraccarico di quello che hai fatto ieri e non sono indicativi della velocità di completamento del prodotto e non creano neanche alcun nuovo valore del prodotto (pensaci). I bug sono un po 'come interruzioni e tutte le altre torte di mucca che devi affrontare su base settimanale. L'idea generale dei punti della storia è che tiene traccia / stima quando consegneremo il prodotto (o il set di funzionalità). I punti della storia sono arbitrari ed è così che rimuove tutte le spese generali senza valore dalla stima. Generalmente il lavoro senza valore è costante settimana per settimana, quindi è integrato nella velocità del team. Il team accelera quando rimuovono o riducono questo lavoro senza valore.

In altre parole, perché anche tracciare i punti sui bug? In modo che alla fine sai quanto "lavoro" ha fatto ogni membro? Smettila! Cattivo manager! :) Misura la squadra, non il giocatore. Incoraggia la squadra a gestirsi da sola se una persona non sta tirando il proprio peso. Molto più efficace. Fare gli oggetti punto storia non dovrebbe far sentire meglio un individuo, ma il team nel suo insieme dovrebbe sentirsi meglio quando si impegnano alla fine dello sprint. Negli sport, l'obiettivo è buono per la squadra o l'individuo? Se l'individuo gioca per se stesso, la squadra perde a lungo termine.

Sai, alla fine non vuoi usare affatto i punti. La stima è il tempo portato via dal vero lavoro. Quando una squadra raggiunge il massimo chi non usa affatto i punti, ma sa esattamente quanti oggetti possono tirare in uno sprint. Hanno imparato l'arte di spezzare le unità di lavoro secondo cui la stima è uno spreco di processo.

Alcuni compiti sono stimabili, altri no. Per cose che non possono essere stimate, utilizzare un budget.

La correzione di un difetto non è un'attività facilmente stimabile perché ha diversi componenti sconosciuti. Cosa sta causando il difetto? Una volta compresa la causa, come può essere risolta? Che impatto ha questa modifica sul resto del sistema? Quanti nuovi difetti hai iniettato per correggere questo difetto?

Tenere presente che la causa di un difetto può provenire da qualsiasi punto del ciclo di vita del software: requisiti incompresi o non comunicati, progettazione errata o ipotesi errate, codifica scadente, test non corretti, nuove conoscenze sul problema basate sulle informazioni apprese dalla versione corrente ...

La creazione di un budget può essere eseguita in due modi diversi per le attività di correzione dei bug. Ecco alcune idee che ho usato in modo efficace:

• Usa i dati storici (diciamo da una precedente iterazione) per aiutarti a capire quanto tempo mettere da parte per la correzione dei bug.
• Inserisci "blocchi" di correzione di bug (diciamo 5 punti o 20 ore) nel tuo backlog e lascia che il cliente scelga questo al posto delle storie.
• È necessario che ciascun membro del team dedichi un determinato periodo di tempo a ogni iterazione per correggere i difetti.

Il tuo obiettivo è quindi quello di correggere il maggior numero possibile di difetti nel budget assegnato. Discutere con le strategie dei clienti per stabilire la priorità dei difetti segnalati. Ad esempio, si ordinano i difetti per criticità quindi per priorità? Priorità rigorosa? Dovresti attaccare prima "la frutta bassa"? Prima i bug dell'interfaccia utente?

Inoltre, correggere i bug non guadagna valore. I difetti di riparazione sono una forma di rifiuto. Hai già guadagnato valore sulla funzione, quindi non dovresti ottenere "punti bonus" per correggere i bug.

Avere un budget aiuta con la pianificazione e ti dà ancora un'immagine accurata di Velocity. Preventivi un numero specifico di punti per la correzione dei bug, dai al budget un tempo approssimativo in base ai tuoi dati storici, quindi elimina quanti più bug puoi nel tempo previsto!

Invece di concentrarmi su storie, bug, faccende e i punti che ognuno ha, trovo che sia meglio concentrarsi sulla fornitura di funzionalità per il cliente.

I clienti si aspettano che il software funzioni e che dia un valore reale allo sviluppo, ai miglioramenti e alle nuove funzionalità, poiché questi spingono il business in avanti.

Le correzioni di bug, per quanto importanti possano essere, non spingono l'azienda in avanti verso nuove aree e nuovi clienti (tangenzialmente ed eventualmente sì, ma non immediatamente, che è ciò che la direzione sta misurando).

Quindi i punti vengono visualizzati al meglio dal punto di vista della velocità più elevato e quanti punti alla settimana sono stati fatti storicamente per storie con punteggi simili.

Questo può portare a una gestione tenendo traccia della storia dei record piuttosto che spingere l'urgente necessità che le storie di questa settimana siano complete e che spesso scoprano che non lo sono. Tuttavia, la perdita del controllo iniziale e la maggiore fiducia che ciò richiede avranno alcuni manager in corsa per la porta inorriditi.

Uso Pivotal Tracker (ho solo JIRA, Trak, Trello e altri) e Pivotal Tracker non fa punti per faccende o bug. È fatto per le stesse buone ragioni sopra che lo rendono vero anche in JIRA come ti vedi.