Il mio team di sviluppo è appena cresciuto del 100% (da 1 sviluppatore a 2). La mia nuova coorte vuole investire in software di tracciamento dei bug. Ci sono vantaggi in questo tipo di software per un team così piccolo?

Penso che tutte le risposte "sì" facciano molto per approvare l'idea. Ma ho intenzione di buttare fuori l'idea che la decisione si basa su alcune domande:

• Come vuoi comunicare come una squadra? Con 2 sviluppatori, ora sei una squadra. Come vuoi comunicare? Un sacco di squadre agili convivono con discusioni di persona e schizzi di lavagna. Ma possono anche arrivare a scrivere cose, soprattutto se si tratta di un bug che non sarà in cima alla lista delle priorità per un po '.
• Come vuoi comunicare con i tuoi clienti? Non conosco la risposta a questa domanda, ma se hai qualche motivo per pubblicare bug (o bug corretti in un documento di rilascio della versione), alla fine finirai per scriverli. Potrebbe anche scegliere un sistema di gestione dei bug a basso stress ed essere fatto con esso.
• C'è valore nel preservare la storia? La risposta potrebbe essere "non adesso", ma se pensi che in futuro ti piacerebbe vedere la tendenza dei bug in modo da poter vedere i luoghi in cui gli utenti hanno più problemi o luoghi in cui potresti passare un po 'di tempo a controllare e rivedere prima di un'importante versione, quindi ottenere un sistema di tracciamento dei bug. La cosa sulla storia è che il giorno in cui desideri che il record non sia il giorno in cui dovresti iniziare a conservare i record.

IMO, le risposte a queste domande riguardano più dove vedi il prodotto in corso e come vuoi far crescere il tuo team e meno se "2 persone = motivo del sistema di tracciamento dei bug". La domanda più grande è probabilmente "un sistema di tracciamento dei bug vale il tempo di configurare e gestire e il costo di acquisto?"

1, ma solo se è indolore. GitHub per esempio ha una molto semplice e usabile issue tracker con più che sufficienti caratteristiche di un piccolo team. Bugzilla, Trac o altri sono buoni, ma richiedono tutti hardware, installazione e configurazione prima dell'uso e la manutenzione è sicuramente una spesa diversa da zero.

Avevamo un team molto piccolo la prima volta che ho usato un software di tracciamento dei bug e sono rimasto sorpreso da quante cose stavamo pensando che dovevamo risolvere che in qualche modo non sono mai stati corretti. Ne vale la pena, non importa quanto sia grande la tua squadra.

Sì. Mille volte sì.

Non pensarci nemmeno in termini di tracciamento dei bug ma come tracciamento dei biglietti.

Essere in grado di vedere tutte le tue attività nei biglietti ha un enorme vantaggio. È possibile conservare la cronologia di un'attività in un unico posto. Sai chi ci ha lavorato e quando. Puoi essere dettagliato come dire cosa è stato completato in quale giorno per un'attività.

Per il rilevamento dei bug, puoi posizionare tutti i tuoi bug in un unico posto e tenere traccia di quelli che sono stati completati e di quelli che sono ancora in corso.

Ti aiuta a gestire le cose molto meglio.

Ne vale la pena con una squadra di uno o più.

Ammettilo, sia che tu acquisti una soluzione software formale o meno che tu abbia un sistema di tracciamento di bug / funzionalità. Potrebbe 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 semplicemente sviluppando in modo casuale, annoti da qualche parte le tue liste di cose da fare. Perché non utilizzare un sistema più organizzato che può crescere con il tuo team?

Vale anche la pena considerare: molti tracker di bug sono gratuiti per l'utilizzo da parte di team molto piccoli (1-2), quindi non è come se dovessi sostenere spese importanti per il vantaggio.

Non è necessario alcun software di tracciamento dei bug, purché tutti i membri del team

• Ha una memoria fotografica perfetta, e
• È in grado di sincronizzare i propri pensieri con tutti gli altri membri del team.

La risposta breve è sì.

Alcuni motivi per cui:

1. Possibilità di registrare i bug che sono stati trovati su versioni specifiche.
2. Possibilità di sapere quali bug (noti) non sono stati ancora corretti.
3. Tieni traccia di chi ha corretto un bug che è stato ritrovato da allora.
4. Fatturato degli sviluppatori: consente il trasferimento delle conoscenze anche se si viene colpiti dal bus proverbiale.

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 è aggiungere peso al lato SÌ dell'argomento.

Sono principalmente una squadra di uno. Uso ampiamente il rilevamento dei problemi (redmine) insieme all'integrazione SVN.

È davvero fantastico e senza di esso impazzirei; la mia qualità calerebbe perché mi dimenticherei delle cose e perderei traccia di ciò su cui devo lavorare.

Strumenti di produttività:

• IDE decente
• Tracciamento dei problemi
• Controllo della fonte

Tracciamento dei problemi; non uscire di casa senza di essa

