Como você defenderia não usar uma planilha compartilhada para rastrear bugs / problemas?


14

Em nossa empresa, os desenvolvedores desejam usar uma ferramenta adequada de rastreamento de erros para gerenciar problemas em nosso aplicativo. A gerência, no entanto, insiste em usar uma planilha compartilhada (antes um arquivo excel compartilhado, agora uma planilha em uma solução de base da web que permite acesso simultâneo).

O argumento deles é que a planilha permite que eles tenham uma visão mais avançada do estado do projeto, pois podem ver quantos bugs estão abertos com uma rápida olhada. Isso também permite que eles vejam quem está trabalhando em cada bug e obtenha uma estimativa do tempo necessário para fechá-los (como o desenvolvedor é obrigado a preencher a estimativa do tempo em que está trabalhando).

Como você pode entender, isso não é realmente prático para os desenvolvedores (o software de rastreamento de bugs foi inventado por um motivo). Então, como posso defender o software de rastreamento de bugs para facilitar o trabalho do desenvolvedor?

Como bônus, qual software você recomendaria que permitiria à gerência obter seus feedbacks (número de bugs abertos, quem está trabalhando neles, estimativa de tempo) com uma visão de alto nível?


Infelizmente, na maioria das vezes, a gerência já se decidiu.
precisa saber é o seguinte

4
Mostre a eles eusprig.org/stories.htm . Ou até mesmo a perda de 24 milhões de TransAlta devido a um erro de copiar e colar no EXCEL. Caramba, você não deseja usar um programa que permita que alguém mude sobre qualquer coisa de uma maneira absolutamente descontrolada. A pior ferramenta para gerenciamento é o Excel, e isso é comprovado inúmeras vezes. Este é também um artigo interessante: skillsportal.co.za/page/training/articles/…
Joris Meys

Você tem pelo menos o rastreamento de versão ativado no arquivo do Excel? Caso contrário, você também pode usar um quadro branco.
Wonko the Sane

O Mantis é gratuito, você pode instalá-lo em cerca de 2 horas e fornece estatísticas e outras coisas. Como bônus, você pode alocar facilmente bugs para lançamentos e desenvolvedores, alterar estados, impor fluxos de trabalho, registrar comentários e comentários, anexar emails ou outros arquivos. A lista continua e continua. Uma planilha é primitiva, descontrolada, ineficiente e muito menos eficaz. Como nós, propensos a erros humanos e não deixando pistas de auditoria.
quickly_now

2
abra a planilha em uma estação de trabalho não utilizada para que fique bloqueada para edição, desligue a tela e finja que não sabe o que há de errado quando ninguém pode atualizar a planilha. ;-)
Steven A. Lowe

Respostas:


22

Então, como posso defender o software de rastreamento de bugs para facilitar o trabalho do desenvolvedor?

Dada esta afirmação:

a planilha permite que eles tenham uma visão de mais alto nível do estado do projeto, pois podem ver quantos bugs estão abertos com uma rápida olhada.

você precisa observar sistemas que possuem ferramentas de relatório que permitem efetivamente a criação de planilhas em "tempo real" (ou o mais próximo possível). Quando você descobre uma delas, explica que fazer com que os desenvolvedores usem um sistema "adequado" significará que os dados nos quais eles estão interessados ​​(espero) serão mais precisos e atualizados (por exemplo).


5

Qual versão da planilha está atualizada? Quem tem essa planilha?

Qualquer rastreador de erros decente fará o que uma planilha pode, apenas:

  • enviará um email às partes relevantes quando algo mudar
  • fornece uma única fonte canônica de informações atualizadas
  • permite relatórios resumidos, para fornecer visualizações de alto nível do estado do projeto

Para meus projetos pessoais, uso o Mantis (apenas porque é realmente fácil de configurar). O trabalho usa Trac com integração Mercurial.

O Mantis fornece coisas como número de bugs abertos / fechados / atribuídos prontos para uso, e imagino que a maioria dos rastreadores de bugs o faria. Não sei sobre estimativa de tempo, porque não me incomodei em olhar. O Trac (ou a instalação aqui no trabalho) tem uma estimativa de tempo e é fácil escrever um relatório personalizado que, por exemplo, somará as estimativas por marco.


5

As respostas de todos os outros são boas. Um outro aspecto me ocorre.

E quanto à segurança em torno da planilha. A gerência não deveria se preocupar com o fato de qualquer desenvolvedor aleatório poder acidentalmente pressionar os botões CTRL + A, DELETE e realmente atrapalhar as coisas? Um sistema adequado de rastreamento de bugs não permitiria esse tipo de corrupção de dados. E isso nem explica malícia. E se um desenvolvedor em particular quisesse mais crédito e começasse a reatribuir todas as correções de defeitos para si mesmo. Um sistema real teria uma trilha de auditoria em que esse tipo de coisa seria perceptível. Uma planilha não.


4

Você precisa mostrar à gerência que seus requisitos serão atendidos.

