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

9

Non mi piacciono i sistemi di localizzazione dei problemi perché:

Ci vuole troppo tempo per descriverne i problemi. Questo scoraggia il suo utilizzo.
Crei un posto per conservare i tuoi bug. E se c'è un posto per loro, le persone di solito non si preoccupano troppo di riparare un bug perché possono metterlo lì in modo che un giorno qualcuno possa risolverlo (o no).
Con il tempo, la lista dei bug diventa così lunga che nessuno può più occuparsene, occupando molto del nostro tempo.

Preferisco gestire i problemi usando i post-it su una lavagna, conversazioni faccia a faccia e uccidere bug importanti non appena compaiono. Non mi interessa troppo tenere traccia della cronologia dei bug perché non penso che valga la pena.

Sono solo qui? Esistono studi (libro / articolo / qualunque cosa) sugli svantaggi (o grandi vantaggi) dell'utilizzo dei sistemi di localizzazione dei problemi?

project-management agile issue-tracking

— user1062120
fonte

5

Votazione per chiudere, troppo localizzata. Il problema qui non sembra essere con i sistemi di tracciamento dei problemi, piuttosto con il processo di gestione dei bug in azienda.

— P.Brian.Mackey,

1

Quali sistemi di tracciamento dei problemi hai provato (oltre alle note e alle lavagne post-it)? Qual è stato il processo attorno al loro utilizzo?

— FrustratedWithFormsDesigner il

1

