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

14

Em nossa empresa, os desenvolvedores querem usar uma ferramenta de rastreamento de erros adequada para gerenciar problemas em nosso aplicativo. No entanto, o gerenciamento insiste em usar uma planilha compartilhada (anteriormente, um arquivo de 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 alta do estado do projeto, pois eles 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 obtenham uma estimativa do tempo necessário para fechá-los todos (já que os desenvolvedores precisam preencher a estimativa de tempo do bug em que estão trabalhando).

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

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

    
por Sylvain Defresne 06.01.2011 / 11:43
fonte

12 respostas

22

So how can I advocate bug tracking software to ease the work of the developer ?

Dada esta afirmação:

the spreadsheet allow them to have a more highlevel view of the state of the project as they can see how many bugs are open with a quick glance.

você precisa estar olhando para sistemas que possuem ferramentas de relatórios que efetivamente permitem a criação de planilhas em "tempo real" (ou o mais próximo possível). Quando você descobrir que uma dessas explicações faz com que os desenvolvedores usem um sistema "adequado", isso significa que os dados em que eles estão interessados serão (com sorte) mais precisos e atualizados (por exemplo).

    
por 06.01.2011 / 11:48
fonte
5

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

Qualquer bugtracker decente fará o que uma planilha pode, apenas:

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

Para meus projetos pessoais eu uso Mantis (só porque é muito fácil de configurar). O trabalho usa o Trac com a integração do Mercurial.

Mantis fornece coisas como o número de bugs abertos / fechados / atribuídos fora da caixa, e imagino que a maioria dos bugtrackers o faria. Eu não sei sobre estimativa de tempo, porque não me incomodei em procurar. O Trac (ou a instalação aqui no trabalho) tem uma estimativa de tempo e é fácil escrever um relatório personalizado que, digamos, soma as estimativas por marco.

    
por 06.01.2011 / 11:49
fonte
5

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

E quanto à segurança na planilha. O gerenciamento não deveria estar preocupado com o fato de que qualquer desenvolvedor aleatório poderia 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 conta para malícia. E se um desenvolvedor específico quiser mais créditos e começar a transferir todas as correções de defeitos para si mesmo. Um sistema real teria uma trilha de auditoria onde esse tipo de coisa seria perceptível. Uma planilha não seria.

    
por 06.01.2011 / 15:36
fonte
4

Você precisa mostrar à gerência que os requisitos deles serão cumpridos.

Their argument is that the spreadsheet allow them to have a more highlevel view of the state of the project as they can see how many bugs are open with a quick glance. This also allow them to see who is working on each bug, and get estimation of the time required to close them all (as developer are required to fill time estimation of the bug they are working on).

Portanto, configure um sistema fictício e mostre a eles com demos que eles podem ter essa informação tão boa quanto e talvez até melhor do que usar uma planilha.

    
por 06.01.2011 / 11:58
fonte
4

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

  • Boas reportagens, tanto resumidas quanto detalhadas - isso pode ser pesquisado mais tarde
  • Todos precisam saber onde está a cópia mais atualizada.

Em quase todos os ambientes que defendem o uso de uma planilha do Excel, há 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 de ambos os 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 como seu sistema de controle de versão (o Eclipse possui esse recurso). Isso torna muito mais fácil trabalhar com seus bugs designados.

    
por 06.01.2011 / 14:18
fonte
4

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

Eu usei muitos sistemas de controle de código-fonte diferentes (VSS, SVN, TFS ...) e muitos sistemas de rastreamento de bugs (sistemas proprietários customizados, Tracker, SharePoint e sim, mesmo Excel), mas pelo meu dinheiro ( e é um bom pedaço de mudança), o TFS vale o investimento em dinheiro e tempo.

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

    
por 06.01.2011 / 15:22
fonte
2

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

Lendo os argumentos da gerência

Their argument is that the spreadsheet allow them to have a more highlevel view of the state of the project as they can see how many bugs are open with a quick glance. This also allow them to see who is working on each bug, and get estimation of the time required to close them all (as developer are required to fill time estimation of the bug they are working on).

Eu concordei com todos eles e cada um é atendido pelo JIRA ( Eu menciono o JIRA apenas porque é o que eu uso, tenho certeza de que existem outros candidatos que valem a pena)

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

    
por 06.01.2011 / 15:31
fonte
2

Hora da história.

Alguns meses atrás, voltei de uma semana de férias para descobrir que toda a minha empresa estava de cabeça para baixo. Um projeto que outra seção do departamento de desenvolvimento vinha ruminando havia meses era de repente uma urgência urgente, e todo o time foi retirado do que eles estavam trabalhando para agitar a coisa. Na reunião daquele dia, o dono da empresa nos pediu para derrubar algumas peças naquele dia e o resto no dia seguinte e estaríamos em boa forma.

Seis semanas depois, nós finalmente entregamos essa coisa, depois de praticamente todo o ciclo de trabalho / sono.

Nossa métrica para "concluído" foi que o cliente não recebeu mais feedback. Novas e excitantes coisas apareceriam em cada versão de seu feedback (entregue para nós por e-mail) que nunca tinha aparecido antes, e cada palavra que eles disseram era instantaneamente parte da especificação (justificada com a frase "vamos fazer ").

Tarde da noite eu estava totalmente enlouquecendo com o gerenciamento de relatórios de bugs por e-mail e impressões com marcas de seleção. Instalei o Mantis no nosso servidor de teste e carreguei o documento de feedback que acabei de receber para a minha seção. Eu configurei meu gerente como usuário e deixei que ele começasse a receber e-mails dele enquanto eu encerrava os problemas.

Dentro de 6 horas, eu tinha toda a equipe. O PM estava filtrando e-mails de clientes para o 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 papel sem papel de detalhes sobre cada item.

No dia seguinte, eles me pediram para liderar o restante do projeto. Era como se tivesse sido entregue uma granada viva, mas eu peguei e corri com ela. Duas semanas depois, finalmente esgotamos a capacidade do cliente de puxar o anel do nariz e colocar o local em produção. O Mantis é agora como gerenciamos bugs e podemos nos tornar 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. Deixe-o provar seu valor por conta própria.

BTW, esta é a mesma política que estou seguindo sobre 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, eu imediatamente faço um repositório git local para meu próprio uso no desenvolvimento.

    
por 07.01.2011 / 15:14
fonte
1

Estamos usando o Atlassian Jira .

Tem muitos relatórios disponíveis como este:

    
por 06.01.2011 / 16:16
fonte
0

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

    
por 06.01.2011 / 14:47
fonte
0

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

  • ninguém mais pode editá-lo quando alguém o abre, bloqueia a estação de trabalho e vai almoçar.
    • a solução "óbvia" é salvar uma nova versão para gravação. Isso cria uma ramificação - e o Excel é ruim na mesclagem. O trabalho de alguém será perdido.
  • o documento pode ser salvo com linhas ocultas, um problema passa despercebido por semanas.
  • tudo pode ser excluído e o acompanhamento de histórico é marginal. "o que aconteceu com a análise detalhada do problema em que entrei na semana passada?"
  • é fácil adicionar valores a campos "restritos". "Como a gravidade deste bug foi marcada como 'Epic Fail'?"
  • recortar e colar sobrescreve fórmulas. Um cálculo pode facilmente se tornar uma constante.

Eu já passei por tudo isso. E nós ainda conseguimos entregar ... Foi apenas três meses atrasado e custou milhares de horas extras não planejadas.

    
por 06.01.2011 / 22:54
fonte
0

"É GRÁTIS!" é geralmente um bom argumento. O Pivotal Tracker é grátis, não requer instalação, e pode facilmente dar aos seus gerentes uma melhor visão de alto nível do que é possível com um planilha simples.

Editar:

Para minha irritação, foi anunciado que o Pivotal Tracker não ficará disponível por muito mais tempo. : (

    
por 07.01.2011 / 02:57
fonte