Existem estudos sobre as desvantagens do uso de sistemas de rastreamento de problemas? [fechadas]

Não gosto de sistemas de rastreamento de problemas porque:

• Leva muito tempo para descrever problemas nele. Isso desencoraja seu uso.
• Você cria um local para guardar seus bugs. E se houver um lugar para eles, as pessoas geralmente não se importam muito em consertar um bug, porque podem colocá-lo lá para que um dia alguém possa consertá-lo (ou não).
• Com o tempo, as listas de bugs ficam tão longas que ninguém mais consegue lidar com isso, ocupando muito do nosso tempo.

Prefiro lidar com problemas usando post-its em um quadro branco, conversas cara a cara e matando bugs importantes assim que aparecem. Não me importo muito em acompanhar o histórico de erros, porque não acho que valha a pena.

Estou sozinho aqui? Existem estudos (livro / artigo / qualquer que seja) sobre as desvantagens (ou grandes vantagens) do uso de sistemas de rastreamento de problemas?

Leva muito tempo para descrever problemas nele. Isso desencoraja seu uso.

Se você não consegue nem descrever um bug, como pode corrigi-lo?

Você cria um local para guardar seus bugs. E se houver um lugar para eles, as pessoas geralmente não se importam muito em consertar um bug, porque podem colocá-lo lá para que um dia alguém possa consertá-lo (ou não).

Esse é um problema com sua equipe e não com o software.

Com o tempo, as listas de bugs ficam tão longas que ninguém mais consegue lidar com isso, demorando muito tempo.

Mais uma vez, você está descrevendo um problema com sua equipe.

O objetivo do software de rastreamento de bugs não é ajudá-lo a motivar sua equipe a corrigir bugs, é manter um registro para que você possa rastrear a causa dos bugs e impedir que eles aconteçam novamente. Nenhum software será um substituto para o bom gerenciamento.

OMI seu ponto de partida é tendencioso. Se os desenvolvedores falharem na correção dos bugs, o projeto está fadado ao fracasso, sejam eles rastreados usando uma ferramenta adequada de rastreamento de bugs, post-its, esculturas em pedra ou não. Não é culpa da ferramenta se ela não for usada ou mal utilizada. (Dito isso, é claro que existem rastreadores de problemas / problemas ruins por aí ... Eu trabalhei em um projeto usando uma ferramenta totalmente inadequada para esse trabalho, então acho que sei o quão ruim pode ser. Mas também existem bons, que exigem cerimônia e despesas gerais mínimas, permitindo que você se concentre nas informações relevantes.)

Se, no entanto, os desenvolvedores se importarem, e o projeto for maior do que trivial, e houver mais de um desenvolvedor, haverá algum tipo de gerenciamento envolvido (todos bastante comuns em projetos do mundo real). ), em breve surgirão perguntas como:

1. Qual dos bugs abertos deve ser corrigido primeiro? (nota: em um projeto são, isso deve ser decidido pelo proprietário e / ou pelo gerenciamento do produto, NÃO por um desenvolvedor - para o qual eles devem estar cientes de todos os erros abertos antes de tudo!)
2. Quantos bugs abertos temos e com que gravidade?
3. Qual destes deve ser corrigido antes de estarmos prontos para o lançamento?
4. Quanto tempo para planejar essas correções - geralmente levando a: quanto tempo leva para corrigir um erro, em média?
5. quantos bugs foram relatados pelos clientes na última versão?
6. quem corrigiu esse e esse bug, quando e quais alterações (código / configuração / dados) a correção envolveu?
7. que correções de erros estão incluídas na versão que estamos prestes a publicar?
8. ...

Você pode responder a essas perguntas [atualizar] repetidamente, com confiabilidade e eficiência [/ atualizar] com base em suas notas post-it?

Sim, a inserção de dados de erros em um rastreador de problemas implica alguma sobrecarga. No entanto, é mais do que compensado pelo tempo e esforço economizados ao procurar e criar relatórios como o acima, a partir dos dados armazenados dos erros.

Sua metodologia pode funcionar para projetos muito pequenos com um número limitado de programadores. Quando um projeto cresce, ter um sistema de rastreamento de problemas se torna muito mais importante para a coordenação entre equipes diferentes, principalmente se houver correções em diferentes versões do código. Projetos complexos terão muitas partes / componentes móveis, e garantir que os problemas sejam agendados e corrigidos é uma grande parte de uma boa implementação de rastreamento de problemas

Alguns artigos / estudos que podem lhe interessar incluem este artigo que discute o uso de Jira por Zend e este estudo francês que discute o uso de sistemas de rastreamento de bugs.

