I casi dovrebbero essere riaperti per bug o dovrebbero essere aperti come nuovo caso?

Attualmente nel mio posto di lavoro utilizziamo FogBugz per gestire tutte le nostre funzionalità e bug per le nostre diverse applicazioni web.

Quando una nuova funzionalità deve essere aggiunta a una delle nostre applicazioni Web, viene creato un nuovo caso. Ad esempio "Crea modulo di caricamento CSV".

Quindi lavoro sul caso registrando il tempo che ho trascorso su di esso. Una volta completato questo caso, lo risolvo e viene assegnato all'apriporta (di solito il project manager), che quindi chiude il caso.

Se ci sono bug con la funzione, il mio Project Manager riapre il caso e me lo restituisce con un elenco puntato di bug.

A mio avviso, credo che questi bug a punta di proiettile debbano essere aperti come singoli casi di bug, in modo che possano essere rintracciati più facilmente e non essere ingombra con le note originali del case feature.

I miei manager non sono d'accordo con me affermando che è più facile calcolare il tempo totale speso per la funzionalità, se è tutto in un caso.

Inoltre credono che sia meno confuso per i nostri clienti in quanto hanno solo 1 riferimento al numero di caso per la funzione. Tuttavia, vorrei sottolineare che i bug dovrebbero essere trattati come casi separati poiché si tratta del post-completamento del caso originale.

Ho ragione nel dichiarare che i bug dovrebbero essere riaperti come nuovo caso? E quali sono i pro / contro di ogni modo di gestirlo?

Sia tu che il tuo manager avete buone ragioni per trattare nel modo che preferite, e non vi è alcuna reale necessità di scendere a compromessi. C'è una soluzione che funziona per me e affronta entrambe le preoccupazioni.

Per casi come il mio utilizzo un approccio di alto livello / sub-task di basso livello (concetto che ho scelto da JIRA , non posso dire se il supporto di FogBugz ^sembra esplicitamente ^come ). In questo modo, gli elenchi puntati "rivolti al cliente" vanno ad attività di alto livello mentre le "iterazioni degli sviluppatori" per me importanti si riflettono nelle attività secondarie.

Quando l'attività di alto livello viene "riaperta", creo una nuova attività secondaria per tracciare lo sforzo aggiunto per se stessi .

In questo modo lo sviluppatore può riflettere chiaramente tutte le permutazioni, le perversioni e le torsioni attraversate dalle specifiche delle funzionalità, lasciando comunque al manager di presentarlo ai clienti come se fosse perfetto. A proposito, come una presentazione perfetta per me ha il suo valore come sviluppatore, perché avere più facile da leggere per i clienti aiuta a ottenere aggiustamenti più accurati.

Ciò naturalmente consente anche di avere una chiara giustificazione nei casi in cui l'implementazione delle funzionalità richiede molto più tempo di quanto inizialmente previsto.

_{Per quanto riguarda il monitoraggio del tempo per attività o sottoattività - poiché JIRA consente di includere il monitoraggio delle attività secondarie in un riepilogo di livello superiore, è accettabile per il manager che io tenga traccia del tempo nelle attività secondarie. Tuttavia, anche se non fosse così, potrei vivere con il tracciamento formale del tempo nell'attività "padre" - in questo caso userò solo i commenti delle sotto-attività per indicare quanto tempo è stato dedicato a una particolare iterazione.}

Se tutto ciò accade prima che la funzionalità venga rilasciata al cliente, basta avere un caso. L'argomento qui è che il caso non è veramente completo fino a quando non viene superato il QA e pronto per essere rilasciato. Gli altri vantaggi: un singolo numero di caso per la fatturazione e gli utenti finali a cui fare riferimento sono validi e importanti.

Una volta rilasciata la funzione e individuati i bug, questi dovrebbero essere sollevati come nuovi problemi nel software di tracciamento dei problemi.

Sono completamente d'accordo con te, e anche FogBugz - ecco perché definisce diverse categorie per bug e funzionalità. FogBugz non è stato progettato per essere uno strumento per tenere traccia dell'uso del tempo; questo è un sottoprodotto accidentale dell'introduzione di una pianificazione basata sull'evidenza.

I bug per una funzione completata possono essere collegati al caso principale per la funzione (in FogBugz, usando un nome tag o un riferimento incrociato o rendendoli sotto-casi). Vedo che questo è un po 'più lavoro per il tuo PM per consolidare le informazioni in diversi casi, ma spesso ha anche senso essere in grado di separare il tempo dedicato allo sviluppo originale e il tempo dedicato alla manutenzione, in particolare per i contratti a prezzo fisso, e perdi la capacità di farlo se metti tutto in un caso.

La mia opinione è che una volta chiuso un biglietto dovrebbe rimanere chiuso, il tuo localizzatore di bug dovrebbe essere in grado di collegarsi ad altri casi comunque. Vorrei sottolineare che la creazione di nuovi bug e il collegamento al caso originale offre vantaggi migliori rispetto al metodo descritto.

• i client possono comunque avere un numero di riferimento che contiene collegamenti a ciascun bug.
• lo stato di ciascun bug può essere monitorato individualmente, consentendo una migliore definizione delle priorità e rapporti sullo stato.
• la presenza di bug separati consentirà al manager di suddividere il tempo speso per i bug rispetto al tempo dedicato allo sviluppo di nuove funzionalità e dovrebbe essere solo uno sforzo aggiuntivo minimo per ottenere un numero totale per tutti i bug relativi a una modifica e allo sviluppo di tale modifica.
• la separazione dei bug rende molto più semplice per il tuo manager raccogliere altre metriche come bug totali, tempo medio per correzione bug, rapporti di bug chiusi / in corso / risolti.
• casi separati per bug consentono di suddividere meglio le attività tra tutti gli sviluppatori e di ritenerne ciascuno responsabile per il proprio lavoro, oppure consente questa possibilità qualora vengano assunti più sviluppatori in un secondo momento.

L'unico vantaggio della configurazione corrente è che è estremamente semplice per le persone che non sono i principali utenti del sistema. Lo scopo di un bug tracker è che lo sviluppatore abbia un posto dove segnalare tutto su un bug in un singolo posto che sia anche abbastanza amichevole da consentire agli altri di vedere i progressi, il tuo sistema attuale sembra minare quasi ogni parte di quello.

I bug sono stati trovati prima o dopo che il prodotto è stato "spedito / rilasciato" ai clienti?

Se è prima di un rilascio, i bug devono essere tracciati rispetto al ticket originale.

Se è dopo un rilascio, ogni bug dovrebbe essere il proprio ticket.

Dove lavoro, solo gli addetti al controllo qualità possono chiudere un caso. Abbiamo caselle di controllo per Code Review, Engineer Tested e Demo to Stakeholder (nel tuo caso Project Manager). Se il team addetto al QA vede un caso contrassegnato come "Fatto" che non ha tutti questi campi contrassegnati, lo contrassegnerà come annullato e lo rispedirà a noi.

Una volta che un caso ha superato tutte queste fasi e il QA lo chiude, tutti i nuovi problemi rilevati vengono registrati come bug.

Questo sistema sembra funzionare bene per noi.

Penso che tu possa fare una discussione in entrambi i modi. Vorrei provare a sedermi con il Primo Ministro e spiegare perché pensi che avere problemi discreti ti aiuterà. Personalmente voglio che ogni oggetto todo dovrebbe essere il suo biglietto, ma posso capire perché lo vuole in quel modo.