it-swarm-pt.tech

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

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

Os argumentos que ouvi em favor geralmente seguem as linhas de:

  • 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 a capacidade de ajustar algum recurso de alguma forma supostamente única
  • Acreditando que não é difícil construir um sistema de rastreamento de bugs

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

54
Matt Sheppard

Primeiro, olhe para estas 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 minhas razões para construir seu próprio sistema interno de rastreamento de bugs:

  1. Você precisa neutralizar todos os bozocoders 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.

80
Constantin

Eu gostaria de inverter a questão. POR QUE diabos você gostaria de construir o seu próprio?
Se você precisar de alguns campos extras, vá com um pacote existente que pode ser modificado.
Relatório especial? Acesse o banco de dados e crie-o.

Acreditar que não é difícil? Tente então. Especifique e veja a lista de recursos e horas aumentar. Depois que a lista estiver completa, tente encontrar um pacote existente que possa ser modificado antes de implementar o seu.

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

39
Lars Mæhlum

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

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

Há também um grande fato da tomada de decisão enterrado aí: sempre há duas razões para fazer algo: uma boa e a certa. Tomamos uma decisão ("Construir o nosso próprio") e então a justificamos ("Precisamos de controle total"). A maioria das pessoas nem mesmo tem consciência de sua verdadeira motivação.

Para mudar suas mentes, você deve atacar a razão real, não a justificativa.

19
MattW.

Síndrome de não inventado aqui!

Construir seu próprio bug tracker? 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 depois.

14
Stu Thompson

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

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

Outros links:

12
Anthony

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

10
Omer van Kloeten

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

Isso, é claro, levanta a questão de por que construir sua própria estrutura da web. Assim como existem muitos rastreadores de bugs gratuitos e valiosos, também existem muitos frameworks valiosos. Eu me pergunto se seus desenvolvedores têm suas prioridades bem definidas. Quem está fazendo o trabalho que torna sua empresa dinheiro real?

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 a capacidade de ajustar algum recurso de alguma forma supostamente única

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

Acreditando 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 de C #. Mas agora, 6 anos e alguns milhares de horas depois, ainda há uma grande lista de solicitações de recursos desfeitas, então tudo depende do que você deseja que um sistema de rastreamento de bugs faça. Quanta integração de email, integração de controle de fonte, permissões, fluxo de trabalho, rastreamento de tempo, estimativa de programação, etc. Um rastreador de bug pode ser um aplicativo importante.

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

Não preciso 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 acabam sendo difíceis de implementar, ou são difíceis e importantes, mas muitas vezes esquecidos?

Se você o está criando apenas para você mesmo, pode usar vários atalhos, porque pode fazer a ligação direta das coisas. Se você estiver construindo para muitos usuários diferentes, em muitos cenários diferentes, então é o suporte para configurabilidade que é difícil. Fluxo de trabalho configurável, campos personalizados e permissões.

Acho que dois recursos que um bom rastreador de bugs deve ter, que ambos FogBugz e BugTracker.NET têm, são 1) integração de e-mails recebidos e enviados, de modo que toda a conversa sobre um bug permaneça 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.

8
Corey Trager

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 bons sistemas de rastreamento de bugs disponíveis? Dê-me um exemplo de um recurso que você precisa ajustar e que não está 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 favorecem Scrum ou esse tipo de coisa, e a maioria dos sistemas de rastreamento de bugs estão alinhados com tais sugestões e métodos. Não fique muito burocrático sobre isso.

6
Slavo

Um sistema de rastreamento de bugs pode ser um ótimo projeto para iniciar os 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 os desenvolvedores juniores construam tal sistema é relativamente barato e eles podem cometer seus 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 em um desenvolvedor júnior ser capaz de experimentar o ciclo de vida completo e todas as oportunidades de transferência de conhecimento que tal projeto trará.

5
Garry Shutler

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 pudemos encontrar em produtos comerciais.

Agora estamos olhando para os sistemas de rastreamento de bugs novamente e estamos considerando seriamente a migração para o Mantis e o uso do Mantis Connect para adicionar recursos personalizados adicionais. A quantidade de esforço para desenvolver nosso próprio sistema é muito grande.

Acho que também devemos olhar para o FogBugz :-)

5
dcraggs