Se ne hai meno di 3, probabilmente puoi cavartela con un foglio di calcolo di Google Documenti, forse, suppongo. Ma davvero il costo dell'installazione di bugzilla o simili da qualche parte è così banale accanto al costo di un programmatore che stai meglio solo a farlo. (Inoltre quando cresci fino a 7 sarà già lì)

Anche un team di uno può beneficiare di una sorta di bug tracker, che si tratti di un file di testo di note o di un software completo. Per 2 sviluppatori, consiglierei solo di investire tempo nella creazione di un sistema di tracciamento dei bug, non di denaro. A seconda del progetto, puoi andare bene scrivendo i bug su carta, mantenendo un elenco attraverso un documento online condiviso o usando un software gratuito di tracciamento dei bug come Trac o Bugzilla. Fogbugz è disponibile anche come prova gratuita per 45 giorni.

Sì.

Devi seguirli un po 'come!

Il problema è quanti bug hai piuttosto che quanti sviluppatori. Puoi gestire un foglio Excel quando hai a che fare con alcuni bug, ma anche in questo caso non è il migliore.

Esiste un benifet definitivo: utilizzo software di tracciamento dei bug anche su progetti personali. È utile non solo per il monitoraggio dei bug, ma anche per il monitoraggio di "TODO" e richieste di funzionalità.

Ho usato bug ovunque quando lavoravo da solo. Funziona con il tuo DVCS mantenendo le informazioni sui bug insieme alla tua fonte. Sovraccarico molto basso in quanto non richiede server centrale. Il rovescio della medaglia è che devi stare attento a quali rami inserisci nuovi bug per assicurarti che si propaghino in modo tempestivo, anche se potrebbe non importare molto se vuoi principalmente tenere traccia dei tuoi bug e cosa è stato corretto nel tuo ultimo pull, piuttosto di tracciare lo stato di una squadra nel suo insieme.

Inizia a usarne uno

Se inizi a usarne uno, inizierai a renderti conto della loro praticità, in modo molto simile al software di controllo della versione o, per tale motivo, al controllo della versione distribuita.

Maturità dello sviluppo

Non importa se hai un team di 100 o 1, ho iniziato a utilizzare il tracciamento dei bug e il controllo della versione distribuita (ha molto senso a causa degli commit locali) solo per me e me stesso e mi sono già sentito ad un altro livello, ma non solo che, avrei potuto gestire il mio lavoro ad un altro livello ... a un livello che potrebbe ridimensionare senza che io investissi più sforzi.

Usando un tracker puoi anticipare i problemi e dare la priorità al lavoro, i tracker bug / issue non sono solo per bug / problemi, sono più per l'amministrazione del progetto e ogni progetto dovrebbe avere quello .

Per me non si tratta solo del software, ma del processo che lo circonda. Nel mio lavoro quotidiano come Test Manager sostanzialmente vivo in uno e offre i seguenti vantaggi:

Trovo che funzioni davvero bene con 2+ tester e 3+ sviluppatori.

Gestione delle attività di correzione dei bug degli sviluppatori

Gestiamo attivamente una "coda di bug" degli sviluppatori per controllare la quantità di lavoro loro assegnata e assicuriamo di disporre di un'allocazione di livello del lavoro di correzione dei bug in tutto il team.

Decidere cosa fa e non riparare

Il controllo attraverso nuovi bug su un processo quotidiano è un ottimo modo per aiutarti a concentrarti su ciò che fai e non risolvi, così come quando lo risolvi. All'inizio di un progetto, vuoi sistemare tutto. Alla fine, vuoi solo correggere gli stopper dello show, e lo strumento di tracciamento dei bug è ottimo per questo

Quando hai bisogno di metriche

La cosa importante per me sono le metriche, ovvero quando si desidera essere in grado di visualizzare la ricerca dei bug e correggere le tendenze, dove si trovano le aree buggy del codice o la velocità con cui i tester stanno trovando e testando nuovamente i bug. È tempo di un sistema di tracciamento dei bug.

Concordo con l'opinione comune secondo cui un membro del team è sufficiente per iniziare a necessitare di un bug tracker. Lo caratterizzerei come obbligatorio dopo che hai uno o due utenti reali, ma importante molto prima della tua prima versione.

Personalmente, mi piacciono i fossili sia per il controllo del codice sorgente che per il tracciamento dei bug. È un SCM completo a bassa cerimonia distribuito che è ben integrato in un tracker di bug e in un wiki. Ed è un'installazione a singolo eseguibile, ampiamente portabile, 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 delle revisioni, puoi facilmente collegare le modifiche ai ticket e visualizzare gli aggiornamenti dei ticket nella stessa visualizzazione della linea temporale delle revisioni (e delle modifiche alla pagina wiki).

Si si si SI! Essere in grado di tracciare, stabilire le priorità e gestire i problemi è la chiave per lo sviluppo di software di successo. Con una persona, puoi (quasi) cavartela con un foglio di calcolo e comprimere vecchi alberi di origine. L'aggiunta anche di uno sviluppatore a un progetto cambia radicalmente le cose: all'improvviso sono necessari il monitoraggio dei problemi e il controllo del codice sorgente, oppure si verificheranno problemi di rilascio, sovrascrittura delle funzionalità e generalmente si avrà un periodo miserabile di esso.