O argumento deles é que a planilha permite que eles tenham uma visão mais avançada do estado do projeto, pois podem ver quantos bugs estão abertos com uma rápida olhada. Isso também permite que eles vejam quem está trabalhando em cada bug e obtenha uma estimativa do tempo necessário para fechá-los (como o desenvolvedor é obrigado a preencher a estimativa do tempo em que está trabalhando).

Portanto, configure um sistema fictício e mostre-os com demonstrações para que eles possam obter essas informações da melhor maneira possível e até melhor do que usar uma planilha.


4

Até agora, todos têm respostas semelhantes e adequadas. Há um aspecto importante que ainda não foi mencionado. Para rastrear bugs e garantir que nada escorregue pelas fendas, você precisa de duas coisas:

  • Bons relatórios, resumo e detalhes - isso pode ser pesquisado posteriormente
  • Todo mundo precisa saber onde está a cópia mais atualizada.

Em quase todos os ambientes que defendem o uso de uma planilha do Excel, existem cópias diferentes dessa planilha na máquina de todos - e nenhuma delas é a mesma. Isso torna o processo de revisão do progresso extremamente difícil e contraproducente.

Um servidor centralizado, como Trac, RedMine, JIRA, Mantis ou o que você quiser, cuida desses dois problemas. Nesse ponto, é uma questão do que melhor se adapta às necessidades da sua empresa. Dependendo do seu ambiente, essas ferramentas podem se integrar ao seu IDE, assim como seu sistema de controle de versão (o Eclipse possui esse recurso). Isso facilita muito o trabalho com os erros atribuídos.


O arquivo é compartilhado centralmente; por que precisaria haver cópias adicionais?
Jeffo

2
Nunca precisa haver. Acontece inevitavelmente.
Berin Loritsch

Atualmente, estamos usando uma solução baseada na Web para editar uma planilha compartilhada. Portanto, a duplicação não deve acontecer.
Sylvain Defresne

4

Não conheço seu ambiente, mas para usuários do Visual Studio, sugiro o TFS. Ele integra o controle de origem e o rastreamento de problemas, com recursos completos de relatórios. Ele também oferece camadas de autoridade, rastreamento completo do histórico (ou seja, quem atualizou o bug quando, e se configurado, por quê), permite diferenciar entre um "bug" e um "problema" e um "aprimoramento" e o que mais você desejar gosta e se integra completamente ao IDE do Visual Studio. Ele une um bug com o código que foi registrado, que pode ser vinculado a compilações específicas. E muito mais.

Eu usei muitos sistemas diferentes de controle de origem (VSS, SVN, TFS ...) e muitos sistemas de rastreamento de bugs (sistemas proprietários personalizados, Tracker, SharePoint e sim, até Excel), mas pelo meu dinheiro (e é uma boa parte da mudança), o TFS vale o investimento em dinheiro e tempo.

E sim, você pode exportar para (e importar) o Excel.


2
Usamos o Team Explorer com TFS, onde você pode literalmente abrir a Lista de Erros como uma planilha, escolher "Atualizar" no menu Equipe e pronto, a lista de erros mais recente no Excel, mas com um sistema completo de rastreamento de erros no TFS.
Marcie

1
Além disso, existe uma coisa de "painel" (baseada no Sharepoint) que inclui bibliotecas de documentos que parecem conter planilhas. Quando você abre a planilha, ela é preenchida puxando uma consulta do repositório. O gerente pode atualizar o preço, o esforço alocado e o que mais quiser usando o Excel, depois clicar em Publicar e ele voltará ao repositório. Eles obtêm toda a excelência que desejam, enquanto os desenvolvedores obtêm todo o acesso associado a WI, adicionar uma captura de tela do problema, ver minhas tarefas no Visual Studio, etc que eles querem.
Kate Gregory

2

Para ajudar a vender a transição para um rastreador de problemas adequado, você deve tentar descobrir o que o gerenciamento de problemas tem com seu sistema atual (é provável que exista um 'seria bom se ...') e veja se você não pode coçar esse problema. para eles.

Lendo os argumentos da gerência

O argumento deles é que a planilha permite que eles tenham uma visão mais avançada do estado do projeto, pois podem ver quantos bugs estão abertos com uma rápida olhada. Isso também permite que eles vejam quem está trabalhando em cada bug e obtenha uma estimativa do tempo necessário para fechá-los (como o desenvolvedor é obrigado a preencher a estimativa do tempo em que está trabalhando).

Eu concordei com todos eles e todos são atendidos pelo JIRA (eu menciono o JIRA apenas porque é o que eu uso, tenho certeza que existem outros candidatos que valem a pena)

Você precisa enfatizar que, com uma ferramenta como o JIRA, eles não apenas manterão todas as vantagens da sua configuração atual, mas também terão muitas vantagens.


2

Hora da história.

