Chega de erro na criação de issues, por favor

Seguindo a linha de boas práticas em equipes de desenvolvimento de software, vamos começar falando das temidas Correções / Issues.

Uma issue é basicamente uma correção ou ajuste, um ponto de atenção no projeto, que por algum motivo, não está funcionando como deveria.

É uma frente de tarefas que se possui falha na comunicação, pode gerar atrasos, prejuízos e dores de cabeça que seriam evitáveis com um pouco mais de atenção na hora de abrir e descrever a issue.

Separei alguns pontos que considero boas práticas para aplicar no desenvolvimento e gerenciamento das issues:

Primeiro de tudo, issue é correção ou ajuste, não é task nova.

• Não é nova funcionalidade ou nem alteração de regra de negocio. Misturar tudo pode gerar confusão e dificultar o acompanhamento de demandas com prioridades maiores entre as correções.

Issues precisam ser validadas por alguém.

• Pode acontecer de stakeholder ou um terceiro de fora do núcleo do desenvolvimento/requisitos abre uma issue que, na verdade, é só falta de entendimento do componente ou da regra. Ou abrir uma issue sem descrição, sem detalhes, sem a devida explicação do que está acontecendo e qual o cenário correto.

Issue ou mal-entendimento?

• Sempre bom verificar se a issue é realmente um erro para corrigir, e que não é uma falta de entendimento da regra de negócio, do componente ou má configuração, etc.

Uma issue de cada vez.

• Algo que facilita muito na comunicação e no controle das entregas, manter uma issue por "card". Dessa forma fica muito mais tranquilo de você acompanhar o que está sendo feito, o que vai ser entregue. Quando várias correções são agrupadas, basta uma falhar para todo o pacote voltar (pior fica se não for relatado qual das issues não passaram).

Acredito que além disso, uma estrutura básica que se deve seguir na criação de uma issue seria:

• Título claro e direto: ajuda todos a entender rapidamente o problema.
• Descrição do problema, criar uma issue só com titulo é maldade, por favor.
• Evidências (prints, logs, URLs etc.): dar todo o contexto e ajuda quem vai corrigir a reproduzir o erro.
• Indicação da tela ou módulo afetado .
• Contexto: quanto mais informação, menor a chance de mal-entendidos e retrabalhos.

Post feito com base em dores de cabeça que ando tendo na minha equipe, usei i.a apenas para melhorar alguns fluxos gramáticas e ortográficos.

Link do post original do linkedin.

Vlw, Flw.