In ambiente agile, come viene consolidato il tracciamento dei bug e il tracciamento delle iterazioni.

"... trova un bug, il report entra in un database di tracciamento dei bug e diventa anche una storia che dovrebbe avere la priorità come tutti gli altri lavori.

La domanda è, se la tracciabilità dei bug e il tracciamento delle caratteristiche sono diversi, e puoi usare un singolo sistema per eseguire entrambe le iterazioni / le tappe miliari / ecc ...

In termini di approccio "puro" Agile, consenti al tuo team di utilizzare qualsiasi combinazione di strumenti e processi che funzioni bene per loro. Certo, potresti trovare un singolo prodotto che fa tutto, ma forse non fa alcune cose come vorresti. Se si eseguono più sistemi, è necessario determinare solo l'integrazione di cui hanno bisogno, e se è necessaria qualsiasi integrazione, trovare i mezzi per farlo e decidere quante informazioni devono essere duplicate. Tutto si riduce a una situazione di costi / benefici, quindi naturalmente qualsiasi sistema impiegato deve tenere conto dell'impatto sull'efficienza complessiva di una squadra.

Dove lavoro, utilizziamo un sistema Redmine per tenere traccia di bug e funzionalità in un singolo sistema per più progetti, con collegamenti tra ogni progetto in cui esistono dipendenze. Creiamo etichette che riguardano le pietre miliari, che per noi sono effettivamente lunghe iterazioni che possono variare da poche settimane a pochi mesi. Per le singole attività e funzionalità, tendiamo a non tenere traccia delle iterazioni troppo da vicino, quindi non dobbiamo preoccuparci di grafici di burn-down, lavagne bianche, sticky notes, schede delle caratteristiche e tutte queste cose, come abbiamo scoperto per il nostro esigenze specifiche, alcune di queste cose sono eccessive. Ogni caratteristica stessa rappresenta efficacemente piccole iterazioni di durata compresa tra 2 e 10 giorni, e per quelli che potrebbero interessare, registriamo le nostre stime di tempo in funzione del tempo effettivo per un'analisi successiva. Questo potrebbe sembrare un po 'ad-hoc, ma funziona per noi e alla fine la nostra vera misura è lavorare codice all'interno di una serie di tempi.

Suppongo che se decidessimo di utilizzare un'altra metodologia più formalmente "irreggimentata", potremmo considerare uno strumento che aiuti a tenere traccia dei progressi, ma con ciò che attualmente abbiamo investito nel nostro attuale metodo, probabilmente nutriremmo almeno il descrizioni di funzioni brevi e dati temporali su un altro sistema, a meno che qualcuno non abbia sviluppato un modulo per Redmine che fa ciò che vogliamo, o se è diventato veramente importante per noi, potremmo creare il modulo Redmine evitare brutti mal di testa di integrazione che potrebbero riguardarci.

Non si può quasi mai dire realisticamente con certezza al 100% che non esistono bug. Anche se ogni caso di test è stato meticolosamente pensato, testato, verificato, probabilmente ci sarà una situazione a cui qualcuno non ha pensato. I bug identificati dal cliente si verificano, non sono la fine del mondo, ma quando accadono, mi assicuro di crearli in una user story e dare loro la massima priorità.

Uso Rally e lo adoro. In genere durante lo sprint, il test delle funzionalità viene eseguito non appena vengono completate dalle risorse QA. Quando il QA trova bug, di solito li scrive come Difetti in Rally e poi gli sviluppatori tentano di risolvere tutti i difetti prima della fine dello sprint.

Idealmente tutti i Difetti dovrebbero essere risolti, tuttavia per Difetti piccoli o banali potrebbe non essere necessario mantenere lo sprint indietro non accettando la User Story. Il QA dovrebbe fare il giudizio. Accettano la User Story con i difetti aperti o no?

Una volta accettato lo sprint, eventuali Difetti rimanenti possono essere elevati alle User Story per il prossimo sprint.

Un altro errore del tuo modo di pensare che ho notato è che hai delineato il QA come entità separata al di fuori del team di sviluppo. Questa è una mentalità intrinsecamente Waterfall come si presume semplicemente che una fase di Test di grandi dimensioni deve verificarsi prima del rilascio. Questo non dovrebbe essere così. I test dovrebbero svolgersi insieme al team di sviluppo DURANTE lo sprint e dovrebbero lavorare a stretto contatto con gli sviluppatori che preparano i loro casi di test e interpretano i risultati dei loro test.

Se Agile è fatto bene, lo sprint sarà pienamente accettato entro la fine dello sprint, il che significa che è pronto per la versione di produzione (non significa necessariamente che ogni sprint dovrebbe essere una release, solo che dovrebbe essere in produzione pronto se ne sorge la necessità).