Há alguns meses, voltei de uma semana de férias para encontrar toda a minha empresa de cabeça para baixo. Um projeto em que outra seção do departamento de desenvolvimento vinha trabalhando há meses era de repente uma prioridade urgente, e toda a equipe foi retirada do que estava trabalhando para produzir a coisa. Na reunião daquele dia, o proprietário da empresa nos pediu para retirar algumas peças naquele dia e o resto no dia seguinte e estaríamos em boa forma.

Seis semanas depois, finalmente entregamos a coisa, depois de praticamente ciclos contínuos de trabalho / sono.

Nossa métrica para "concluído" era que o cliente não tinha mais comentários. Coisas novas e empolgantes apareceriam em cada versão de seus comentários (enviada por e-mail) que nunca havia aparecido antes, e cada palavra que eles diziam fazia parte instantaneamente da especificação (justificada com a frase "vamos fazê-lo" ").

Tarde da noite, eu estava totalmente enlouquecedora com o gerenciamento de relatórios de erros por e-mail e impressões com marcas de seleção. Instalei o Mantis em nosso servidor de teste e carreguei o documento de feedback que acabara de receber para minha seção. Configurei meu gerente como um usuário e o deixei começar a receber e-mails dele quando resolvi problemas.

Dentro de seis horas, eu tinha toda a equipe. O PM estava filtrando e-mails de clientes no Mantis, os desenvolvedores estavam reivindicando e trabalhando em listas de problemas. Melhor ainda, eles foram capazes de solicitar esclarecimentos e comunicação dentro do sistema, resultando em uma trilha de detalhes sem papel sobre cada item.

No dia seguinte, eles me pediram para liderar o restante do projeto. Era como se tivesse recebido uma granada viva, mas eu a peguei e corri com ela. Duas semanas depois, finalmente esgotamos a capacidade do nosso cliente de puxar o nariz e colocar o site em produção. O Mantis é agora como gerenciamos os bugs e pode se tornar a forma como lidamos com solicitações de recursos desde o início de um projeto.

TL; DR: Instale você mesmo e comece a usá-lo para suas próprias coisas. Que prove seu valor por si próprio.

BTW, esta é a mesma política que estou seguindo sobre o controle de versão. Usamos o Subversion sob uma política de bloqueio obrigatório, porque meu gerente não confia na mesclagem de arquivos. Tudo bem, mas depois de verificar um projeto SVN, imediatamente faço um repositório git local para meu próprio uso no desenvolvimento.



0

Você precisa criar uma planilha que, quando o gerente a abrir, todos os dados de relatórios necessários sejam atualizados no aplicativo de sua escolha. Se você fizer isso funcionar, não há argumento.


Isso nunca vai funcionar. Seja por acidente ou malícia, mais cedo ou mais tarde alguém quebrará o sistema "infalível".
ASHelly #

0

coisas que podem dar errado com uma planilha de rastreamento de bugs em um compartilhamento de rede:

  • ninguém mais pode editá-lo quando alguém o deixa aberto, depois trava a estação de trabalho e vai almoçar.
    • a solução "óbvia" é salvar uma nova versão para escrita. Isso cria uma ramificação - e o Excel é ruim na fusão. O trabalho de alguém será perdido.
  • o documento pode ser salvo com linhas ocultas, um problema é esquecido por semanas.
  • tudo pode ser excluído e o rastreamento do histórico é marginal. "o que aconteceu com a análise detalhada dos problemas que eu entrei na semana passada?"
  • é fácil adicionar valores a campos "restritos". "Como a gravidade desse bug foi marcada como 'Epic Fail'?"
  • recortar e colar substitui as fórmulas. Um cálculo pode facilmente se tornar uma constante.

Eu vivi tudo isso. E ainda conseguimos entregar ... Estava atrasado apenas três meses e custou milhares de horas extras não planejadas.


0

"É grátis!" geralmente é um argumento muito bom. O Pivotal Tracker é gratuito, não requer instalação e pode facilmente fornecer aos seus gerentes uma melhor visão de alto nível sobre as coisas do que é possível com uma planilha modesta.

Editar:

Para minha irritação, acabei de anunciar que o Pivotal Tracker não ficará livre por muito mais tempo. :(


Eu já tentei esse argumento. Não ganhou, como me disseram que o preço não era o problema.
Sylvain Defresne

Acho que você está preso ao argumento "Superior In Every Regard". :-)
Nick Spreitzer

Na verdade, muitas pessoas associam-se gratuitamente à porcaria. Sugeri uma alternativa gratuita a algo e meu chefe respondeu "Queremos apenas o melhor" ou algo semelhante. No mercado livre, isso geralmente é verdade, mas nem sempre se aplica ao código aberto, é claro. Poucas pessoas realmente entendem o modelo de código aberto; se for comercial e gratuito, terá strings em algum lugar.
Keyo 7/01/11

É por isso que você precisa acompanhar "é grátis" com "e é incrível".
precisa saber é o seguinte

1
Só não se preocuparam em mencionar livre
Murph
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.