Acho que todas as respostas "sim" ajudam muito a endossar a ideia. Mas vou jogar fora a ideia de que a decisão é baseada em algumas perguntas:

• Como você deseja se comunicar como uma equipe? Com dois desenvolvedores, agora você é uma equipe. Como você quer se comunicar? Muitas equipes ágeis vivem com discursos em pessoa e esboços em quadros brancos. Mas eles também podem ir tão longe a ponto de anotar as coisas, especialmente se for um bug que não estará no topo da lista de prioridades por um tempo.
• Como você deseja se comunicar com seus clientes? Eu não sei a resposta para isso, mas se você tem algum motivo para publicar bugs (ou bugs corrigidos em um documento de versão), então você ' vai acabar escrevendo-os eventualmente. Poderia também escolher um sistema de gerenciamento de bugs de baixo estresse e acabar com isso.
• Existe valor para preservar o histórico? A resposta pode ser "não agora", mas se você acha que, no futuro, gostaria de ver a tendência dos bugs para ver os lugares que os usuários ter mais problemas, ou lugares onde você poderia passar algum tempo checando e revisando antes de um grande lançamento - então pegue um sistema de rastreamento de bugs. A coisa sobre a história é que o dia em que você quer o registro não é o dia em que você deve começar a manter registros.

IMO, as respostas para essas perguntas são mais sobre onde você vê o produto e como você quer aumentar sua equipe e menos sobre se "2 pessoas = razão para o sistema de rastreamento de bugs". A pergunta maior provavelmente é "um sistema de rastreamento de bugs vale a pena o tempo para configurar & gerenciar e o custo de compra?"

1, mas somente se for indolor. O GitHub, por exemplo, tem um rastreador de problemas muito simples e utilizável com mais do que suficiente recursos para uma pequena equipe. O Bugzilla, o Trac ou outros são bons, mas todos eles requerem hardware, instalação e configuração antes do uso, e a manutenção é definitivamente uma despesa diferente de zero.

Tivemos uma equipe muito pequena na primeira vez que usei software de rastreamento de bugs e fiquei impressionado com o volume de coisas que tínhamos pensado que precisávamos para consertar e que de alguma forma nunca foram consertadas. Vale a pena, não importa o tamanho do seu time.

How big of a team do you need to benefit from bug tracking software?

1

Sim. Mil vezes sim.

Nem pense nisso em termos de acompanhamento de bugs, mas como controle de tickets.

Ser capaz de ver todas as suas tarefas em tickets tem uma enorme vantagem. Você pode manter um histórico de uma tarefa em um só lugar. Você sabe quem trabalhou e quando. Você pode ser tão detalhado quanto dizer o que foi concluído em que dia para uma tarefa.

Para o rastreamento de bugs, você pode colocar todos os seus bugs em um só lugar e acompanhar quais foram concluídos e quais ainda estão em andamento.

Isso apenas ajuda você a gerenciar as coisas muito melhor.

Vale a pena com uma equipe de um ou mais.

Se você comprar uma solução formal de software ou não, terá um sistema de rastreamento de bugs / recursos. Pode ser no bloco de notas, pode ser notas adesivas, pode estar em um bloco de comentários no topo do seu código. No entanto, a menos que você esteja apenas desenvolvendo aleatoriamente, você estará anotando suas listas de tarefas em algum lugar. Por que não usar um sistema mais organizado que pode crescer com sua equipe?

Você não precisa de nenhum software de rastreamento de bugs, desde que todos os membros da equipe

• Tem uma memória fotográfica perfeita e
• É possível sincronizar seus pensamentos com todos os outros membros da equipe.

A resposta curta é sim.

Algumas razões:

1. Capacidade de registrar erros encontrados em versões específicas.
2. Capacidade de saber quais (conhecidos) bugs ainda não foram corrigidos.
3. Acompanhe quem corrigiu um bug que foi encontrado novamente.
4. Giro do desenvolvedor - permite a transferência de conhecimento mesmo se você for atingido pelo ônibus proverbial.

Você provavelmente desejará ver algo que não levará muito tempo para você configurar / gerenciar. Também sugeriria procurar algo que inclua essa capacidade de integrá-lo ao seu controle de origem.

Esta resposta é para adicionar peso ao lado YES do argumento.

Eu sou principalmente um time de um. Eu uso extensivamente o rastreamento de problemas (redmine) junto com a integração com o SVN.

É verdadeiramente soberbo e eu ficaria louco sem ele; minha qualidade cairia porque eu esqueceria as coisas e deixaria de lado o que tenho para trabalhar.

Ferramentas de produtividade:

• IDE decente
• Acompanhamento de problemas
• Controle de origem

Acompanhamento de problemas; não saia de casa sem ela

Se você tem menos de 3 anos, provavelmente você pode conseguir com uma planilha do Google Docs, talvez, eu acho. Mas realmente o custo de instalar o bugzilla ou algo semelhante em algum lugar é tão trivial ao lado do custo de um programador que você é melhor fazê-lo. (Além disso, quando você crescer para 7, ele já estará lá)

