Usando software de rastreamento de bugs / rastreamento de problemas para discutir questões de design, novas ferramentas, etc.

Alguém tem experiência com o uso de um software de rastreamento de erros / rastreamento de problemas como o bugzilla, mantis ou JIRA, não apenas para bugs ou tarefas, mas para iniciar e manter discussões que, no final, levam a uma decisão?

Por exemplo, um desenvolvedor pensa que todos os campos protegidos devem ser abolidos e alterados para campos particulares com métodos protegidos que os acessam. A decisão não é dele e ele gostaria de discutir. Normalmente, ele aborda o assunto na próxima reunião de desenvolvedores, no final da qual uma decisão é tomada. Em vez disso, minha ideia era que ele abrisse uma questão de um certo tipo de "decisão" e descrevesse sua intenção como normalmente descreveria um bug ou tarefa.

Outros desenvolvedores podem fazer seus comentários se quiserem e, no final, o problema é encerrado como "aceito" ou "negado".

As vantagens que vejo nisso:

• Comunicação assíncrona: ninguém é obrigado a expressar sua opinião em uma reunião quando ainda não teve tempo de supervisionar todas as implicações dessa decisão.
• Registro escrito de considerações que levam a uma decisão. Se alguém mais tarde levantar essa questão novamente, ele poderá ser encaminhado a ela.
• Relações com outras questões podem ser feitas, por exemplo, uma tarefa pode ser seguida de volta a uma decisão.
• A integração com o software de controle de versão, por exemplo, uma confirmação pode ser rastreada até uma decisão.

Desvantagens:

• Cheiro forte de um martelo de ouro: o software de rastreamento de problemas normalmente é usado para rastrear itens acionáveis
• A sobrecarga organizacional pode ser desproporcional: em vez de uma pequena conversa informal, é preciso comunicar suas idéias por escrito

A maneira como trabalhamos, o rastreamento de problemas deve acompanhar todos os problemas. Não sabemos quais problemas são passíveis de ação até que sejam analisados. Se o sistema de rastreamento tiver apenas problemas acionáveis, é provável que eles estejam sendo triados muito cedo, o que significa que quaisquer discussões e decisões serão perdidas. Adotamos a abordagem em que tudo deve ser seguido (no nosso fluxo de trabalho), pois caso contrário, os problemas poderão ser repetidamente levantados sem visibilidade.

Como temos uma categoria em nossa implementação do Jira para "Risco", estamos usando o Jira para rastrear itens que não são acionáveis, mas que podem comprometer o software de alguma forma. A discussão sobre o item é rastreada e, quando o risco desaparece (ou atenua), o problema é encerrado. O exemplo que você deu pode facilmente entrar na categoria Risco.

É importante que coisas como essa sejam discutidas e rastreadas, e a decisão registrada. Quando o desenvolvedor reavalia o problema em alguns meses, a resposta "Perguntado e respondido" tem uma justificativa.

Corrija-me se eu estiver errado; mas acho que o que você está falando é: "Posso / como usar os sistemas de rastreamento de bugs / rastreamento de problemas para também fazer o 'Decision Tracking'. É ou estou faltando alguma coisa?

No começo, eu diria que essa é realmente uma ótima idéia. Embora não o usemos exatamente da maneira mencionada, faz sentido usá-lo para fins de rastreamento. No nosso caso, uma longa lista de emails - mais como uma lista de fórum / correspondência é seguida.

No entanto, sua pergunta em um sentido mais amplo é sobre como tomar (e gerenciar) decisões efetivamente e conectar as implicações do trabalho de volta às decisões tomadas que trazem melhores insights.

Como eu disse, pode ser uma ótima idéia se isso ajudar as pessoas. Nada de errado nisso. Mas, para tomar / administrar efetivamente decisões, precisa de poucas coisas concretas.

1. É verdade que a maioria das decisões deve ser um esforço inclusivo de base ampla, para que todos os aspectos importantes sejam cobertos e pesados ​​adequadamente antes que as decisões sejam baseadas. Portanto, qualquer ferramenta usada deve ter permitido acesso transparente às informações para todos os envolvidos. Você está certo de que o modo assíncrono de transmitir e coletar informações ajuda porque as pessoas podem dedicar tempo antes de colocar sugestões. Se for solicitado respostas antecipadas - normalmente nas reuniões, o julgamento pode não ser igualmente bom em comparação com a mesma pessoa com trabalhos de casa suficientes.

2. No entanto, isso não significa necessariamente "democracia pura", onde todos os votos são iguais. Em geral, a pessoa que toma as decisões deve ser uma ou poucas - e, embora tenham tomado todas as opiniões, elas devem ser individualmente responsáveis ​​pelas decisões e não todas as pessoas que deram suas opiniões.

3. A maioria das decisões deve ser acionável. Pode ser difícil evitar contradições; mas o fato de as decisões não serem acionáveis ​​e apenas subjetivas significa possibilidades para interpretações futuras.

4. É importante classificar o nível e o escopo da decisão. Mais importante, precisamos identificar se estamos discutindo um problema de design específico ou um aspecto específico de código, aspecto de processos ou se esses problemas estão relacionados ao planejamento e ao rastreamento de projetos? Frequentemente, quando os problemas surgem de um código de produção - todos são aplicáveis, mas devemos ser capazes de distinguir todos os aspectos diferentes e de forma independente para poder gerenciar essas decisões com eficiência.

5. Às vezes, as decisões podem ser sobre se usamos certos sistemas ou papéis e responsabilidades para os indivíduos; pode ser difícil colocar essas decisões em paralelo com a codificação de decisões específicas em um fórum do tipo quadro de avisos.

6. Apenas mais uma anedota; toda equipe deve colocar as revisões de código e as de design como um processo por si só - o que abrangerá exaustivamente muitos problemas, como o exemplo que você citou. Eles precisam se as decisões de rastreamento tratam ou não de outras coisas.

As boas práticas de tomada de decisão envolvem muita disciplina sobre como reunimos as informações e garantimos que as decisões sejam seguidas com as implementações com o espírito certo.

Uma ferramenta só pode ajudar a tornar as informações mais apresentáveis, além disso; mas isso pode ser uma boa ajuda se funcionar para você.

FogBugz é o caminho a percorrer. Não é grátis. Os novos recursos tornam a implementação de uma metodologia ágil ainda mais fácil.

Um caminho mais simples e gratuito seria o Asana.

Independentemente da ferramenta usada, a comunicação em equipe é a mais importante para facilitar um projeto bem-sucedido.