Sono sorpreso che nessuno abbia menzionato la casa madre di StackExchange, FogCreek, il loro software FogBugz è la migliore app di tracciamento dei problemi che abbia mai usato. Alta velocità, bassa resistenza e conveniente, soprattutto se si utilizza la loro soluzione ospitata. Avevano una versione di prova gratuita ospitata che, a mio avviso, aveva due licenze utente gratuite - potrebbe non essere più il caso, ma consiglierei di provarlo.

ecco i miei 2 centesimi.

per il tracciamento dei bug uso solo un foglio di calcolo Google-Doc, posso invitare chiunque voglia modificarlo o visualizzarlo. è gratuito quindi non molto di un investimento. tengo traccia di tutte le attività lì solo per i bug.

corro anche SVN sul mio host web che non aggiunge alcun costo aggiuntivo al web hosting.

alcuni clienti hanno richiesto l'utilizzo di software di dislocamento o altri software di gestione dei progetti / tracciamento dei bug, ma preferirei le soluzioni gratuite di cui sopra.

Se hai un bug tracker minimalista, direi che è utile anche per una squadra di uno. In uno dei siti di progetti del mio amico QuokForge , forniscono fondamentalmente un'istanza di Red Mine per ogni progetto. Red Mine, secondo me ha un buon tracker di bug (anche se a volte un po 'strano). Vale a dire perché è possibile presentare un bug inserendo solo il testo in UN campo. Ho anche usato FogBugz prima. È gratuito per 2 o meno persone. E consente la stessa semplicità, archiviando un bug compilando un solo campo di testo. (Fornisce anche grafici e altre cose che sono follemente utili)

Fondamentalmente, non rendere la presentazione dei bug 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 un elenco di bug (anche se tutti i bug contiene circa 50 caratteri di testo) è estremamente prezioso. "Hmm, in procinto di rilasciare 1.0. PENSO di aver corretto l'ultimo bug." Ed è anche bello per i manager vedere che stai effettivamente facendo qualcosa :). In una squadra, è più prezioso perché non stai entrambi cercando di tenere un diverso insieme di liste di cose da fare nella tua testa. E corregge il "Hai risolto quel [bug di sicurezza davvero brutto]? Uhm, sì, PENSO così. Ok, rilasciamo 1.0 allora."

Adoro anche tenere traccia delle funzionalità. Questo è un po 'più facoltativo, ma trovo ancora beneficio dalla possibilità di scaricare il compito mentale di tenere un elenco di cose da fare nella mia testa.

Inoltre, vedi cosa ha detto Joel a 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 semplicemente farne a meno quando il numero totale di sviluppatori è 1.

Tuttavia, non appena si hanno due o più sviluppatori, non c'è un solo motivo per non avere un software di tracciamento dei bug, nemmeno uno.

Sì. E una raccomandazione è bitbucket http://www.bitbucket.org Forniscono il monitoraggio gratuito dei bug e i repository privati gratuiti in mercurial.

Uno. Nel qual caso è più simile a un elenco di cose da fare.

Presumo investendo nel frattempo. Esistono molti sistemi gratuiti di tracciamento dei bug, che dovrebbero andare bene per un team di due persone. Non esaminerei le offerte commerciali fino a quando non avessi una squadra più grande.

Penso che la tua domanda abbia messo in evidenza il tuo malinteso. Perché non è il team che ha bisogno di tracciare i bug, è il / i prodotto / i.

Quindi, è necessario eseguire il tracciamento dei bug nel software? Bene, questo aiuterebbe, non credi?

Potrebbe non valerne la pena se sono presenti le seguenti due condizioni:

1. I problemi hanno una durata breve. In questo caso potrebbe essere sufficiente con una semplice scheda attività (poiché è intelligente visualizzare il flusso di lavoro per molte altre ragioni). Tuttavia, se non riesci a risolvere rapidamente i problemi, f.ex. correggendo rapidamente i bug, troverai utile tenere traccia del problema.
2. Le modifiche al codice sono documentate con test automatici come documentazione vivente. Vale a dire, i bug e le correzioni sono documentati con test falliti quando compaiono, con il superamento dei test che diventano test di regressione dopo la correzione. - E i cambiamenti di funzionalità sono documentati con test di accettazione automatizzati (ad esempio utilizzando alcuni strumenti BDD come FitNesse o Cucumber). Tale documentazione dovrebbe essere facilmente disponibile da un server CI come Jenkins.

Se 1 o 2 non sono presenti, beneficerai del rilevamento dei problemi.

No

Non tenere traccia dei bug, correggili .

Non è la dimensione della squadra che conta, è quanto tempo sei disposto a guardare i bug in un elenco prima di risolverli.

Se si utilizza Agile / TDD, l'elenco dei bug sarà breve e i bug non rimarranno a lungo nell'elenco. Qualsiasi sistema di tracciamento sarà sufficiente in quel caso.