Até mesmo um time de um pode se beneficiar de algum tipo de rastreador de bugs, seja um arquivo de texto de notas, ou algum software completo. Para dois desenvolvedores, eu recomendaria apenas investir tempo na criação de algum sistema de rastreamento de bugs, não de dinheiro. Dependendo do projeto, você pode se dar bem escrevendo bugs no papel, mantendo uma lista através de um documento online compartilhado, ou usando um software gratuito de rastreamento de bugs, como o Trac ou o Bugzilla. O Fogbugz também está disponível como teste gratuito por 45 dias.

Sim.

Você precisa rastreá-los de alguma forma!

O problema é quantos bugs você tem, em vez de quantos desenvolvedores. Você pode gerenciar com uma planilha de excel ao lidar com alguns bugs, mas mesmo assim não é o melhor.

Existe um benifet definitivo - eu uso software de rastreamento de bugs, mesmo em projetos pessoais. É útil não apenas para rastrear bugs, mas também para rastrear TODOs e solicitações de recursos.

Eu usei bugs em todos os lugares quando estou trabalhando sozinho. Funciona com o seu DVCS, mantendo as informações do bug em conjunto com a sua fonte. Sobrecarga muito baixa, pois não requer nenhum servidor central. A desvantagem é que você precisa ter cuidado com as ramificações nas quais insere novos bugs para garantir que elas se propaguem em tempo hábil, embora não seja muito importante se você deseja rastrear seus próprios bugs e o que foi consertado em sua última atração, do que rastrear o status de uma equipe como um todo.

Basta começar a usar um

Se você começar a usá-lo, começará a perceber sua conveniência na prática, bem como o software de controle de versão ou, ainda, o controle de versão distribuída.

Maturidade no desenvolvimento

Não importa se você tem uma equipe de 100 ou 1, comecei a usar o controle de bugs e controle de versão distribuída (faz muito sentido por causa de commits locais) para mim e para mim e eu já me senti em outro nível , mas não só isso, eu poderia administrar meu trabalho em outro nível ... até um nível que pudesse escalar sem que eu investisse mais esforço.

Usando um rastreador você pode antecipar problemas e priorizar o trabalho, rastreadores de bugs / problemas não são apenas para bugs / problemas, eles são mais para administração de projetos, e todo e qualquer projeto deve ter isso .

Para mim, não se trata apenas do software, mas do processo que o rodeia. No meu dia-a-dia como Gerente de Testes eu basicamente moro em um e isso oferece os seguintes benefícios:

Acho que isso funciona muito bem com mais de 2 testadores e mais de 3 desenvolvedores.

Gerenciamento dos esforços de correção de erros do desenvolvedor

Nós gerenciamos ativamente uma "fila de erros" de desenvolvedores para controlar quanto trabalho eles atribuíram a eles e garantimos que tenhamos uma alocação de nível de trabalho de correção de bugs na equipe.

Decidindo o que é e o que não é consertado

Triagem através de novos bugs em um processo diário é uma ótima maneira de ajudar a focar no que você faz e não conserta, assim como quando você corrige isso. No começo de um projeto, você quer consertar tudo. No final, você só quer consertar os stoppers, e a ferramenta de rastreamento de bugs é ótima para isso

Quando você precisa de métricas

O mais importante para mim é o Metrics, ou seja, quando você quiser ver o bug encontrar e corrigir tendências, onde estão as áreas problemáticas do código ou a rapidez com que os testadores estão encontrando e testando novamente os bugs. É hora de um sistema de rastreamento de bugs.

Concordo com a opinião comum de que um membro da equipe é suficiente para começar a precisar de um rastreador de bugs. Eu o caracterizaria como obrigatório depois de ter um ou dois usuários reais, mas importante bem antes de seu primeiro lançamento.

Pessoalmente, eu gosto de fóssil para controle de fontes e rastreamento de bugs. É um SCM distribuído de baixa cerimônia completo que está bem integrado a um bug tracker e um wiki. E é uma instalação executável única, amplamente portátil, e usa um aplicativo da Web interno como sua GUI. Sua home page é na verdade servida quase inteiramente por uma cópia de fósseis.

Com o rastreador totalmente integrado ao controle de revisão, é possível vincular facilmente as alterações a tickets e ver as atualizações de tickets na mesma linha do tempo como revisões (e edições da página da wiki).

Um. Nesse caso, é mais uma lista de tarefas.

Eu assumo investindo o tempo. Há muitos sistemas gratuitos de rastreamento de bugs, que devem ser bons para uma equipe de duas pessoas. Eu não procuraria ofertas comerciais até ter uma equipe maior.

Acho que sua pergunta destacou seu equívoco. Pois não é a equipe que precisa de rastreamento de bugs, é o (s) produto (s).

Então, o acompanhamento de bugs precisa ser feito em software? Bem, isso ajudaria, você não acha?

Pode não valer a pena se as duas condições a seguir estiverem presentes:

1. Os problemas têm vida curta. Nesse caso, pode ser o suficiente com um quadro de tarefas simples (já que é inteligente visualizar o fluxo de trabalho por vários outros motivos). No entanto, se você não conseguir resolver problemas rapidamente, f.ex. Para corrigir erros rapidamente, você achará útil acompanhar o problema.
2. Alterações de código são documentadas com testes automatizados como documentação ativa. Ou seja, bugs e correções são documentados com testes de falha quando eles aparecem, com testes de passagem se tornando testes de regressão após a correção. - E as alterações de funcionalidade são documentadas com testes de aceitação automatizados (por exemplo, usando algumas ferramentas do BDD, como FitNesse ou Pepino). Essa documentação deve estar facilmente disponível em um servidor de IC como o Jenkins.

Se 1 ou 2 não estiverem presentes, você se beneficiará do rastreamento de problemas.

Sim, sim, sim, sim! Ser capaz de rastrear, priorizar e gerenciar seus problemas é fundamental para o desenvolvimento bem-sucedido de software. Com uma pessoa, você pode (quase) se safar com uma planilha e fechando árvores de fontes antigas. Adicionar até mesmo um desenvolvedor a um projeto muda as coisas drasticamente - de repente, o rastreamento de problemas e o controle do código-fonte são necessários, ou você estará descartando problemas, substituindo a funcionalidade e, geralmente, tendo um tempo ruim.

Estou surpreso que ninguém mencionou a empresa matriz do StackExchange, a FogCreek, ainda - seu software FogBugz é o melhor aplicativo de rastreamento de problemas que já usei. Alta velocidade, baixo arrasto e preços acessíveis, especialmente se você usar a solução hospedada. Eles costumavam ter um teste hospedado gratuito que tinha, acredito, duas licenças de usuário gratuitas - pode não ser mais o caso, mas eu recomendo que você verifique isso.

aqui estão meus 2 centavos.

para o acompanhamento de bugs: basta usar uma planilha do google-doc, posso convidar qualquer pessoa que eu queira editar ou visualizar. é livre, não muito de um investimento. Eu mantenho o controle de todas as tarefas para apenas bugs.

Eu também executo o SVN no meu host que não adiciona nenhum custo adicional à hospedagem na web.

alguns clientes exigiram o uso de unfuddle ou outro software de gerenciamento de projetos / acompanhamento de bugs, mas eu preferiria as soluções gratuitas que mencionei acima.

Se você tem um bug tracker minimalista, eu diria que é útil mesmo para um time de um. Em um dos sites de projetos do meu amigo QuokForge , eles fornecem basicamente uma instância da Red Mine para cada projeto. Red Mine, na minha opinião, tem um bom bug tracker (mesmo que seja um pouco estranho às vezes). Isso porque você pode registrar um bug digitando apenas texto em um campo. Eu também usei o FogBugz antes. É grátis para 2 ou menos pessoas. E permite a mesma simplicidade, preenchendo um erro preenchendo apenas um campo de texto. (Ele também fornece gráficos e outras coisas que são insanamente úteis)

Basicamente, não faça o arquivamento de um processo estrito e formal exigindo que você reserve 30 minutos para preencher um relatório de bug (BugZilla, estou olhando para você). Isso significa apenas que as pessoas não vão usá-lo.

Finalmente, ter uma lista de erros (mesmo que todos os erros contenham cerca de 50 caracteres de texto) é extremamente valioso. "Hmm, prestes a lançar 1.0. Penso que consertei o último dos bugs." E também é ótimo para os gerentes verem que você está realmente fazendo algo :). Em uma equipe, é mais valioso porque você não está tentando manter um conjunto diferente de listas de tarefas mentais em sua cabeça. E isso corrige o "Você consertou isso [bug de segurança muito ruim]? Hum, sim, eu acho que sim. Ok, vamos liberar o 1.0 então".

Eu também adoro acompanhar os recursos também. Isto é um pouco mais opcional, mas eu ainda acho que é benéfico poder descarregar a tarefa mental de manter uma lista de tarefas na minha cabeça.

Além disso, veja o que Joel tinha a dizer sobre isso

Você acabou de chegar a esse número ... 2 ! Embora eu possa ver os benefícios de usar o software de rastreamento de bugs, mesmo se você for o único desenvolvedor ... você pode passar sem ele quando o número total de desenvolvedores for 1.

No entanto, assim que você tiver dois ou mais desenvolvedores, não há uma única razão para não ter um software de rastreamento de bugs, não um.

Sim. E uma recomendação é o link do bitbucket. Eles fornecem rastreamento gratuito de bugs, bem como repositórios Privados gratuitos no mercurial.

Não

Não rastreie bugs, corrija-os .

Não é o tamanho da equipe que importa, há quanto tempo você está disposto a analisar os erros em uma lista antes de corrigi-los.

Se você estiver usando o Agile / TDD, sua lista de bugs será curta e os bugs não permanecerão na lista por muito tempo. Qualquer sistema de rastreamento será suficiente nesse caso.