Como você lida com o rastreamento de erros de uma maneira amigável para programadores e equipe não técnica? [fechadas]

Na verdade, estamos usando o Mantis para nossos projetos. Ou devo dizer "tentamos usar". O problema com todos os rastreadores de erros que conheço é que eles são feitos por programadores, para programadores. Portanto, o design é inexistente ou totalmente absurdo.

É claro que, como programador, posso usar mantis sem problemas, mas quão útil é um rastreador de erros quando todas as pessoas envolvidas ** em um projeto as consideram tão mal projetadas e difíceis de usar que preferem criar documentos do Google com listas de marcadores dos bugs que encontraram ou sugestão que possam ter.

Estou prestes a instalar um fórum, parece-me uma solução "no meio" entre um rastreador de erros e uma lista de marcadores simples. Pelo menos um fórum permite monitorar e centralizar uma discussão sobre uma sugestão.

Caso minha preocupação não seja clara, minha pergunta pode ser resumida em:

Como você lida com o relatório de bugs e sugestões para o usuário não técnico?

** Por envolvido, não quero dizer o cliente real ou o usuário final. Estou pensando em nosso integrador, gerentes de projeto e aqueles que estão envolvidos com o controle de qualidade.

Mudamos do Mantis para o FogBugz (e Kiln) no início deste ano, mas a única coisa que não mudamos foi que não permitimos que os "usuários" tivessem acesso ao rastreador de bugs. Alguns dos outros chefes de departamento têm acesso somente leitura, mas, honestamente, são gerentes e geralmente esquecem disso dentro de algumas semanas. Todos os usuários do nosso software lidam com um único responsável pela solução de problemas que determina se é um problema de configuração, erro do usuário ou bug do software. Essa pessoa atua como o gatekeeper para inserir os problemas reais no FogBugz. Isso evita que nosso sistema fique cheio de problemas que não são realmente relevantes.

Então, para responder à sua verdadeira pergunta ... não é realmente um problema para nós que o software de rastreamento de bugs seja "por programadores", "para programadores", porque somente "programadores" o utilizam. Todo mundo lida diretamente com um humano.

(Observe, nosso produto não é retrátil e todos os nossos usuários são funcionários diretos ou estão trabalhando com um funcionário do departamento de serviço.)

Usamos redmine para esse tipo de coisa. O truque principal é que a maioria dos usuários nunca vê redmine - eles apenas enviam um email para support@example.com. Usando alguns truques mais avançados - principalmente usando nossa conta redmine e incluindo o problema # -, podemos manter as atualizações em redmine. Para pessoas mais avançadas, apenas as deixamos usar o redmine diretamente, uma vez que é um pouco mais moderno e fácil de usar do que o MANTIS já foi.

Atualmente, estamos usando o MKS. Para os não programadores, configurei alguns relatórios e um painel com resumos nos quais eles estão interessados. Isso significa que tenho que fazer a configuração inicial, mas eles são capazes de monitorar o progresso dos defeitos e o resumo geral dados por conta própria, depois que eu mostro a eles como acessar os relatórios e painéis. Eles também precisavam de algum treinamento para modificar seus tickets, mas sempre haverá algum treinamento adicional. Felizmente, foi proporcional aos recursos envolvidos.

Eu uso o Redmine em segundo lugar e uso pessoalmente o The Bug Genie (sim, nome extravagante, mas bem projetado; se você estiver em um ambiente PHP e / ou não puder executar o Ruby por qualquer motivo) para rastrear problemas amigáveis ​​a usuários de tecnologia.

Além disso, uma das chaves é que os usuários finais nunca precisam ver mais problemas do que aqueles que colocam, por padrão (opcionalmente, você pode ter capacidade de pesquisa para evitar tickets duplicados, mas isso depende de suas necessidades e configurações). Ver todos os problemas apenas atrapalha a interface e confunde o usuário final. Os usuários em geral devem ver apenas o que precisam ver, para que os gerentes de projeto vejam apenas os problemas dos projetos que controlam, por exemplo. Como já mencionado, para os usuários finais, quanto mais simples você fizer o envio do ticket, melhor. Pontos de bônus se você puder enviar um ticket que nem sequer exija a interface do usuário do rastreador (por email ou por meio de um formulário simples que possua apenas os campos necessários para enviar o ticket).

Usamos "os recursos de Gerenciamento do Ciclo de Vida do Aplicativo do Visual Studio", anteriormente conhecidos como Team Systems. Uma grande vantagem para nós é que você pode exportar um resultado da consulta (como "todos os requisitos" ou "todos os bugs com um pri 2 ou inferior que não estará na próxima versão") para uma planilha ou documento do Project. Os gerentes de projeto, os representantes dos usuários finais, as partes interessadas etc. podem editar esses arquivos - alterando a prioridade, atualizando as descrições, atribuindo a outra pessoa, o que for - e, quando o arquivo retornar à máquina conectada ao TFS, você poderá clicar em Publicar e as alterações retornam ao repositório. Os programadores trabalham com itens de trabalho diretamente do Visual Studio, mas os não programadores nunca chegam perto do VS. Também há um site de compartilhamento para cada projeto TFS, para que você não

Talvez não seja uma opção se você não é uma loja VS, mas vale a pena pensar se você é.

Se você estiver falando com a equipe de QA / PM, precisará avaliar várias ferramentas de rastreamento de código aberto e fechado. Os que têm a capacidade de definir builds etc. são bons, para que o pessoal do QA / PM possa colocar tickets em um build específico e, quando você corrige um problema, eles podem saber em qual build testá-lo.

A maioria das ferramentas apropriadas que usei são mais ajustadas para não programadores do que para programadores. O StarTeam funcionou muito bem para mim, mas não sei se ainda está por aí. Você pode personalizar campos e outros, se quiser. Apenas certifique-se de que não exagere nisso.

Se você está falando sobre usuários finais, precisa consultar o software de suporte técnico e, em seguida, fazer com que sua equipe de helpdesk passe para a ferramenta de erros, conforme necessário.