Razões para não construir seu próprio sistema de rastreamento de bugs [fechado]

StackOverflow https://stackoverflow.com/questions/62153

  •  09-06-2019
  •  | 
  •  

Pergunta

Várias vezes me deparei com planos de uma equipe que deseja construir seu próprio sistema de rastreamento de bugs – não como um produto, mas como uma ferramenta interna.

Os argumentos que ouvi a favor são geralmente do tipo:

  • Querer 'comer nossa própria comida de cachorro' em termos de alguma estrutura da web construída internamente
  • Precisando de algum relatório altamente especializado ou da capacidade de ajustar algum recurso de uma forma supostamente única
  • Acreditar que não é difícil construir um sistema de rastreamento de bugs

Que argumentos você poderia usar para apoiar a compra de um sistema de rastreamento de bugs existente?Em particular, quais recursos parecem fáceis, mas são difíceis de implementar, ou são difíceis e importantes, mas muitas vezes esquecidos?

Foi útil?

Solução

Primeiro, olhe para estes Ohloh Métricas:

    Trac:  44 KLoC, 10 Person Years,   $577,003
Bugzilla:  54 KLoC, 13 Person Years,   $714,437
 Redmine: 171 KLoC, 44 Person Years, $2,400,723
  Mantis: 182 KLoC, 47 Person Years, $2,562,978

O que aprendemos com esses números?Aprendemos que construir Yet Another Bug Tracker é uma ótima maneira de desperdiçar recursos!

Então, aqui estão meus motivos para construir seu próprio sistema interno de rastreamento de bugs:

  1. Você precisa neutralizar todos os bozocodificadores por uma ou duas décadas.
  2. Você precisa liberar algum dinheiro para evitar a redução do orçamento no próximo ano.

Caso contrário, não faça isso.

Outras dicas

Eu gostaria de inverter a questão.POR QUE diabos você iria querer construir o seu próprio?
Se precisar de alguns campos extras, escolha um pacote existente que possa ser modificado.
Relatório especial?Acesse o banco de dados e faça-o.

Acreditar que não é difícil?Experimente então.Especifique e veja a lista de recursos e horários aumentar.Depois que a lista estiver completa, tente encontrar um pacote existente que possa ser modificado antes de implementar o seu próprio.

Resumindo, não reinvente a roda quando outra só precisa de alguns ajustes para caber.

Os programadores gostam de construir seu próprio sistema de tickets porque, tendo visto e usado dezenas deles, sabem tudo sobre ele.Dessa forma, eles podem ficar na zona de conforto.

É como visitar um novo restaurante:pode ser gratificante, mas acarreta um risco.Melhor pedir pizza novamente.

Há também um grande fato da tomada de decisão enterrado aí:sempre há dois motivos para fazer algo:um bom e o certo.Tomamos uma decisão (“Construa a nossa própria”) e depois a justificamos (“precisamos de controle total”).A maioria das pessoas nem sequer tem consciência da sua verdadeira motivação.

Para fazê-los mudar de ideia, você tem que atacar o real razão, não a justificativa.

Síndrome de Não Inventado Aqui!

Construir seu próprio rastreador de bugs?Por que não construir seu próprio cliente de e-mail, ferramenta de gerenciamento de projetos, etc.

Como Omer van Kloeten diz em outro lugar, pague agora ou pague depois.

Existe uma terceira opção: nem comprar nem construir.Existem pilhas de bons gratuitos por aí.Por exemplo:

Rolar seu próprio rastreador de bugs para qualquer uso que não seja o aprendizado não é um bom uso do tempo.

Outros links:

Eu diria apenas que é uma questão de dinheiro - comprar um produto acabado que você sabe que é bom para você (e às vezes nem comprar se for de graça) é melhor do que desenvolver um por conta própria.É um jogo simples de pague agora vs. pague mais tarde.

Primeiro, contra os argumentos a favor da construção do seu próprio:

Querer 'comer nossa própria comida de cachorro' em termos de alguma estrutura da web construída internamente