Dove lavoro abbiamo anche il principio, quasi come un "articolo di fede", che i difetti non vengono sollevati durante un'iterazione ma semplicemente che lo sviluppo non è completo fino a quando non vengono affrontati tutti i problemi. Un problema può essere costituito da una mancanza di ambiguità nel modo in cui la tecnologia dovrebbe essere implementata in un bug vecchio stile nel codice. Perché, in modo molto agile, le nostre storie di utenti non sono specifiche ma piuttosto "segnaposti per una conversazione" è considerato vantaggioso che i requisiti siano finalizzati con i Proprietari del prodotto durante lo sviluppo in modo che né loro né gli sviluppatori siano inquinati in una soluzione in anticipo specifiche dei requisiti.

Se e quando viene identificato un "problema", la pratica incoraggiata è di tracciarlo creando una nuova attività sulla scheda del radiatore del progetto e in Rally. Questo serve a ricordare ai proprietari dei prodotti di fornire i requisiti, agli sviluppatori di implementarli e ai QA per incorporarli nel loro piano di test. Se un problema non può essere affrontato nel lasso di tempo per lo sviluppo, spetta al Product Owner (non al QA) accettare la storia con un avvertimento che il problema diventerà parte di una nuova storia o cresciuto come un difetto.

Questo è tutto eccezionale e funziona bene su piccoli progetti con team di piccole dimensioni e abbastanza piccoli che comunicano quotidianamente faccia a faccia. Tuttavia, nella mia esperienza, diventa problematico nei progetti più grandi in cui sono coinvolte terze parti e / o squadre offshore. Ciò è dovuto al fatto che i compiti sul tabellone o nel Rally non hanno i vantaggi di segnalazioni di difetti formali, ricordiamoci di questi benefici; 1. Una cornice comune di riferimento per il problema con un identificativo univoco (numero). 2. Passi per ricreare il problema con i risultati effettivi rispetto a quelli attesi, quindi non ci può essere alcuna ambiguità su quale sia effettivamente il problema. 3. Un repository ricercabile di problemi noti in modo che i membri del team non chiedano costantemente in giro se qualche presunto bug che hanno trovato è già stato segnalato. 4. Responsabilità; se facciamo affidamento su passaparola e / o catene di e-mail per segnalare problemi, le cose sono destinate a essere ignorate, ignorate o dimenticate, specialmente quando i problemi iniziano a montare.

Come QA credo fermamente che ci sia spazio per qualche metodo di tracciamento dei problemi durante lo sviluppo. Tuttavia, ogni volta che cerco di farlo funzionare, di solito sono schiaffeggiato e gli ho detto "Non capisco Agile" o parole in tal senso. È interessante notare che di solito sono i programmatori che sollevano tali obiezioni. Questo è comprensibile perché i programmatori non hanno il potenziale problema di segnalazione e di monitoraggio di numerosi problemi. Quindi raccomando che qualsiasi discussione su questo argomento coinvolga BA, Project Manager e QA perché è qualcosa su cui tutti dobbiamo lavorare quotidianamente. Al contrario, l'esperienza di un difetto di un programmatore di solito è solo un singolo pezzo di lavoro che devono risolvere all'interno di una data area di codice.

Dove lavoro, usiamo TFS per il controllo del codice sorgente e il monitoraggio degli oggetti di lavoro. Sia le storie che i bug sono elementi di lavoro in TFS, così come lo sono le attività necessarie per completare entrambi. Il codice, quando archiviato, è associato agli elementi di lavoro e le build sono associate sia al check-in sia agli elementi di lavoro, quindi è chiaro quali build sono pensati per correggere quali bug.

Credo sia il modo migliore per aggiungere bug ai tuoi sprint e rilasciarlo in questo modo per tenere traccia dei bug.

Ho ricevuto questa idea da un nuovo strumento Yodiz che ti consente di aggiungere bug a sprint e versioni

Penso che la soluzione di questo problema sia lasciare che il team crei problemi / bug all'interno della user story, proprio come le attività.

Yodiz (www.yodiz.com) risolve facilmente questo problema consentendo di creare problemi nella scheda Sprint e assegnarli a una storia utente. Lo stesso problema può essere visto anche sul tracker dei problemi integrato di Yodiz, quindi ora puoi vedere lo stesso problema in due punti sulla scheda di emissione, oltre allo sprint o alla scheda kanban.

Puoi calpestare il problema come compito e spostarlo lungo la scacchiera come se avessi spostato il tuo compito da uno stato problematico a un altro.

Ancheinquestocasononperdimaitracciadeituoibug.Cisonomomentiincuiiteamditestinizianoatestareletueattivitàcompletateeinquellesituazionièmoltoutileperconsentirtidiallegareproblemiallauserstory.IncasoditesterYodizpuoicreareunproblemasultrackerdiproblemiecollegarlo(associarlo)aunastoriautenteequelbuginizierebbeacomparirenellaschedasprintdeglisviluppatori.