Esistono studi sugli svantaggi dell'utilizzo dei sistemi di tracciamento dei problemi? [chiuso]

It takes too much time to describe issues in it. This discourage its usage.

Se non riesci nemmeno a descrivere un bug come puoi iniziare a risolverlo?

You create a place to keep your bugs. And if there is a place for them, people usually don't care too much about fixing a bug cause they can put it there so that someday someone can fix it (or not).

Questo è un problema con il tuo team non con il software.

With time, the bug lists gets so long that nobody can deal with it anymore, taking a lot of our time.

Ancora una volta descrivi un problema con il tuo team.

Il punto del software di tracciamento dei bug non è quello di aiutarti a motivare il tuo team a correggere i bug, ma è quello di tenere un record in modo da poter rintracciare la causa dei bug e fermarli di nuovo. Nessun software sarà mai un sostituto per una buona gestione.

IMO il tuo punto di partenza è di parte. Se gli sviluppatori non riescono a correggere i bug, il progetto è destinato a fallire, sia che tengano traccia dei bug usando uno strumento di tracciamento dei bug, post-it, incisioni su pietra, o non del tutto. Non è colpa dello strumento se non viene utilizzato o utilizzato in modo improprio. (Detto questo, ci sono ovviamente bug insettidi / tracker di problemi là fuori ... Ho lavorato a un progetto usando uno strumento totalmente inadeguato per questo lavoro, quindi penso di sapere quanto può essere pessimo, ma ce ne sono anche di buoni, che richiedono una cerimonia e un overhead minimi, permettendoti di concentrarti sulle informazioni pertinenti.)

Se, comunque, gli sviluppatori si preoccupano, e il progetto è più grande di dimensioni insignificanti, e c'è più di un singolo sviluppatore su di esso, e c'è una sorta di gestione coinvolta (tutte cose che sono piuttosto comuni nel reale -world projects), presto ci saranno domande come:

1. Quale dei bug aperti dovrebbe essere risolto per primo? (nota: in un progetto sano, questo dovrebbe essere deciso dal proprietario del prodotto e / o dalla direzione, NON da uno sviluppatore - per il quale devono essere consapevoli di tutti i bug aperti prima di tutto!)
2. Quanti bug aperti abbiamo e di quale gravità?
3. Quali di questi devono essere risolti prima di essere pronti per il rilascio?
4. Quanto tempo è necessario per pianificare queste correzioni? Spesso si tratta di: quanto tempo è necessario per correggere un bug in media?
5. quanti bug sono stati segnalati dai clienti nell'ultima versione?
6. chi ha risolto questo bug e questo, quando e quali modifiche (codice / configurazione / dati) ha comportato la correzione?
7. quali correzioni di bug sono incluse nella versione che stiamo per pubblicare?
8. ...

Puoi rispondere a tali domande [aggiorna] in maniera ripetibile, affidabile ed efficiente [/ update] in base alle tue note post-it?

Sì, inserire i dati dei bug in un tracker dei problemi comporta un sovraccarico. Tuttavia, è più che compensato dal tempo e dagli sforzi salvati nella ricerca e dalla creazione di report come quelli sopra, dai dati di bug memorizzati.

La tua metodologia potrebbe funzionare per progetti molto piccoli con un numero limitato di programmatori. Una volta che un progetto diventa più grande, avere un sistema di tracciamento dei problemi diventa molto più importante per il coordinamento tra i diversi team, in particolare se le correzioni saranno pubblicate in diverse versioni di codice. I progetti complessi avranno molte parti / componenti in movimento e assicurando che i problemi siano pianificati e fissati è una parte importante di una buona implementazione del monitoraggio dei problemi

Alcuni articoli / studi che potrebbero interessarti includono questo articolo che parla dell'uso di Jira da parte di Zira e questo studio francese discutendo l'uso di sistemi di tracciamento dei bug.

Potrebbero esserci studi, ma ancora meglio sono le esperienze duramente guadagnate delle persone sul campo. La maggior parte dei sistemi di tracciamento dei problemi soffre dei processi che guidano il loro design. I tracker di problemi spesso devono supportare 2 classi distinte di utenti:

1. Il team di sviluppo
2. Gli utenti del sistema

