Os casos devem ser reabertos para erros ou devem ser abertos como um novo caso?

Atualmente, no meu local de trabalho, usamos o FogBugz para gerenciar todos os nossos recursos e bugs para nossos diferentes aplicativos da web.

Quando um novo recurso deve ser adicionado a um de nossos aplicativos da web, um novo Caso é criado. Por exemplo, "Criar formulário de upload CSV".

Depois, trabalho no caso, registrando a quantidade de tempo que gastei nele. Depois que esse caso é concluído, eu o resolvo e ele é atribuído de volta ao abridor de casos (geralmente o gerente de projeto), que então fecha o caso.

Se houver algum erro com o recurso, meu gerente de projeto reabrirá o caso e o atribuirá de volta a mim com uma lista de erros.

Na minha opinião, acredito que esses erros apontados por marcadores devem ser abertos como casos de erros individuais, para que possam ser rastreados com mais facilidade e não ficarem desordenados com as notas do caso do recurso original.

Meus gerentes discordam de mim, afirmando que é mais fácil calcular o tempo total gasto no recurso, se tudo estiver em um caso.

Além disso, eles acreditam que é menos confuso para nossos clientes, pois eles têm apenas 1 referência de número de caso para o recurso. No entanto, gostaria de enfatizar que os bugs devem ser tratados como casos separados, pois isso é pós-conclusão do caso original.

Estou certo ao afirmar que os bugs devem ser reabertos como um novo caso? E quais são os prós / contras de cada maneira de gerenciar isso?

Você e seu gerente têm boas razões para lidar da maneira que cada um de vocês prefere, e não há uma necessidade real de se comprometer. Existe uma solução que funciona para mim e aborda as duas preocupações.

Para casos como o seu, eu uso a abordagem de tarefa de alto nível / subtarefas de baixo nível (conceito que escolhi no JIRA , não posso dizer se o FogBugz suporta explicitamente o que ^parece ). Dessa forma, as listas com marcadores "voltadas para o cliente" passam para tarefas de alto nível, enquanto as "iterações do desenvolvedor" que são importantes para mim são refletidas nas subtarefas.

Quando a tarefa de alto nível é "reaberta", crio uma nova subtarefa para rastrear o esforço adicional por conta própria .

Dessa forma, o desenvolvedor reflete claramente todas as permutações, perversões e reviravoltas passadas pela especificação do recurso, permitindo que o gerente a apresente aos clientes como se fosse perfeito. A propósito, a apresentação como se perfeita tem seu valor para mim como desenvolvedor - porque a leitura mais fácil para os clientes ajuda a obter ajustes mais precisos.

Isso também permite, naturalmente, uma justificativa clara nos casos em que a implementação do recurso leva muito mais tempo do que o previsto originalmente.

_{Quanto ao rastreamento de tempo por tarefa ou subtarefa - como o JIRA permite incluir o rastreamento de subtarefas no resumo de nível superior, é aceitável para o gerente rastrear o tempo nas subtarefas. No entanto, mesmo que não fosse esse o caso, eu poderia viver formalmente com o tempo de rastreamento na tarefa "pai" - nesse caso, usaria apenas comentários de subtarefas para indicar quanto tempo foi gasto em uma iteração específica.}

Se tudo isso estiver acontecendo antes do recurso ser lançado para o cliente, basta ter um caso. O argumento aqui é que o caso não está realmente completo até que seja aprovado no controle de qualidade e pronto para ser lançado. Os outros benefícios - um número de caso único para o faturamento e os usuários finais fazerem referência são válidos e importantes.

Depois que o recurso é lançado e os erros são encontrados, eles devem ser levantados como novos problemas no seu software de rastreamento de problemas.

Eu concordo totalmente com você, assim como o FogBugz - é por isso que define categorias diferentes para Bugs e Recursos. O FogBugz não foi projetado para ser uma ferramenta para rastrear o uso do tempo; este é um subproduto acidental da introdução do agendamento baseado em evidências.

Os erros de um recurso concluído podem ser vinculados ao caso principal do recurso (no FogBugz, usando um nome de tag ou uma referência cruzada ou tornando-os sub-casos). Percebo que é um pouco mais trabalhoso para o seu gerente consolidar informações em vários casos, mas também costuma fazer sentido separar o tempo gasto no desenvolvimento original e o tempo gasto na manutenção, especialmente em contratos de preço fixo, e você perde a capacidade de fazer isso se colocar tudo em um caso.

É minha opinião que, assim que um ticket for fechado, ele permanecerá fechado, seu rastreador de erros deverá ser capaz de vincular a outros casos de qualquer maneira. Gostaria de salientar que criar novos bugs e vinculá-los ao caso original oferece melhores benefícios do que o método que você descreve.

• os clientes ainda podem ter um número de referência que contém links para cada bug.
• o status de cada bug pode ser rastreado individualmente, permitindo uma melhor priorização e relatórios de status.
• ter bugs separados permitirá que o gerente reduza o tempo gasto em bugs versus o tempo gasto no desenvolvimento de novos recursos e deve ser apenas um esforço adicional mínimo para obter um número total de todos os bugs relacionados a uma alteração e ao desenvolvimento dessa alteração.
• separar bugs torna muito mais fácil para seu gerente reunir outras métricas como bugs totais, tempo médio por correção de bugs, proporções de bugs fechados / em andamento / corrigidos.
• casos separados por bug permitem que as tarefas sejam melhor divididas entre todos os desenvolvedores e responsabilizam cada um por seu próprio trabalho, ou permite essa possibilidade caso mais desenvolvedores sejam contratados posteriormente.

A única vantagem da sua configuração atual é que é extremamente simples para as pessoas que não são os principais usuários do sistema. O objetivo de um rastreador de erros é que o desenvolvedor tenha um lugar para relatar tudo sobre um bug em um único local que também seja amigável o suficiente para que outras pessoas vejam o progresso; seu sistema atual parece prejudicar quase todas as partes dele.

Os erros foram encontrados antes ou depois do produto ter sido 'enviado / liberado' para os clientes?

Se for antes do lançamento, os bugs devem ser rastreados no ticket original.

Se for após um lançamento, cada bug deve ter seu próprio ticket.

Onde trabalho, apenas o pessoal do controle de qualidade pode encerrar um caso. Temos caixas de seleção para revisão de código, teste de engenharia e demonstração para as partes interessadas (no seu caso, gerente de projeto). Se a equipe de controle de qualidade vir um caso marcado como "Concluído" que não possui todos esses campos marcados, eles o marcarão como desfeitos e o enviarão de volta para nós.

Depois que um caso passa por todas essas fases e o controle de qualidade fecha o caso, quaisquer novos problemas encontrados são registrados como bugs.

Este sistema parece funcionar bem para nós.

Eu acho que você pode argumentar nos dois sentidos. Eu tentaria me sentar com o PM e explicar por que você acha que ter problemas discretos o ajudará. Pessoalmente, quero que cada item de tarefa seja seu próprio ticket, mas posso ver por que ele quer dessa maneira.