Mi sto solo chiedendo se dovremmo assegnare dei punti storia alle attività di bug fixing o meno. JIRA, il nostro software per il rilevamento di problemi, non ha campo di story point per problemi di tipo Bug (è solo per Story se Epic s).
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 essere parte di ogni sprint, quindi il lavoro richiesto per correggere i bug dovrebbe essere preso in considerazione quando si assegnano i punti storia (ad es. produrre bug dovrebbe avere più punti storia ad esso assegnati).
In realtà, tuttavia, gli errori emergono continuamente dopo la distribuzione, indipendentemente dalla rigidità dei test; quando ciò accade, rimuovere il bug è solo un altro cambiamento, una funzionalità se lo si desidera. Non c'è 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 del business, bugfix e funzionalità sono uguali, in realtà: o lo fai (scenario B), oppure no (scenario A); entrambi gli scenari hanno costi e benefici collegati, e un uomo d'affari decente li appesantirà e andrà con quello che guadagna più profitti (a lungo termine oa breve termine a seconda della strategia aziendale).
Quindi sì, con ogni mezzo, assegnare i punti storia ai bug. In quale altro modo darai la priorità ai bug rispetto alle funzionalità e ai bug contro i bug? Hai bisogno di una certa misura dello sforzo di sviluppo per entrambi, ed è meglio essere comparabili.
Il problema più grande con questo è che le correzioni dei bug sono spesso più difficili da stimare: il 90% o più dello sforzo reale sta nel trovare la causa; una volta trovato, è possibile fornire una stima accurata, ma è quasi impossibile valutare la durata della ricerca. Ho persino visto una buona dose di bug in cui la maggior parte del tempo è stata spesa solo provando a riprodurre il bug. D'altra parte, a seconda della natura del bug, è spesso possibile restringere la ricerca con una ricerca minima prima di fare una stima.
Stimare bug con punti è intrinsecamente difficile come già sottolineato in altre risposte e sì la soluzione ideale è che i bug trovati in una funzione DOPO che lo sprint è stato accettato dovrebbero essere considerati nuove funzionalità .
Questa difficoltà nella stima puntuale dei bug, tuttavia, è una delle molte ragioni per cui i pacchetti software di PM Agile consentono di stimare compiti e bug in ore, perché impiegano la dilligence e l'esperienza per diventare esperti nella stima dei punti. Molti progetti incontrano problemi significativi con velocità di determinazione appropriata, quindi molti progetti Agile utilizzano i punti per determinare quali storie lo fanno nello sprint, tuttavia usano ore per calcolare il grafico di burndown .
Sembra controintuitivo ma gestibile finché la stima delle ore non viene utilizzata come fattore nel determinare l'impegno dello sprint. Overcommittment porterà naturalmente a funzioni mancate o incomplete o straordinari, quindi nel tempo tutte le parti coinvolte sono costrette a migliorare la stima dei punti, a quel punto la stima delle ore su compiti e bug diventa lentamente una metrica priva di significato.
Tu non dovresti dare punti per la risoluzione dei bug. Considera il fatto che il bug proviene da una storia in cui gli sviluppatori hanno già guadagnato punti per aver completato la storia. Non dovrebbe ricevere punti di nuovo dove in realtà non avrebbe dovuto guadagnare i punti per cominciare.
La risoluzione dei bug dovrebbe avere un effetto negativo sulla velocità. Altrimenti la perdita di qualità finisce per essere premiata con una velocità inalterata o addirittura maggiore!
Forse un link utile:
Vorrei raccomandare di trattare il bug come una user story e assegnargli un numero di punti. Non lo scriverei necessariamente nel formato "As a X, voglio Y in modo che Z" come è comune con le storie degli utenti - Lo scriverei più come "Come una X, quando succede IY, Z, ma Z 'è il comportamento previsto ".
Il vantaggio di questo è che ti consente di dare la priorità alle correzioni dei bug accanto alle nuove richieste di nuove 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, consentendoti di adattarlo a uno sprint quando ne hai la possibilità.
Una cosa da tenere a mente che potrebbe essere difficile stimare lo sforzo richiesto per correggere un bug. Potrebbe coinvolgere più componenti che interagiscono tra loro, richiedendo a qualcuno di familiarizzare con le interazioni di grandi parti del sistema o con più persone per lavorare sulla correzione.
La stima delle storie si basa sul concetto che, con il tempo, una squadra guadagna esperienza nel risolverli. Con esso la precisione è migliorata e la velocità può essere stabilita per misurare la velocità di un team. Una metodologia perfetta per stabilire prognosi 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, accettare che ciò non possa essere raggiunto in ogni momento, dovrebbe essere qualcosa che ogni squadra dovrebbe pianificare. Invece di pensare ostinatamente che il processo debba governare la squadra, dovrebbe essere il contrario.
Ovviamente, bug o storia, dal punto di vista commerciale non importa ciò che la squadra sta affrontando. Entrambi possono produrre una quantità uguale di valore per il proprietario del prodotto.
Nel nostro team abbiamo sperimentato alcune tecniche per stimare i bug:
Con 1. abbiamo fallito miseramente. Per la maggior parte dei bug abbiamo trovato che il 90% del tempo è dedicato all'analisi dei bug. Dopo di ciò la correzione del bug può essere stimata allo stesso modo di una storia. Pianificando i bug in uno sprint, abbiamo commesso l'errore che lo scope sconosciuto ha influito sulla risoluzione della storia fino al punto in cui quasi tutti gli sprint in questo modo non sono riusciti.
Sulla base dell'opzione tecnica di stima del rapporto 90/10 (analisi per il bug fixing) 2. significava che dovevamo pianificare un'analisi che non era coperta dalla pianificazione degli sprint (avevamo imparato dall'opzione 1, ma avevamo nessuna vera soluzione su come andare avanti con i bug analizzati). Il risultato è stato che l'analisi dei bug non è stata eseguita poiché uno sprint si è concentrato sugli elementi pianificati. Il team non ha avuto il tempo di concentrarsi sui bug del backlog. Quindi alla fine non sono stati nemmeno fatti.
Abbracciando l'incertezza, abbiamo optato per l'opzione 3. Abbiamo suddiviso il product backlog in una storia normale / una parte di attività che può essere stimata dal team usando i punti storia e un backlog degli errori. Nel backlog degli errori, il proprietario del prodotto classifica i bug in base al valore aziendale e al giudizio del team molto approssimativo. Il team consente di allocare una parte del tempo durante uno sprint che può essere speso per concentrarsi sui bug. Il proprietario del prodotto non conosce il risultato esatto in quanto non è stato possibile pianificarlo prima. Il rapporto tra il backlog dei bug e il normale backlog può essere regolato per ogni sprint a seconda dello stato corrente di ciascun backlog e dell'importanza e del valore commerciale del contenuto.
Togliendo l'incertezza ha liberato di nuovo la squadra. Gli sprint non sono stati compromessi da errori sconosciuti. Separando i bug in un backlog diverso, abbiamo aumentato sia il focus regolare del team che lo sprint e ci hanno fatto finire bug che contenevano anche un significativo valore di business.
Quindi dipende se i punti della trama sono adatti a te. Proverò a stimare i bug usando prima i punti storia. Se fallisce, prova la mia opzione 3. Ha fatto in modo che il nostro team (più di 30 anni) si concentri sui bug più vecchi che contengono un grande valore aziendale. Ci ha anche liberato dal cercare di offrire qualcosa che il team non può semplicemente stimare. Stava abbracciando l'ignoto che ci ha avvicinato alla realtà e ha anche reso i nostri sprint di nuovo riusciti mentre consegnando un grosso pezzo (basato sul rapporto bug-storia) del valore aziendale attraverso correzioni di bug. Il rapporto che abbiamo usato di recente era 50/50.
Non sono d'accordo con la risposta più alta dell'assegnazione dei punti della storia ai bug. I punti storia dovrebbero essere per il nuovo valore consegnato. Se si assegnano punti a oggetti con valore del prodotto e non a valore, si potrebbe anche solo stimare e tenere traccia delle ore.
I bug sono il sovraccarico di ciò che hai fatto ieri e non sono indicativi della velocità del completamento del prodotto e non creano nemmeno un nuovo valore di prodotto (pensaci su). I bug sono una specie di interrupt e tutte le altre torte di mucca che devi affrontare su base settimanale. L'intera idea dei punti della storia è che tiene traccia / stima quando consegneremo il prodotto (o set di funzionalità). I punti della storia sono arbitrari e questo è il modo in cui rimuove dal calcolo tutti i sovraccarichi non di valore. Generalmente il lavoro senza valore è costante da una settimana all'altra, quindi è integrato nella velocità del team. Il team accelera quando rimuove o riduce questo lavoro senza valore.
In altre parole, perché persino tracciare punti a bug? In modo che alla fine della giornata tu sai quanto "lavoro" ha fatto ogni membro? Smettila! Cattivo manager! :) Misura la squadra, non il giocatore. Incoraggia la squadra a gestire se stessa se una persona non sta tirando il loro peso. Molto più efficace. Fare oggetti di story point non dovrebbe far sentire meglio un individuo, ma la squadra nel suo complesso dovrebbe sentirsi meglio quando si impegnano alla fine dello sprint. Nello 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 i punti. La stima è il tempo tolto dal lavoro reale. Quando una squadra raggiunge massimo chi non usa affatto punti, ma sa esattamente quanti oggetti possono tirare in uno sprint. Hanno padroneggiato l'arte di rompere le unità di lavoro che la stima è spreco di processo.
Alcune attività sono stimabili, altre no. Per le cose che non possono essere valutate, utilizza un budget.
La correzione di un difetto non è un'attività facilmente stimabile perché contiene diversi componenti sconosciuti. Qual è la causa del difetto? Una volta compresa la causa, come può essere riparata? Che impatto ha questo cambiamento 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 errati, progettazione scadente o ipotesi sbagliate, codifica scadente, test errato, nuova conoscenza del problema in base alle informazioni apprese da la versione corrente ...
La creazione di un budget può essere effettuata in un paio di modi diversi per le attività di correzione dei bug. Ecco alcune idee che ho usato in modo efficace:
Il tuo obiettivo è quindi quello di correggere quanti più difetti possibili 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 priorità? Priorità rigorosa? Dovresti attaccare prima "frutta a basso impatto"? Prima i bug dell'interfaccia utente?
Inoltre, correggere bug non guadagna valore. I difetti di fissaggio 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 a pianificare e ti dà ancora un'immagine precisa di Velocity. Budget un numero specifico di punti per la risoluzione dei bug, dai al budget una quantità approssimativa di tempo in base ai tuoi dati storici, e poi contrai quanti più bug possibili nel minor tempo possibile!
Invece di concentrarsi su storie, bug e faccende e sui punti che ciascuno ha, trovo che sia meglio concentrarsi sulla fornitura di funzionalità per il cliente.
I clienti si aspettano che il software funzioni e danno solo valore reale allo sviluppo, ai miglioramenti e alle nuove funzionalità, in quanto portano avanti il business.
Le correzioni dei bug, per quanto importanti possano essere, non guidano l'azienda in nuove aree e nuovi clienti (tangenzialmente e alla fine forse sì ma non immediatamente, che è ciò che la gestione sta misurando).
Quindi i punti sono visti meglio dal punto di vista più alto della velocità e quanti punti alla settimana sono stati fatti storicamente per storie con punteggi simili.
Questo può portare a una gestione per tracciare la cronologia dei record piuttosto che spingere l'urgente necessità che le storie di questa settimana siano complete e spesso si scopre che non lo sono. Tuttavia, la perdita del controllo iniziale e la maggiore fiducia che questo richiede avranno alcuni manager che corrono per la porta inorridita.
Uso Pivotal Tracker (ho solo JIRA, Trak, Trello e altri) e Pivotal Tracker non fa punti per faccende o bug. E 'fatto per le stesse buone ragioni sopra che lo rendono anche vero in JIRA come ti vedi.
Leggi altre domande sui tag bug agile scrum user-story