I casi devono essere riaperti per i bug, o dovrebbero essere aperti i bug come nuovi casi?

Sia tu che il tuo manager avete una buona ragione per affrontare il modo in cui ognuno di voi preferisce, e non c'è alcun reale bisogno di scendere a compromessi. C'è una soluzione che funziona per me e affronta entrambe le preoccupazioni.

Per casi come il tuo utilizzo un approccio di alto livello / sotto-attività di basso livello (concetto che ho scelto da JIRA , non posso dire se FogBugz lo supporta esplicitamente ^{sembra come fa} ). In questo modo, gli elenchi puntati "client-facing" passano a compiti di alto livello, mentre le "iterazioni degli sviluppatori" che sono importanti per me si riflettono nelle attività secondarie.

Quando un'attività di alto livello viene "riaperta", creo una nuova sotto-attività per tracciare lo sforzo aggiunto per sé .

In questo modo lo sviluppatore può riflettere chiaramente tutte le permutazioni, le perversioni e le torsioni attraverso le specifiche delle caratteristiche, lasciando comunque al gestore la presentazione ai clienti come se fosse perfetto. Tra l'altro la presentazione così perfetta ha il suo valore per me come sviluppatore - perché avere più facile leggere per i clienti aiuta a ottenere aggiustamenti più accurati.

Ciò naturalmente consente di avere una chiara giustificazione nei casi in cui l'implementazione della funzione richiede molto più tempo del previsto in origine.

_{Per quanto riguarda il monitoraggio del tempo per attività o sottoattività - poiché JIRA consente di includere il tracciamento delle attività secondarie in un riepilogo di livello superiore, per il gestore è accettabile monitorare il tempo nelle sotto-attività. Tuttavia, anche se questo non fosse il caso, potrei vivere con il tempo di tracciamento formale nel task "genitore" - in questo caso userei solo i commenti delle sotto-attività per indicare quanto tempo è stato speso in particolari iterazioni.}

Se ciò accade prima che la funzione venga rilasciata al cliente, è sufficiente un caso. L'argomento qui è che il caso non è veramente completo finché non viene passato al QA e pronto per essere rilasciato. Gli altri vantaggi: un numero di singolo caso per la fatturazione e gli utenti finali di riferimento sono validi e importanti.

Una volta che la funzione è stata rilasciata e vengono rilevati dei bug, questi dovrebbero essere sollevati come nuovi problemi nel software di monitoraggio dei problemi.

Sono completamente d'accordo con te, e anche FogBugz - è per questo che definisce diverse categorie di bug e funzionalità. FogBugz non è stato progettato per essere uno strumento per tracciare il tempo di utilizzo; 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 di tag, o un riferimento incrociato, o rendendoli sotto-casi). Posso vedere che questo è un po 'più di lavoro per il tuo PM per consolidare le informazioni in diversi casi, ma spesso ha anche senso separare il tempo speso per lo sviluppo originale e il tempo speso per la manutenzione, specialmente per i contratti a prezzo fisso, e perdi la capacità di farlo se metti tutto in un caso.

È mia opinione che una volta che un ticket è stato chiuso dovrebbe rimanere chiuso, il tuo bug tracker dovrebbe comunque essere in grado di collegarsi ad altri casi. Vorrei provare a sottolineare che la creazione di nuovi bug e il loro collegamento al caso originale offre migliori vantaggi rispetto al metodo che descrivi.

I client
• possono ancora avere un numero di riferimento che contiene collegamenti a ciascun bug.
• lo stato di ogni bug può essere monitorato individualmente, consentendo una migliore definizione delle priorità e rapporti sullo stato.
• avere bug separati consentirà al tuo manager di abbattere il tempo speso per i bug e il tempo trascorso a sviluppare nuove funzionalità, e dovrebbe essere solo uno sforzo minimo per ottenere un numero totale per tutti i bug relativi a un cambiamento e allo sviluppo di quel cambiamento .
• separare i bug rende molto più facile 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 consente di suddividere meglio i compiti tra tutti gli sviluppatori e di renderli responsabili per il proprio lavoro, o consente questa possibilità nel caso in cui più sviluppatori vengano assunti in un secondo momento.

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

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

Se è prima di una versione, i bug dovrebbero essere tracciati rispetto al ticket originale.

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

Dove lavoro, solo le persone del controllo qualità possono chiudere un caso. Disponiamo di checkbox per Codice revisionato, Test tecnico e Demo per Stakeholder (nel tuo caso Project Manager). Se il team addetto al controllo della qualità vede un caso contrassegnato come "Fatto" che non ha tutti questi campi contrassegnati, lo contrassegnerà e lo invierà a noi.

Una volta che un caso ha passato tutte queste fasi e QA chiude il caso, qualsiasi nuovo problema trovato viene registrato come bug.

Questo sistema sembra funzionare bene per noi.

Penso che tu possa argomentare in entrambe le direzioni. Vorrei provare a sedermi con il PM e spiegare perché pensi che avere problemi discreti ti aiuterà. Personalmente voglio che ogni articolo di TOD sia un biglietto tutto suo, ma posso capire perché lo vuole in questo modo.