É claro que isso levanta a questão de por que construir sua própria estrutura web.Assim como existem muitos rastreadores de bugs gratuitos que valem a pena, também existem muitas estruturas que valem a pena.Eu me pergunto se seus desenvolvedores têm prioridades claras?Quem está fazendo o trabalho que dá dinheiro real à sua empresa?

OK, se eles precisam construir uma estrutura, deixe-a evoluir organicamente a partir do processo de construção do software real que sua empresa usa para ganhar dinheiro.

Precisando de algum relatório altamente especializado ou da capacidade de ajustar algum recurso de uma forma supostamente única

Como já foi dito, pegue um dos muitos rastreadores de código aberto e ajuste-o.

Acreditar que não é difícil construir um sistema de rastreamento de bugs

Bem, eu escrevi a primeira versão do meu BugTracker.NET em apenas algumas semanas, começando sem nenhum conhecimento prévio em C#.Mas agora, 6 anos e alguns milhares de horas depois, ainda há uma grande lista de solicitações de recursos não concluídas, então tudo depende do que você deseja que um sistema de rastreamento de bugs faça.Quanta integração de e-mail, integração de controle de origem, permissões, fluxo de trabalho, controle de tempo, estimativa de cronograma, etc.Um rastreador de bugs pode ser um aplicativo importante.

Que argumentos você poderia usar para apoiar a compra de um sistema de rastreamento de bugs existente?

Não precisa comprar. Muitos bons de código aberto: Trac, Mantis_Bug_Tracker, meu próprio BugTracker.NET, para citar alguns.

Em particular, quais recursos parecem fáceis, mas são difíceis de implementar, ou são difíceis e importantes, mas muitas vezes esquecidos?

Se você estiver criando isso apenas para você, poderá usar vários atalhos, porque poderá conectar as coisas.Se você estiver construindo para muitos usuários diferentes, em vários cenários diferentes, então é o suporte à configurabilidade que é difícil.Fluxo de trabalho configurável, campos personalizados e permissões.

Acho que duas características que um bom bug tracker deve ter, que ambos FogBugz e BugTracker.NET têm, são 1) integração de e-mails recebidos e enviados, para que toda a conversa sobre um bug viva com o bug e não em um tópico de e-mail separado, e 2) um utilitário para transformar uma captura de tela em uma postagem de bug com apenas alguns cliques.

O argumento mais básico para mim seria a perda de tempo.Duvido que possa ser concluído em menos de um mês ou dois.Por que perder tempo quando existem tantos sistemas bons de rastreamento de bugs disponíveis?Dê-me um exemplo de um recurso que você precisa ajustar e que não está prontamente disponível.

Acho que um bom sistema de rastreamento de bugs deve refletir seu processo de desenvolvimento.Um processo de desenvolvimento muito personalizado é inerentemente ruim para uma empresa/equipe.A maioria das práticas ágeis favorece Scrum ou esse tipo de coisa, e a maioria dos sistemas de rastreamento de bugs estão alinhados com essas sugestões e métodos.Não seja muito burocrático com isso.

Um sistema de rastreamento de bugs pode ser um ótimo projeto para iniciar desenvolvedores juniores.É um sistema bastante simples que você pode usar para treiná-los em suas convenções de codificação e assim por diante.Fazer com que desenvolvedores juniores construam tal sistema é relativamente barato e eles podem cometer erros em algo que o cliente não verá.

Se for lixo, você pode simplesmente jogá-lo fora, mas pode dar a eles a sensação de que o trabalho já é importante para a empresa se for usado.Você não pode colocar um custo para que um desenvolvedor júnior seja capaz de experimentar todo o ciclo de vida e todas as oportunidades de transferência de conhecimento que tal projeto trará.

Nós fizemos isso aqui.Escrevemos nosso primeiro há mais de 10 anos.Em seguida, atualizamos para usar serviços da web, mais como uma forma de aprender a tecnologia.A principal razão pela qual fizemos isso originalmente foi que queríamos um sistema de rastreamento de bugs que também produzisse relatórios de histórico de versões e alguns outros recursos que não conseguimos encontrar em produtos comerciais.