Di questi, ho usato solo Jira (sono d'accordo sul fatto che sembra avere un sacco di spese generali, fino a quando non ti abitui al suo "ritmo"). Non è un fan dell'interfaccia utente Web, ma ottiene il lavoro svolto. Qui, usiamo anche MKS, che fa anche il controllo del codice sorgente. È meglio di Jira. Nessuno di questi è perfetto, ma sono ancora meglio delle note di carta e dei ricordi organici fallibili delle persone.

— FrustratedWithFormsDesigner il

15

Immagino di essere confuso dalla domanda. L'uso dei post-it su una lavagna È un sistema di tracciamento dei problemi. Se il tuo progetto / team / base di codice è abbastanza piccolo e i post-it + faccia a faccia funzionano, probabilmente avrai difficoltà a convincerti ad aggiungere più spese generali al processo. Ci sono molti lati negativi nell'utilizzare un sistema del genere, come indicato di seguito. Non appena il progetto e il team crescono, specialmente quando i membri del team potrebbero non trovarsi nello stesso edificio, città o paese, altri sistemi iniziano a brillare come indicato nelle risposte di seguito.

— s_hewitt,

2

come si collega una traccia dello stack a un post? o uno screenshot? o un messaggio di errore?

— jk.

41

Ci vuole troppo tempo per descriverne i problemi. Questo scoraggia il suo utilizzo.

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

Crei un posto per conservare i tuoi bug. E se c'è un posto per loro, le persone di solito non si preoccupano troppo di riparare un bug perché possono metterlo lì in modo che un giorno qualcuno possa risolverlo (o no).

Questo è un problema con la tua squadra non con il software.

Con il tempo, la lista dei bug diventa così lunga che nessuno può più occuparsene, impiegando molto del nostro tempo.

Ancora una volta descrivi un problema con la tua squadra.

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

— Tom Squires
fonte

Il software di tracciamento aiuta anche a tenere traccia dei bug da correggere. Una nota appiccicosa può cadere e se quattro persone arrivano da te con bug su cui puoi lavorare, allora potresti sistemarne tre e dimenticare il quarto. È utile anche se non presti attenzione alle cause degli errori.

— David Thornley,

e per risolvere il problema con il tuo team potresti usare la gamification -> en.wikipedia.org/wiki/Gamification

— marc.d

11

@JoaoBosco: i biglietti scritti a mano si perdono, si scarabocchiano, si buttano per sbaglio ... le conversazioni faccia a faccia sono fantastiche, tranne quando si descrivono bug complessi a persone che non hanno memoria fotografica. La gente si dimentica le cose da conversazioni, non perché vogliono, ma perché questo è semplicemente ciò che accade.

— FrustratedWithFormsDesigner il

3

@JoaoBosco: che dire degli screenshot degli errori della GUI? Li ridisegnerai a mano? Esempi di output di dati errati (se si tratta di un errore del database, siete pronti a scrivere manualmente n righe con m colonne di dati errati)? Altre forme di artefatti digitali associati al difetto che non si traducono bene in bigliettini? Tutte queste cose possono essere facilmente associate a un ticket in un sistema di tracciamento dei problemi. E se in seguito convertirai la tua nota adesiva in file di testo, perché non un database che ti consente di ordinare, ordinare, classificare i tuoi biglietti, quindi un po 'di più per il rilevamento dei problemi.

— FrustratedWithFormsDesigner il

10

@ user1062120: "Se non c'è posto per conservare i bug, le persone iniziano a correggerli più spesso" - oppure iniziano a ignorare e dimenticare i bug. Non è un "trucco per motivare le persone" ma un assurdo tentativo di rietichettare una debolezza in una forza.

— Michael Borgwardt,

12

IMO il tuo punto di partenza è distorto. Se gli sviluppatori non riescono a correggere i bug, il progetto è destinato a fallire, indipendentemente dal fatto che seguano i bug utilizzando uno strumento di tracciamento dei bug adeguato, post-it, sculture in pietra o per niente. Non è colpa dello strumento se non viene utilizzato o utilizzato in modo improprio. (Detto questo, ci sono ovviamente tracker di bug / problemi difettosi là fuori ... Ho lavorato su un progetto usando uno strumento totalmente inadeguato per questo lavoro, quindi penso di sapere quanto può essere male. Ma ce ne sono anche di buoni, che richiedono un minimo di cerimonia e spese generali, consentendoti di concentrarti sulle informazioni pertinenti.)

Se, tuttavia, 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 (tutto ciò è abbastanza comune nei progetti del mondo reale ), presto sorgeranno domande come:

Quale dei bug aperti dovrebbe essere corretto per primo? (nota: in un progetto sano, questo dovrebbe essere deciso dal proprietario e / o dalla direzione del prodotto, NON da uno sviluppatore - per il quale devono prima essere consapevoli di tutti i bug aperti!)
Quanti bug aperti abbiamo e di quale gravità?
Quale di questi deve essere risolto prima di essere pronti per il rilascio?
Quanto tempo per pianificare queste correzioni, che spesso porta a: quanto tempo impiega a correggere un bug in media?
quanti bug sono stati segnalati dai client nell'ultima versione?
chi ha risolto questo e questo bug, quando e quali modifiche (codice / configurazione / dati) ha comportato la correzione?
quali correzioni di bug sono incluse nella versione che stiamo per pubblicare?
...

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

Sì, l'immissione dei dati dei bug in un tracker di problemi comporta un certo sovraccarico. Tuttavia, è più che compensato dal tempo e dallo sforzo risparmiati nella ricerca e nella creazione di report come sopra, dai dati dei bug memorizzati.

— Péter Török
fonte

I post-it non risponderanno a tutto. È solo uno strumento. Puoi ancora stabilire le priorità, fare statistiche su bug aperti, risolti e così via. Tutto quello che sto dicendo è che penso che i sistemi di tracciamento dei problemi possano essere più controproducenti che aiutarti a risolvere i problemi di gestione che hai.

— user1062120

7

@ user1062120: E tutti gli altri dicono che ti sbagli molto. I post-it sono un sistema di tracciamento dei problemi, molto scarso e privo di molte funzionalità essenziali.

— Michael Borgwardt,

@utente1062120, ovviamente in teoria si potrebbe rispondere a tutte queste domande usando le note appiccicose - se si aggiungono ID univoci a ciascuna, continuare ad aggiungere commenti cronologici dettagliati su di esse (quindi dopo un po 'si iniziano ad avere bisogno di note appiccicose piuttosto grandi :-), e passare una terribile quantità di tempo a smistare, riordinare e riordinarli in base alla domanda corrente (per la quale potrebbe essere necessario assumere un nuovo ragazzo in un progetto più grande ;-).

— Péter Török,

@ user1062120, ad es. pianificazione dei rendimenti Domanda 1 sopra: riorganizziamo le note adesive in base alla priorità. Presto PM chiede Q2: oops, riorganizzare per gravità. Ma Q1 è ancora aperto, quindi ora ordiniamoli di nuovo tutti per priorità. Oops, 3 post-it sono stati esclusi perché erano sulla scrivania di Joe - ricominciare da capo! Quindi Q6: estraiamo le scatole che memorizzano i post-it storici, sfogliamo tutti a mano per trovare quello giusto, quindi proviamo a leggere lo scarabocchio sul dorso, pensato per descrivere i cambiamenti ... oops, qualcuno ha aperto un finestra vicina, affrettati a salvare i tuoi post-it dalla fuga dal vento ... ecc.

— Péter Török

9

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 diversi team, in particolare se le correzioni verranno rilasciate in diverse versioni di codice. I progetti complessi avranno molte parti / componenti mobili e garantire che i problemi siano pianificati e risolti è una parte importante di un'implementazione di monitoraggio dei problemi

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

— JW8
fonte

1

Grazie mille per i riferimenti. Li darò un'occhiata. E sì, sta lavorando all'interno di 3 piccoli team qui.

— user1062120

2

+1 per i riferimenti, che sono stati esplicitamente richiesti nella domanda.

— mattnz,

4

Ci possono essere studi, ma ancora meglio sono le esperienze duramente guadagnate delle persone sul campo. La maggior parte dei sistemi di localizzazione dei problemi risente dei processi che guidano la loro progettazione. I tracker dei problemi spesso devono supportare 2 classi distinte di utenti:

Il team di sviluppo
Gli utenti del sistema

Cal Henderson (precedentemente Flickr) ha un ottimo post sulla progettazione di molti tracker di problemi e sul perché preferisce il tracker di problemi di GitHub (come faccio io). Inoltre, Garrett Dimon ha trattato il design di Sifter e ha illustrato un modo per semplificare il processo per un monitoraggio più efficace dei problemi . Ho adottato alcune delle idee di entrambi questi post per aiutare a semplificare il flusso di lavoro di monitoraggio dei problemi del mio team.

Detto questo, dipende ancora dalle persone rispetto ai processi e agli 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 non appena il bug viene archiviato sulla questione se si tratti o meno di un problema. Una volta presa la decisione, il bug entra in Pivotal Tracker. La differenza qui è che usiamo Tracker per stabilire le priorità , non come penna di tenuta per cose che non vogliamo fare. In effetti quando l'Icebox inizia a diventare troppo grande, elimino attivamente gli elementi, inclusi i bug. Se un problema è abbastanza grande da dover essere gestito, si risolverà di nuovo.

Raramente abbiamo bisogno della cronologia dei bug. Occasionalmente, qualcuno può menzionare un sintomo di un bug e potremmo fare una ricerca per vedere se è correlato a qualche problema che abbiamo già risolto. Ma è raro.

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

— kstewart
fonte

Questo è esattamente ciò che intendevo. Diamo anche la priorità agli articoli non appena compaiono e cancelliamo anche gli articoli non importanti. Le cose importanti torneranno indietro nel tempo. Ho scoperto che il sovraccarico per tenere traccia di tutto non è degno. L'idea di avere una piccola lavagna bianca post-it è che non puoi fisicamente registrare tutto, solo le cose importanti. Quindi questo trucco ti costringe a gestirlo il prima possibile. Ma questo è il mio caso, quindi non sono sicuro che funzionerebbe ovunque.

— user1062120

2

uccidendo bug importanti non appena compaiono

Sembra che stai sfondando la porta aperta qui. I bug importanti vengono "uccisi" il più presto possibile, indipendentemente dal fatto che si usi il tracker dei problemi o meno.

Oh, e la parte "come appaiono" è piuttosto sdrucciolevole. In un progetto abbiamo avuto un bug importante che minacciava di far fallire l'intero prodotto (cosa potrebbe essere più importante?). È stato molto complicato (errore di architettura) e sapevamo che ci vorrà molto tempo per risolverlo. I clienti hanno gentilmente accettato di darci un anno per la riparazione (prima di abbandonare il nostro prodotto) e lo abbiamo fatto in circa un anno.

Per quanto riguarda i tracker dei problemi, li uso da quasi dieci anni e, di regola, tutti i programmatori che mi circondano hanno trascorso un po 'di tempo con il tracker (nota che sto parlando di programmatori; i manager hanno storie diverse). 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 rilevamento dei problemi, di nuovo sembra che tu stia sfondando la porta aperta qui. Il rilevamento dei problemi è una tipica comunicazione scritta ; ci sono molte ricerche che dimostrano che per discutere di cose, la comunicazione di face2face è molto più efficiente rispetto al telefono, che a sua volta è molto più efficiente di quella scritta .

In realtà dato che chiedi di f2f sembra che tu stia usando il tracker per discutere delle cose - questo non è il suo scopo. Per capire la sua destinazione d'uso, basta scrivere il suo nome lentamente e chiaramente: emetti il sistema di tracciamento .

la lista dei bug diventa così lunga

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

Con una lunga lista di bug, gli sviluppatori possono impostare una coda e pianificare correzioni molto più avanti. Questo è tanto produttivo quanto diventa; per me questo è fondamentalmente un nirvana quando ho una tale fila con cui lavorare. Primo bug - correzione - fatto, secondo bug - correzione - successivo, bug successivo - correzione - fatto ecc. Ecc. Nessuna stupida interruzione, nessuna distrazione dolorosa con conversazioni f2f così efficienti, flusso puro .

Ricordo solo un caso in cui le lunghe liste di bug sono state un problema. Accadde quando un idiota della direzione superiore decise una politica che costringeva 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 intensificarlo sulla sua testa e risolverlo.
Qualche tempo dopo che siamo riusciti a stabilire un flusso di lavoro conveniente, abbiamo scoperto che il nostro "backlog infinito" si è svuotato magicamente.

— moscerino
fonte

2

Di recente ho trascorso 2,5 giorni a guadare oltre 300 bug aperti (principalmente UI) accumulati in oltre un anno, tutti assegnati a freelance / stagisti da tempo, o al project manager che non aveva tempo per gestirli. Ho scoperto che avrei potuto chiuderne circa la metà come già riparate o non più rilevanti. Il resto viene fissato a un ritmo decente dopo che li ho assegnati alle persone giuste. Il sistema di tracciamento dei bug era usato male, ma senza di esso, tutti quei bug (senza ostacoli, ma alcuni piuttosto brutti) sarebbero stati sicuramente dimenticati.

— Michael Borgwardt,

1

@MichaelBorgwardt yeah elenchi così a lungo che nessuno può affrontarlo nella mia esperienza è sempre risultato gestibile fintanto che uno non viene congelato da numeri spaventosi come 200, 400, 1000. Ho appena fatto un rapido controllo per curiosità - per l'anno scorso ho risolto più di 300 problemi, solo io (!). Per curiosità ho anche controllato gli altri ragazzi in squadra pensando che forse sono unico - no, 200-400 correzioni / anno sembrano solo un tasso medio. 500 bug comunque spaventosi sembrano, potrebbero essere solo sei mesi di lavoro per 4-5 sviluppatori, un gioco da ragazzi :)

— moscerino