Il mio team di sviluppo è cresciuto del 100% (da 1 sviluppatore a 2). La mia nuova coorte desidera investire nel software di tracciamento dei bug. Ci sono vantaggi per questo software per un team così piccolo?
Penso che tutte le risposte "sì" contribuiscano a sostenere l'idea. Ma ho intenzione di buttare fuori l'idea che la decisione si basi su alcune domande:
IMO, le risposte a queste domande riguardano più il luogo in cui vedi il prodotto e come vuoi far crescere la tua squadra e meno se "2 persone = motivo per il sistema di tracciamento dei bug". La domanda più grande è probabilmente "un sistema di tracciamento dei bug vale quanto il tempo per configurare e gestire e il costo di acquisto?"
1, ma solo se è indolore. GitHub ad esempio ha un tracker di problemi molto semplice e utilizzabile con più di abbastanza caratteristiche per una piccola squadra. Bugzilla, Trac o altri sono buoni, ma tutti richiedono hardware, installazione e configurazione prima dell'uso, e la manutenzione è sicuramente una spesa non zero.
Abbiamo avuto un team molto piccolo la prima volta che ho usato il software di tracciamento dei bug e sono rimasto sbalordito da quanta roba stavamo pensando di aver bisogno di aggiustare che in qualche modo non è mai stato corretto. Ne vale assolutamente la pena, non importa quanto sia grande la tua squadra.
How big of a team do you need to benefit from bug tracking software?
1
Sì. Mille volte sì.
Non pensarci nemmeno in termini di bug tracking ma come tracciamento dei ticket.
Essere in grado di vedere tutte le tue attività nei biglietti ha un enorme vantaggio. È possibile mantenere una cronologia di un'attività in un unico punto. Sai chi ci ha lavorato e quando. Puoi essere dettagliato come dire cosa è stato completato in quale giorno per un'attività.
Per il tracciamento dei bug, puoi mettere tutti i tuoi bug in un posto e tenere traccia di quelli che sono stati completati e di quelli che sono ancora in corso.
Ti aiuta solo a gestire le cose molto meglio.
Ne vale la pena con una squadra di uno o più.
Affrontalo, sia che tu stia acquistando una soluzione software formale o che non abbiate un sistema di tracciamento di bug / funzionalità. Può essere nel blocco note, potrebbe essere note adesive, potrebbe essere in un blocco di commenti nella parte superiore del codice. Tuttavia, a meno che tu non stia sviluppando casualmente, annoterai da qualche parte le tue cose da fare. Perché non utilizzare un sistema più organizzato che può crescere con la tua squadra?
Vale anche la pena di considerarlo: molti dei tracker di bug sono gratuiti per l'uso da parte di team molto piccoli (1-2), quindi non è che tu stia incorrendo in importanti spese per il beneficio.
Non è necessario alcun software di tracciamento dei bug a condizione che ogni membro del team
La risposta breve è sì.
Alcuni motivi per cui:
Probabilmente vorrai guardare qualcosa che non richiederà molto tempo per l'installazione / gestione. Suggerirei anche di cercare qualcosa che includa quella capacità di integrarlo con il controllo del codice sorgente.
Questa risposta è di aggiungere peso al lato SÌ dell'argomento.
Sono principalmente una squadra di uno. Uso estensivamente il rilevamento dei problemi (redmine) insieme all'integrazione SVN.
È veramente superbo e diventerei pazzo senza di esso; la mia qualità diminuirà perché mi dimenticherei delle cose e non saprei dire su cosa devo lavorare.
Strumenti di produttività:
Rileva il problema; non uscire di casa senza di esso
Se ne hai meno di 3, puoi probabilmente cavartela con un foglio di calcolo di google docs, suppongo. Ma in realtà il costo di installare bugzilla o simili da qualche parte è così banale, accanto al costo di un programmatore, che è meglio farlo semplicemente. (Inoltre quando cresci fino a 7 sarà già lì)
Anche una squadra di una può trarre vantaggio da una sorta di bug tracker, che si tratti di un file di testo di note o di un software in piena regola. Per 2 sviluppatori, consiglierei solo di investire tempo nella creazione di un sistema di tracciamento dei bug, non in denaro. A seconda del progetto, puoi ottenere buoni risultati scrivendo bug su carta, mantenendo un elenco tramite un documento online condiviso o utilizzando software di tracciamento dei bug gratuito come Trac o Bugzilla. Fogbugz è anche disponibile come prova gratuita per 45 giorni.
Sì.
Devi rintracciare loro come!
Il problema è quanti bug hai, piuttosto che quanti sviluppatori. Puoi gestire con un foglio Excel quando hai a che fare con alcuni bug, ma anche in questo caso non è il massimo.
C'è un sistema ben definito: utilizzo software di tracciamento dei bug anche su progetti personali. È utile non solo per il tracciamento dei bug, ma anche per il tracciamento di "TODO e richieste di funzionalità.
Ho usato bug ovunque lavorando solo da solo. Funziona con il tuo DVCS mantenendo informazioni sui bug insieme alla tua fonte. Overhead molto basso in quanto non richiede server centrale. Il rovescio della medaglia è che devi fare attenzione a quali rami inserisci nuovi bug per assicurarti che si propagino in modo tempestivo, anche se potrebbe non avere molta importanza se si vuole principalmente tenere traccia dei propri bug e cosa è stato risolto nell'ultima estrazione, piuttosto che monitorare lo stato di una squadra nel suo complesso.
Se inizi a utilizzarne uno, inizierai a realizzare la loro praticità in pratica, proprio come il software di controllo della versione o, per quanto riguarda ciò, il controllo della versione distribuito.
Non importa se hai una squadra di 100 o 1, ho iniziato a usare il bug tracking e il controllo della versione distribuita (ha molto senso a causa dei commit locali) solo per me e me stesso e mi sono già sentito ad un altro livello , ma non solo, potrei gestire il mio lavoro ad un altro livello ... ad un livello che potrebbe scalare senza che io investissi più sforzi.
Usando un tracker puoi anticipare i problemi e dare la priorità al lavoro, i bug / issue tracker non sono solo per bug / problemi, sono più per l'amministrazione del progetto e ogni progetto dovrebbe avere .
Per me non si tratta solo del software, ma del processo che lo circonda. Nel mio lavoro quotidiano come Test Manager in pratica vivo in uno e offre i seguenti vantaggi:
Trovo che funzioni molto bene con 2+ tester e 3+ sviluppatori.
Gestione degli sforzi di risoluzione dei bug degli sviluppatori
Gestiamo attivamente una "coda dei bug" per gli sviluppatori per controllare quanto lavoro hanno assegnato loro e ci assicuriamo di avere un'assegnazione di livello del lavoro di correzione dei bug all'interno del team.
Decidere cosa fa e non viene risolto
Triaging attraverso nuovi bug in un processo quotidiano è un ottimo modo per concentrarsi su ciò che si fa e non si risolve, così come quando lo si aggiusta. All'inizio di un progetto, vuoi sistemare tutto. Alla fine si desidera solo correggere i fermi degli spettacoli e lo strumento di tracciamento dei bug è ottimo per questo
Quando hai bisogno di metriche
La cosa più importante per me è la metrica, cioè quando si vuole essere in grado di vedere i bug trovare e correggere le tendenze, dove sono le aree bug del codice, o quanto velocemente i tester stanno trovando e ricontrollando i bug. È tempo di un sistema di tracciamento dei bug.
Sono d'accordo con l'opinione comune che un membro del team sia sufficiente per iniziare a richiedere un bug tracker. Lo classificherei come obbligatorio dopo che hai uno o due utenti reali, ma importante molto prima del tuo primo rilascio.
Personalmente, mi piace fossile per il controllo del codice sorgente e il bug tracking. È un SCM completo, a bassa cerimonia, ben integrato con un bug tracker e un wiki. Ed è un'installazione single-executable, ampiamente portatile, e utilizza un'applicazione Web interna come GUI. La sua home page è in realtà servita quasi interamente da una copia di fossili.
Con il tracker strettamente integrato con il controllo di revisione, puoi facilmente collegare le modifiche ai ticket e vedere gli aggiornamenti dei biglietti nella stessa visualizzazione della linea del tempo come revisioni (e modifiche alle pagine wiki).
Sì, sì, sì, sì! Essere in grado di tracciare, stabilire le priorità e gestire i propri problemi è la chiave per lo sviluppo del software di successo. Con una persona, puoi (quasi) farla franca con un foglio di calcolo e comprimere i vecchi alberi dei sorgenti. Aggiungendo anche uno sviluppatore a un progetto cambia le cose in modo drammatico: improvvisamente, è necessario il monitoraggio dei problemi e il controllo del codice sorgente, oppure si stanno per perdere problemi, sovrascrivere le funzionalità e in genere avere un tempo infelice.
Sono sorpreso che nessuno abbia menzionato la società madre di StackExchange, FogCreek, ancora - il loro software FogBugz è la migliore app per il rilevamento dei problemi che abbia mai usato. Alta velocità, bassa resistenza e conveniente, soprattutto se si utilizza la soluzione ospitata. Avevano una prova gratuita in hosting che aveva, credo, due licenze utente gratuite - che potrebbe non essere più il caso, ma ti consiglio di provarlo.
ecco i miei 2 centesimi.
per il monitoraggio dei bug uso solo un foglio di lavoro di google-doc, posso invitare chiunque voglia modificare o visualizzarlo. è gratis quindi non molto di un investimento. tengo traccia di tutti i compiti lì solo per i bug.
Eseguo anche SVN sul mio web-host che non aggiunge alcun costo aggiuntivo al web hosting.
alcuni clienti hanno richiesto l'uso di unfuddle o altri software di gestione dei progetti / bug tracking ma preferirei le soluzioni gratuite che ho menzionato sopra.
Se hai un bug tracker minimalista, direi che è utile anche per una squadra di uno. Oltre a uno dei siti del progetto di un mio amico QuokForge , forniscono fondamentalmente un'istanza Red Mine per ogni progetto. Red Mine, a mio parere ha un buon bug tracker (anche se un po 'strano a volte). Vale a dire perché puoi archiviare un bug inserendo il testo solo in un campo. Ho anche usato FogBugz prima. È gratuito per 2 o meno persone. E consente la stessa semplicità, archiviando un bug compilando solo un campo di testo. (Fornisce anche grafici e altre cose che sono follemente utili)
Fondamentalmente, non fare bug archiviare un processo rigoroso e formale che richiede di mettere da parte 30 minuti per compilare una segnalazione di bug (BugZilla, ti sto guardando). Questo significa solo che le persone non lo useranno.
Infine, avere una lista di bug (anche se tutti i bug contengono circa 50 caratteri di testo) è estremamente preziosa. "Hmm, bout to release 1.0. PENSO Ho risolto l'ultimo bug." Ed è anche bello per i manager vedere che stai effettivamente facendo qualcosa :). In una squadra, è più prezioso perché non stai cercando di mantenere un diverso insieme di liste mentali di cose da fare nella tua testa. E risolve il problema "Hai risolto questo [bug di sicurezza veramente brutto?" Uhm, penso che sia così. Ok, allora rilasciamo 1.0 ".
Mi piace anche tenere traccia delle caratteristiche. Questo è un po 'più opzionale, ma trovo ancora il vantaggio di essere in grado di scaricare il compito mentale di mantenere una lista di cose da fare nella mia testa.
Inoltre, vedi cosa Joel ha dovuto dire al riguardo
Hai appena raggiunto quel numero ... 2 ! Mentre posso vedere i vantaggi dell'utilizzo del software di tracciamento dei bug anche se sei l'unico sviluppatore ... puoi cavartela senza di esso quando il numero totale di sviluppatori è 1.
Tuttavia, non appena hai due o più sviluppatori, non c'è una sola ragione per non avere software di tracciamento dei bug, non uno.
Uno. In tal caso è più come una lista di cose da fare.
Suppongo che investendo intendi il tempo. Ci sono un sacco di sistemi di tracciamento dei bug gratuiti là fuori, che dovrebbero andare bene per una squadra di due persone. Non guarderei le offerte commerciali finché non avessi una squadra più grande.
Penso che la tua domanda abbia messo in luce il tuo malinteso. Perché non è il team che ha bisogno di bug tracking, è il prodotto (i).
Quindi, il bug tracking deve essere fatto nel software? Beh, sarebbe d'aiuto, non credi?
Potrebbe non valerne la pena se sono presenti le seguenti due condizioni:
Se 1 o 2 non è presente, trarrai vantaggio dal monitoraggio dei problemi.
Non tenere traccia dei bug, risolverli .
Non è importante per le dimensioni della squadra, ma per quanto tempo sei disposto a esaminare i bug in una lista prima di risolverli.
Se usi Agile / TDD, la tua lista di bug sarà breve e gli errori non dureranno a lungo sull'elenco. In tal caso, qualsiasi sistema di tracciamento sarà sufficiente.
Leggi altre domande sui tag issue-tracking