Agora estamos analisando os sistemas de rastreamento de bugs novamente e considerando seriamente migrar para o Mantis e usar o Mantis Connect para adicionar nossos próprios recursos personalizados.A quantidade de esforço para implementar nosso próprio sistema é grande demais.

Acho que também deveríamos dar uma olhada no FogBugz :-)

Mais importante ainda, onde você enviará os bugs para o seu rastreador de bugs antes de terminar?

Mas seriamente.As ferramentas já existem, não há necessidade de reinventar a roda.Modificar ferramentas de rastreamento para adicionar determinados recursos específicos é uma coisa (modifiquei Trac antes)...reescrever um é simplesmente bobo.

A coisa mais importante que você pode ressaltar é que se tudo o que eles desejam fazer é adicionar alguns relatórios especializados, não será necessária uma solução básica.Além disso, o ÚLTIMO lugar em que "sua solução homebrew" é importante são as ferramentas internas.Quem se importa com o que você está usando internamente se está fazendo o trabalho conforme necessário?

Sendo um programador trabalhando em uma tarefa já crítica (ou pelo menos importante), não deve se deixar desviar tentando desenvolver algo que já esteja disponível no mercado (open source ou comercial).

Agora você tentará criar um sistema de rastreamento de bugs para acompanhar o sistema de rastreamento de bugs usado para rastrear bugs em seu desenvolvimento principal.

Primeiro:1.Escolha a plataforma que seu sistema de bugs seria executado (Java, PHP, Windows, Linux etc.) 2.Tente encontrar ferramentas de código aberto que estão disponíveis (por código aberto, quero dizer ferramentas comerciais e gratuitas) na plataforma que você escolheu 3.Gaste o mínimo de tempo para tentar personalizar de acordo com sua necessidade.Se possível, não perca tempo personalizando

Para uma equipe de desenvolvimento empresarial, começamos a usar JIRA.Queríamos alguns relatórios extras, login SSO, etc.O JIRA era capaz disso e poderíamos estendê-lo usando o plugin já disponível.Como o código recebeu parte do suporte pago, gastamos apenas um tempo mínimo escrevendo o plugin personalizado para login.

Com base no que outras pessoas disseram, em vez de apenas baixar um software gratuito/de código aberto.Que tal baixá-lo e modificá-lo inteiramente de acordo com suas necessidades?Eu sei que fui obrigado a fazer isso no passado.Instalei o Bugzilla e modifiquei-o para suportar testes de regressão e relatórios de testes (isso foi há muitos anos).

Não reinvente a roda a menos que esteja convencido de que pode construir uma roda mais redonda.

Eu diria que um dos maiores obstáculos seria a angústia em relação ao modelo/fluxo de trabalho de dados.Eu prevejo que isso levará um longo tempo e envolvem muitas discussões sobre o que deveria acontecer com um bug sob certas circunstâncias, o que realmente constitui um bug, etc.Em vez de passar meses discutindo de um lado para outro, se você apenas implementasse um sistema pré-construído, a maioria das pessoas aprenderia como usá-lo e tirar o melhor proveito dele, independentemente das decisões já tomadas.Escolha algo de código aberto e você poderá ajustá-lo mais tarde, se necessário - isso será muito mais rápido do que criar o seu próprio do zero.

Neste ponto, sem uma grande nova direção no rastreamento/ticketing de bugs, seria simplesmente uma reinvenção da roda.O que parece ser o que todo mundo pensa, em geral.

Suas discussões começarão com o que constitui um bug e evoluirão para qual fluxo de trabalho aplicar e terminarão com uma grande discussão sobre como gerenciar projetos de engenharia de software.Você realmente quer aquilo?:-) Nah, pensei que não - vá e compre um!

A maioria dos desenvolvedores pensa que possui poderes únicos que ninguém mais possui e, portanto, podem criar um sistema que seja único de alguma forma.