Mais importante, para onde você enviará os bugs para o rastreador de bugs antes que ele seja concluído?

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

A coisa mais importante que você pode salientar é que, se tudo o que eles querem fazer é adicionar alguns relatórios especializados, isso não requer uma solução completa. E, além disso, o ÚLTIMO lugar que "sua solução homebrew" importa são as ferramentas internas. Quem se importa com o que você está usando internamente se estiver fazendo o trabalho conforme necessário?

5
Loren Segal

Sendo um programador a trabalhar numa tarefa que já é crítica (ou pelo menos importante), não se deve deixar desviar tentando desenvolver algo que já está disponível no mercado (open source ou comercial).

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

Primeiro: 1. Escolha a plataforma em que seu sistema de bug 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 você escolheu 3. Gaste um tempo mínimo 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 podíamos estendê-lo usando o plugin já disponível. Uma vez que o código recebeu parte do suporte pago, gastamos apenas um tempo mínimo escrevendo o plugin personalizado para login.

4
Ram Prasad

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

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

3
Mark Ingram

Estive em ambos os lados deste debate, então deixe-me ser um pouco dois enfrentados aqui.

Quando eu era mais jovem, empurrei para construir nosso próprio sistema de rastreamento de bugs. Eu apenas destaquei todas as coisas que as coisas de prateleira não podiam fazer e pedi à gerência para fazer isso. Quem eles escolheram para liderar a equipe? Eu! Seria minha primeira chance de liderar uma equipe e ter voz ativa em tudo, desde o design às ferramentas e ao pessoal. Fiquei emocionado. Portanto, minha recomendação seria verificar as motivações das pessoas que estão promovendo este projeto.

Agora que estou mais velho e enfrentando a mesma pergunta novamente, decidi usar o FogBugz. Ele faz 99% do que precisamos e os custos são basicamente 0. Além disso, Joel enviará e-mails pessoais para você se sentir especial. E no final, não é esse o problema, seus desenvolvedores acham que isso os tornará especiais?

2
Jonathan Beerhalter

A maioria dos desenvolvedores pensa que possui alguns 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 casa de 1%?

2
LepardUK

Eu diria que um dos maiores obstáculos seria agonizar sobre o modelo de dados/fluxo de trabalho. Prevejo que isso levará longo tempo e envolverá muitos argumentos sobre o que deve acontecer com um bug em certas circunstâncias, o que realmente constitui um bug, etc. Em vez de passar meses discutindo de um lado para outro, se Se você simplesmente implantar um sistema pré-construído, a maioria das pessoas aprenderá como usá-lo e tirar o melhor proveito dele, não importa quais decisões já foram fixadas. Escolha algo de código aberto, e você sempre pode Ajustá-lo mais tarde, se necessário - isso será muito mais rápido do que criar o seu do zero.

2
Bobby Jack

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

2
Tony Pitale

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!

2
Rikalous

Se "Precisando de algum relatório altamente especializado, ou a 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 seu aplicativo, torná-lo disponível para o mundo. Em vez de reinventar a roda, basta pagar aos fabricantes de rodas para colocar raios em forma de molas.

Caso contrário, se estiver tentando mostrar uma estrutura, tudo bem. Apenas certifique-se de incluir 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 estritamente o SDLC em cascata. Obtenha todos os requisitos logo de início. Isso certamente os ajudará a compreender a complexidade. Normalmente são as mesmas pessoas que afirmam 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 usados ​​na fase 2.

1
Kinjal Dixit

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

É quase certo que não vale a pena 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 tenha que fazer isso acessando o banco de dados subjacente diretamente.

1
Dan Dyer

A questão é: o que sua empresa está lhe pagando para 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 se integrar a um sistema existente? (Controle de tempo, estimativa, requisitos, controle de qualidade, teste automatizado)? Você tem alguns requisitos exclusivos em sua organização relacionados a, digamos, conformidade SOX que requer elementos de dados específicos que seriam difíceis de capturar?

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

Se a resposta for sim para esses tipos de perguntas - então, por suposto, o argumento "comprar" versus construir diria construir.

1
fuzzbone

Porque Trac existe.

E porque você terá que treinar novos funcionários em seu software sob medida, quando eles provavelmente terão experiência em outros sistemas que você pode construir em vez de jogar fora.

1
Marc Gear

