Por que combinar o significado de pronto?
Imagine que uma funcionalidade passou na máquina de quem a desenvolveu, mas não tem teste, ainda não foi revisada e depende de uma configuração que não existe no ambiente de produção. Para uma pessoa, ela está pronta; para outra, ainda é trabalho em andamento. Essa diferença gera surpresas no fim da sprint e torna as previsões pouco confiáveis.
A Definition of Done (DoD) é um acordo compartilhado sobre qualidade e completude. Ela não é uma lista para punir pessoas, nem substitui critérios de aceite específicos de cada história. Critérios de aceite descrevem o comportamento daquela funcionalidade; DoD descreve o padrão comum esperado para todo incremento.
O que uma boa Definition of Done pode conter?
O conjunto deve ser curto o bastante para ser lembrado e rigoroso o bastante para reduzir riscos. Uma equipe de produto web pode começar com critérios como:
- O comportamento atende aos critérios de aceite e os casos de erro relevantes estão tratados.
- O código foi revisado conforme o processo combinado e as verificações automáticas passaram.
- Testes adequados foram adicionados ou atualizados, sem deixar falhas conhecidas escondidas.
- Logs, métricas e tratamento de erros necessários permitem operar a funcionalidade.
- Documentação, configuração ou migrações afetadas foram atualizadas.
- A mudança está integrada e pode ser implantada pelo processo normal, ou há uma razão explícita para não estar.
Nem todo produto precisa de todos esses itens. Um sistema regulado pode precisar de evidências e aprovações formais; um protótipo pode adotar um acordo menor. O critério deve servir à realidade da equipe e do risco.
DoD não é critério de aceite nem plano da tarefa
Se uma história diz “o cliente pode cancelar o pedido antes do envio”, esse é um critério específico do comportamento. “Testes automatizados relevantes passaram” pode fazer parte da DoD de todas as histórias. Misturar as duas coisas cria listas enormes e dificulta distinguir o que torna essa funcionalidade correta do que é padrão de qualidade geral.
Também não confunda DoD com uma lista de atividades individuais. “Executar o comando X” pode envelhecer quando a ferramenta muda. Escreva resultados verificáveis (“a análise estática obrigatória passou”) sempre que possível.
Como criar o acordo com a equipe
- Reúna desenvolvimento, produto, QA e operação conforme as responsabilidades do time.
- Liste os problemas recorrentes: defeitos em produção, trabalho esquecido, documentação desatualizada.
- Transforme os riscos mais importantes em condições observáveis.
- Comece com poucos itens e identifique quais podem ser automatizados.
- Revise o acordo periodicamente quando contexto ou risco mudar.
Uma DoD escrita por uma única pessoa e imposta sem conversa tende a virar burocracia. O propósito é explicitar expectativas e compartilhar responsabilidade, não transferir toda a qualidade para uma função específica.
O que fazer quando um item não pode ser cumprido?
Uma exceção pode ser necessária, por exemplo numa correção urgente. Ela deve ser transparente: registrar o risco, definir quem aceita a exceção e criar acompanhamento quando houver trabalho pendente. Se exceções viram regra, a DoD está desconectada da capacidade real ou o fluxo está incentivando atalhos.
Não marque como completo algo que não cumpre o acordo apenas para melhorar um indicador. É mais honesto renegociar escopo, dividir o item ou explicitar uma exceção do que esconder trabalho não terminado.
DoD como ferramenta de melhoria
Observe se os critérios realmente reduzem retrabalho e incidentes. Remova itens que não ajudam, automatize verificações repetitivas e melhore a colaboração onde a lista revela uma lacuna. A qualidade não pode ser “inspecionada para dentro” no último momento; ela emerge das decisões de desenho, testes, revisão e operação ao longo do trabalho.
Uma Definition of Done clara melhora conversas sobre prazo: se um item falha num critério, a equipe enxerga o trabalho restante em vez de descobrir depois. Para conhecer práticas complementares, leia code review que ensina e testes de integração com ASP.NET Core.