99% deles estão errados.

Quais são as chances de sua empresa ter funcionários na faixa de 1%?

Estive em ambos os lados deste debate, por isso deixe-me ser um pouco ambíguo aqui.

Quando eu era mais jovem, tentei construir nosso próprio sistema de rastreamento de bugs.Acabei de destacar todas as coisas que o material pronto para uso não poderia fazer e pedi à gerência para fazer isso.Quem eles escolheram para liderar a equipe?Meu!Seria minha primeira chance de ser líder de equipe e ter voz em tudo, desde design até ferramentas e pessoal.Fiquei emocionado.Portanto, minha recomendação seria verificar as motivações das pessoas que impulsionam este projeto.

Agora que estou mais velho e me deparo com a mesma dúvida novamente, decidi usar o FogBugz.Faz 99% do que precisamos e os custos são basicamente 0.Além disso, Joel enviará e-mails pessoais fazendo você se sentir especial.E no final das contas, não é esse o problema, seus desenvolvedores acham que isso os tornará especiais?

Todo desenvolvedor de software deseja construir seu próprio sistema de rastreamento de bugs.É porque podemos obviamente melhorar o que já existe, pois somos especialistas no domínio.

É quase certo que não vale o custo (em termos de horas de desenvolvedor).Basta comprar JIRA.

Se precisar de relatórios extras para o seu sistema de rastreamento de bugs, você pode adicioná-los, mesmo que precise fazer isso acessando diretamente o banco de dados subjacente.

A questão é: para que sua empresa está pagando para você fazer?É para escrever software que só você usará?Obviamente não.Portanto, a única maneira de justificar o tempo e as despesas para construir um sistema de rastreamento de bugs é se ele custar menos do que os custos associados ao uso de um sistema de rastreamento de bugs gratuito.

Pode haver casos em que isso faça sentido.Você precisa integrar com um sistema existente?(Controle de tempo, estimativa, requisitos, controle de qualidade, testes automatizados)?Você tem alguns requisitos exclusivos em sua organização relacionados, por exemplo, à conformidade com SOX que exigem elementos de dados específicos que seriam difíceis de capturar?

Você está em um ambiente extremamente burocrático que leva a um "tempo de inatividade" significativo entre os projetos?

Se a resposta for sim para esses tipos de perguntas - então, sem dúvida, o argumento "comprar" versus construir diria construir.

Se "precisar de algum relatório altamente especializado ou da capacidade de ajustar algum recurso de alguma forma supostamente única", a melhor e mais barata maneira de fazer isso é conversar com os desenvolvedores dos sistemas de rastreamento de bugs existentes.Pague-os para colocar esse recurso em seus aplicativos e disponibilizá-lo para o mundo.Em vez de reinventar a roda, basta pagar aos fabricantes de rodas para colocarem raios em forma de molas.

Caso contrário, se estiver tentando mostrar uma estrutura, está tudo bem.Apenas certifique-se de inserir as isenções de responsabilidade relevantes.

Para as pessoas que acreditam que o sistema de rastreamento de bugs não é difícil de construir, siga rigorosamente o SDLC em cascata.Obtenha todos os requisitos antecipadamente.Isso certamente os ajudará a compreender a complexidade.Normalmente são as mesmas pessoas que dizem que um mecanismo de pesquisa não é tão difícil de construir.Apenas uma caixa de texto, um botão "pesquisar" e um botão "estou com sorte", e o botão "estou com sorte" podem ser feitos na fase 2.

Use algum software de código aberto como está.Com certeza existem bugs, e você precisará do que ainda não existe ou que está pendente de correção de bug.Isso acontece o tempo todo.:)

Se você estender/personalizar uma versão de código aberto, deverá mantê-la.Agora, o aplicativo que supostamente irá ajudá-lo nos testes aplicativos para ganhar dinheiro se tornará um fardo para suportar.