Cal Henderson (ex Flickr) ha un su il design di molti tracker di problemi e il motivo per cui preferisce il tracker di problemi GitHub (come faccio io). Inoltre, Garrett Dimon ha coperto il design di Sifter e illustrato un modo per semplificare il processo per più rilevamento efficace dei problemi . Ho adottato alcune delle idee di entrambi questi messaggi per semplificare il flusso di lavoro per il rilevamento dei problemi del mio team.

Tutto ciò che è stato detto, dipende ancora dalle persone rispetto a processi e strumenti. Il mio pensiero generale è che i tracker di problemi tendono a creare questo arretrato che devi gestire. Durante il triage, le persone hanno maggiori probabilità di razionalizzare ciò che è o non è un bug. Nel nostro processo, prendiamo decisioni quasi non appena il bug è archiviato sul fatto che sia o meno un problema. Una volta presa questa decisione, il bug viene inserito in Pivotal Tracker. La differenza qui è che utilizziamo il Tracker per prioritization , non come un pennarello per cose che non vogliamo fare. Infatti quando Icebox inizia a diventare troppo grande, elimino attivamente gli elementi, inclusi i bug. Se un problema è abbastanza grande da dover essere gestito, verrà visualizzato di nuovo.

Abbiamo raramente bisogno di una cronologia degli errori. Occasionalmente, qualcuno può menzionare un sintomo di un bug e possiamo fare una ricerca per vedere se è correlato ad alcuni problemi già trattati. Ma questo è raro.

TL; DR Concentrati sul tuo processo, scegli strumenti semplici e risolvi i problemi man mano che si presentano.

killing important bugs as soon as they appear

Sembra che tu stia irrompendo nella porta aperta qui. I bug importanti vengono "uccisi" il prima possibile, indipendentemente dal fatto che tu usi o meno il tracker dei problemi.

• Oh e parte "come appaiono" è piuttosto scivolosa. In un progetto abbiamo avuto un bug importante che ha minacciato di buttare l'intero prodotto fuori dal mercato (cosa potrebbe essere più importante?). È stato molto complicato (errore di architettura) e sapevamo che ci sarebbe voluto molto tempo per risolverlo. I clienti hanno gentilmente accettato di darci un anno per risolvere il problema (prima di abbandonare il nostro prodotto) e lo abbiamo fatto in circa un anno.

Come per gli inseguitori di problemi, li uso da quasi dieci anni e, di regola, tutti i programmatori intorno a me hanno trascorso un po 'di tempo con tracker (nota che sto parlando di programmatori; storia diversa). Ho visto casi (raramente) quando non era così - in tutti questi casi qualcosa era gravemente rotto.

Per quanto riguarda gli studi sulle conversazioni faccia a faccia e il monitoraggio dei problemi, ancora una volta sembra che tu stia irrompendo nella porta aperta qui. Il rilevamento dei problemi è una tipica comunicazione scritta ; ci sono molte ricerche che dimostrano che per discutere le cose, la comunicazione face2face è molto più efficiente di al telefono che a sua volta è molto più efficiente di scritto .

• In realtà dato che chiedi informazioni su f2f sembra che tu stia usando il tracker per discutere di cose, questo non è il suo scopo. Per capire il suo uso previsto, scrivi il suo nome lentamente e chiaramente: sistema di tracciamento dei problemi .

the bug lists gets so long

Nella mia esperienza, qui sopra è un vantaggio non un problema.

Con gli elenchi di bug lunghi gli sviluppatori possono impostare una coda e pianificare le correzioni molto più avanti. Questo è tanto produttivo quanto diventa; per me questo è fondamentalmente un nirvana quando ho una tale coda con cui lavorare. Primo bug - fix - done, secondo bug - fix - done, prossimo bug - fix - done etc etc. nessuna interruzione stupida, nessuna distrazione dolorosa con conversazioni f2f oh-così efficienti, flusso puro .

• Ricordo solo un caso in cui lunghi elenchi di bug sono stati un problema. È successo quando un idiota del management più alto ha deciso una politica che obbligava gli sviluppatori a scegliere il prossimo bug da una pila di 50-100 quasi ogni giorno. Che spreco. Ci sono voluti alcuni mesi di dolore fino a quando non abbiamo capito come aumentarlo sopra la sua testa e farlo aggiustare.
  Qualche tempo dopo che siamo riusciti a stabilire un flusso di lavoro conveniente, abbiamo scoperto che il nostro "backlog infinito" si è magicamente svuotato.