Eu concordo com todas as razões para NÃO. Tentamos por algum tempo usar o que estava por aí e acabamos escrevendo o nosso próprio de qualquer maneira. Por quê? Principalmente porque a maioria deles é muito complicada para envolver ninguém além do pessoal técnico. Nós 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 criamos no código com uma linha de javascript. Permite aos nossos clientes abrir uma pequena janela, anotar informações rapidamente e enviar para a base de dados.

Mas certamente demorou muitas horas para codificar; tornou-se um grande projeto de estimação; muito tempo de fim de semana.

Se você quiser dar uma olhada: http://www.archerfishonline.com

Adoraria algum feedback.

1
Rich Goidel

Porque não é hora 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 .

1
pro

Trabalhei em uma startup por vários anos, onde começamos com GNATS , uma ferramenta de código aberto, e essencialmente construímos nosso próprio sistema elaborado de rastreamento de bugs em cima dela. 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 de nosso código. Este foi um dos fatores que contribuíram para o fim de nossa empresa.

1
Rangachari Anand

se algum software de código aberto no estado em que se encontra. Com certeza há bugs e você vai precisar do que ainda não existe ou está pendente de uma 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 o ajudará com os testes aplicativos que geram dinheiro se tornará um fardo para suportar.

1
maestroQC

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 toneladas de alternativas. A principal coisa que aprendemos ao construir nossa própria ferramenta é que você gastará muito tempo trabalhando nela. E esse é o momento em que você pode cobrar pelo seu tempo. Faz muito mais sentido, como uma pequena empresa, pagar a mensalidade que você pode recuperar facilmente com uma ou duas horas faturáveis, do que gastar todo esse tempo cobrando 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

1
jjriv

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

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

Para mim, o maior motivo do fracasso da maioria dos rastreadores de bugs é que eles não proporcionam uma experiência de usuário ideal e pode ser muito doloroso trabalhar com um sistema que você usa MUITO, quando não está otimizado para usabilidade.

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

1
Sarat

Não acho que construir um sistema de rastreamento interno seja relativamente fácil de construir e certamente não será compatível com uma solução paga ou de código aberto. Na maioria das vezes, eu iria para o "ego do programador" ou apenas ter um departamento de TI que realmente não pode usar software de terceiros e tem que construir literalmente cada pedaço de software usado.

Uma vez eu trabalhei em uma empresa de telecomunicações que tinha seu sistema de controle de versão interno, e era muito ruim, mas mantinha uma equipe inteira ocupada ...

0
t3mujin

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 faça a mesma coisa (e melhor) por menos tempo e dinheiro gasto.

0
Chris Pietschmann

Eu construí meus próprios sistemas de rastreamento de bugs. Eu também pensei: "quão difícil pode ser, é apenas um sistema de rastreamento de bugs" ERR - ERRADO * - levou seis meses para codificá-lo.

O principal motivo pelo qual assei foi para fazê-lo exatamente como eu queria. O outro motivo foi como um projeto de hobby.

Eu diria que essa é a única vez que se justifica construir o seu próprio é como um projeto de hobby. Nenhuma empresa deveria gastar seu tempo fazendo isso.

Meu software é chamado Bugweb a propósito.

0
louism

Suponha que, amanhã (ano que vem), se eles decidissem trazer uma ferramenta open source/comercial popular para TODOS os sistemas de rastreamento de bugs da empresa, como essa ferramenta será capaz de exportar todos os seus tíquetes de bug para a outra ferramenta?

Contanto que haja uma necessidade real de um sistema de rastreamento de bugs personalizado, e tais questões sejam respondidas, eu NÃO me preocuparia muito.

0
anjanb

Já existem tantos outros fantásticos por aí, por que perder tempo reinventando a roda?

Basta usar FogBugz .

0
Miles

Eu concordo com a maioria das pessoas aqui. Não adianta reconstruir algo quando existem muitas ferramentas (mesmo gratuitas) disponíveis. Se você quiser personalizar qualquer coisa, a maioria das ferramentas gratuitas fornece o código, brinque com ele.

Se você faz um novo desenvolvimento, não deve fazê-lo apenas para você.

0
quadri

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 ano sabático não remunerado. Qualquer pessoa que desejar tirar suas férias anuais em vez de trabalhar o projeto é livre para fazê-lo.

0
Andy Dent