Acho que a razão pela qual as pessoas escrevem seus próprios sistemas de rastreamento de bugs (na minha experiência) é:

  1. Eles não querem pagar por um sistema que consideram relativamente fácil de construir.
  2. Ego do programador
  3. Insatisfação geral com a experiência e solução oferecida pelos sistemas existentes.
  4. Eles vendem isso como um produto :)

Para mim, a maior razão pela qual a maioria dos rastreadores de bugs falharam foi que eles não proporcionaram uma experiência de usuário ideal e pode ser muito doloroso trabalhar com um sistema que você usa MUITO, quando ele não está otimizado para usabilidade.

Acho que a outra razão é a mesma por que quase todos nós (programadores) construímos seu próprio CMS ou estrutura CMS personalizada em algum momento (culpado conforme acusado).Só porque você pode!

Concordo com todas as razões para NÃO fazê-lo.Tentamos por algum tempo usar o que havia por aí e acabamos escrevendo o nosso mesmo assim.Por que?Principalmente porque a maioria deles é muito complicada para envolver qualquer pessoa que não seja o pessoal técnico.Até tentamos o basecamp (que, claro, não foi projetado para isso e falhou nesse aspecto).

Também criamos algumas funcionalidades exclusivas que funcionaram muito bem com nossos clientes:um botão "relatar um bug" que transformamos em código com uma linha de javascript.Ele permite que nossos clientes abram uma pequena janela, anote informações rapidamente e envie para o banco de dados.

Mas certamente demorou muitas horas para codificar;tornou-se um GRANDE projeto favorito;muito tempo de fim de semana.

Se você quiser conferir: http://www.archerfishonline.com

Adoraria algum feedback.

Nós fizemos isso...algumas vezes.A única razão pela qual construímos o nosso é porque foi há cinco anos e não havia muitas alternativas boas.mas agora existem inúmeras alternativas.A principal coisa que aprendemos ao construir nossa própria ferramenta é que você gastará muito tempo trabalhando nela.E é nessa hora que você pode cobrar pelo seu tempo.Faz muito mais sentido, como uma pequena empresa, pagar a taxa mensal que você pode facilmente recuperar com uma ou duas horas faturáveis, do que gastar todo esse tempo fazendo a sua própria.Claro, você terá que fazer algumas concessões, mas ficará muito melhor no longo prazo.

Quanto a nós, decidimos disponibilizar nosso aplicativo para outros desenvolvedores.Confira em http://www.myintervals.com

Porque Trac existe.

E porque você terá que treinar novos funcionários em seu software personalizado, quando eles provavelmente terão experiência em outros sistemas nos quais você pode desenvolver em vez de jogá-los fora.

Porque não é um tempo faturável ou mesmo muito útil, a menos que você vá vendê-lo.

Existem sistemas de rastreamento de bugs perfeitamente bons disponíveis, por exemplo, FogBugz.

Trabalhei em uma startup por vários anos onde começamos com GNATOS, uma ferramenta de código aberto, e essencialmente construímos nosso próprio sistema elaborado de rastreamento de bugs sobre ela.O argumento era que evitaríamos gastar muito dinheiro em um sistema comercial e obteríamos um sistema de rastreamento de bugs exatamente adequado às nossas necessidades.

Claro, acabou sendo muito mais difícil do que o esperado e foi uma grande distração para os desenvolvedores – que também tiveram que manter o sistema de rastreamento de bugs além do nosso código.Este foi um dos fatores que contribuíram para o desaparecimento da nossa empresa.

Não escreva seu próprio software apenas para "comer sua própria comida de cachorro".Você está apenas criando mais trabalho, quando provavelmente poderia comprar um software que faz a mesma coisa (e melhor) por menos tempo e dinheiro gasto.

Diga a eles, isso é ótimo, a empresa poderia economizar algum dinheiro por um tempo e ficará feliz em contribuir com as ferramentas de desenvolvimento enquanto você trabalha neste período sabático não remunerado.Qualquer pessoa que deseje tirar férias anuais para trabalhar no projeto é livre para fazê-lo.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top