Pode haver estudos, mas ainda melhores são as experiências duramente conquistadas pelas pessoas no campo. A maioria dos sistemas de rastreamento de problemas sofre com os processos que orientam seu design. Os rastreadores de problemas geralmente precisam oferecer suporte a 2 classes distintas de usuários:

1. A equipe de desenvolvimento
2. Os usuários do sistema

Cal Henderson (ex-Flickr) tem um ótimo post sobre o design de muitos rastreadores de problemas e por que ele prefere o rastreador de problemas do GitHub (como eu). Além disso, Garrett Dimon abordou o design do Sifter e ilustrou uma maneira de simplificar o processo para um rastreamento de problemas mais eficaz . Adotei algumas das idéias de ambas as postagens para ajudar a simplificar o fluxo de trabalho de rastreamento de problemas da minha equipe.

Tudo isso dito, ainda se resume às pessoas sobre processos e ferramentas. Meu pensamento geral é que os rastreadores de problemas tendem a criar esse backlog que você precisa gerenciar. Durante a triagem, é mais provável que as pessoas racionalizem o que é ou não um bug. Em nosso processo, tomamos decisões quase assim que o bug é arquivado sobre se é ou não um problema. Depois que essa decisão é tomada, o bug entra no Pivotal Tracker. A diferença aqui é que usamos o Tracker para priorizar , não como uma caneta para coisas que não queremos fazer. De fato, quando o Icebox começa a ficar muito grande, eu excluo ativamente itens, incluindo bugs. Se um problema for grande o suficiente para precisar ser resolvido, ele será exibido novamente.

Raramente precisamos de histórico de erros. Ocasionalmente, alguém pode mencionar um sintoma de um bug e podemos fazer uma pesquisa para verificar se está relacionado a algum problema que já resolvemos. Mas isso é raro.

TL; DR Concentre-se em seu processo, escolha ferramentas simples e resolva problemas à medida que eles surgirem.

matando bugs importantes assim que aparecerem

Parece que você está arrombando a porta aberta aqui. Erros importantes são "eliminados" o mais rápido possível, independentemente de você usar o rastreador de problemas ou não.

• Ah, e parte "como parecem" é bastante escorregadia. Em um projeto, tivemos um bug importante que ameaçava tirar todo o produto do negócio (o que poderia ser mais importante?). Foi muito complicado (erro de arquitetura) e sabíamos que demoraria muito para corrigi-lo. Os clientes concordaram em nos dar um ano para consertar (antes de lançar nosso produto) e o fizemos em cerca de um ano.

Quanto aos rastreadores de problemas, eu os uso há quase dez anos e, como regra, todos os programadores ao meu redor passaram muito pouco tempo com o rastreador (note que estou falando de programadores; os gerentes são uma história diferente). Tenho visto casos (raramente) quando não era assim - em todos esses casos, algo estava gravemente quebrado.

Em relação aos estudos sobre conversas cara a cara e acompanhamento de problemas, novamente parece que você está invadindo a porta aberta aqui. O rastreamento de problemas é uma comunicação escrita típica ; existem muitas pesquisas mostrando que, para discutir as coisas, a comunicação face2face é muito mais eficiente do que por telefone, o que, por sua vez, é muito mais eficiente do que a escrita .

• Na verdade, se você pergunta sobre o f2f, parece que você está (mis) usando o rastreador para discutir as coisas - esse não é o seu objetivo. Para descobrir o uso pretendido, basta soletrar o nome de maneira lenta e clara: sistema de rastreamento de problemas .

as listas de bugs ficam tão longas

Na minha experiência, acima é uma vantagem, não um problema.

Com uma longa lista de bugs, os desenvolvedores podem configurar uma fila e planejar correções com bastante antecedência. Isso é tão produtivo quanto possível; para mim, isso é basicamente um nirvana quando tenho uma fila para trabalhar. Primeiro bug - conserto - feito, segundo bug - conserto - feito, próximo bug - conserto - feito etc etc. Sem interrupções estúpidas, sem distrações dolorosas com conversas f2f tão eficientes, fluxo puro .

• Lembro-me de apenas um caso em que longas listas de bugs foram um problema. Isso aconteceu quando algum idiota da alta gerência decidiu por uma política que obrigava os desenvolvedores a escolher o próximo bug de uma pilha de 50 a 100 quase diariamente. Que desperdício. Levamos alguns meses de dor até descobrirmos como escalar isso sobre sua cabeça e consertá-lo.
  Algum tempo depois de conseguirmos estabelecer um fluxo de trabalho conveniente, descobrimos que nossa "lista interminável de pedidos" ficou magicamente vazia.