Quantas vezes você já ouviu um colega dizer "está pronto" sobre uma tarefa, apenas para descobrir dias depois que faltava escrever testes, atualizar a documentação ou fazer o deploy? A frase "está pronto" e surpreendentemente ambigua em times de desenvolvimento, e essa ambiguidade custa caro: retrabalho, bugs em produção, frustrações e sprints que nunca entregam o que prometeram.
A Definition of Done (DoD) e um conceito fundamental do Scrum e das métodologias ágeis que resolve exatamente esse problema. Ela estabelece um contrato claro e compartilhado entre todos os membros do time sobre o que significa uma tarefa estar verdadeiramente concluida. Neste artigo, vamos explorar como criar, implementar e evoluir uma DoD que realmente funcione para o seu time.
O que é a Definition of Done
A Definition of Done e uma lista de critérios que devem ser atendidos para que qualquer item de trabalho seja considerado completo. Ela não é específica para uma tarefa individual, mas sim um padrão que se aplica a todos os itens de trabalho do time. Pense nela como um checklist de qualidade mínima que garante consistência nas entregas.
No Scrum Guide, a DoD e descrita como "uma descrição formal do estado do Incremento quando ele atende as medidas de qualidade exigidas para o produto". Em termos práticos, ela responde a pergunta: "Quais são todas as coisas que precisam acontecer antes de podermos dizer que isso está pronto?"
"Uma tarefa sem Definition of Done e como uma viagem sem destino definido. Você pode estar andando, mas nunca sabe quando chegou."
Por que a Definition of Done é essencial
A ausencia de uma DoD clara gera uma serie de problemas que se acumulam ao longo do tempo e corroem a saude do projeto e do time:
Transparência e previsibilidade
Quando todos concordam sobre o que "pronto" significa, a velocidade do time se torna uma métrica confiável. Se cada pessoa tem uma definição diferente de "pronto", a velocity medida nas sprints não reflete a realidade. Um time pode parecer rápido ao mover cards para "done", mas estar acumulando uma montanha de trabalho oculto que explodira em algum momento futuro.
Qualidade consistente
A DoD atua como um guarda de qualidade automático. Em vez de depender da disciplina individual de cada desenvolvedor para lembrar de escrever testes, revisar código é atualizar documentação, a DoD torna esses passos obrigatórios e visíveis para todo o time.
Redução da dívida técnica
Sem uma DoD, e tentador declarar algo como "pronto" quando o código funciona, deixando testes, refatoração e documentação para "depois". Esse "depois" raramente chega, e a dívida técnica se acumula silenciosamente. Uma DoD bem definida impede que atalhos se tornem hábito.
Alinhamento do time
A DoD cria uma linguagem comum. Quando um Product Owner pergunta se uma feature está pronta, a resposta não depende de interpretação pessoal. Ela está pronta quando todos os critérios da DoD foram atendidos, ponto final.
Como criar uma Definition of Done eficaz
Criar uma DoD não é um exercício solitario do Scrum Master ou do tech lead. Ela deve ser construída colaborativamente por todo o time, pois todos precisam se comprometer com ela. Aqui está um processo passo a passó para criar a sua:
Passo 1: Reuna o time
Reserve uma hora para uma sessão dedicada. Todos os membros do time de desenvolvimento devem participar, além do Product Owner. Cada pessoa traz uma perspectiva diferente sobre o que considera importante para uma entrega de qualidade.
Passo 2: Liste todos os critérios possíveis
Faca um brainstorm aberto. Perito para cada pessoa listar individualmente tudo que acredita que deve acontecer antes de uma tarefa ser considerada pronta. Exemplos comuns incluem:
- Código escrito e commitado no repositório
- Testes unitarios escritos e passando
- Testes de integração passando
- Code review realizado e aprovado por pelo menos um colega
- Pipeline de CI passando sem erros
- Documentação técnica atualizada
- Changelog atualizado
- Feature testada em ambiente de staging
- Sem regressoes em funcionalidades existentes
- Performance dentro dos limites aceitaveis
- Acessibilidade verificada
- Traducoes atualizadas (se aplicavel)
- Deploy realizado em produção
- Métricas de monitoramento configuradas
Passo 3: Priorize e negocie
Nem todos os critérios serao viaiveis imediatamente. O time deve discutir cada item e decidir coletivamente o que é obrigatório agora e o que sera adicionado no futuro. E melhor começar com uma DoD menor que o time consegue realmente cumprir do que uma DoD ambiciosa que sera ignorada.
Passo 4: Documente e torne visível
A DoD finalizada deve ser documentada em um local acessível a todos. Imprima e cole na parede, adicione ao README do projeto, inclua como template no seu board Kanban. No GalagoWork, você pode criar checklists padronizados que são automaticamente associados a cada nova tarefa, garantindo que a DoD esteja sempre visível.
Passo 5: Revise periodicamente
A DoD não e estatica. A cada retrospectiva, o time deve avaliar se a DoD atual ainda faz sentido. Novos critérios podem ser adicionados conforme o time amadurece, e critérios que se tornaram automáticos podem ser consólidados.
Exemplos práticos de Definition of Done
Para tornar o conceito mais concreto, vamos ver exemplos de DoD para diferentes contextos:
DoD para um time de backend
- Código segue os padrões de estilo definidos (linter passando)
- Testes unitarios com cobertura mínima de 80% para o novo código
- Testes de integração para novos endpoints ou alterações em endpoints existentes
- Code review aprovado por pelo menos um colega
- Pipeline de CI verde
- Documentação da API atualizada (Swagger/OpenAPI)
- Migrações de banco de dados testadas e reversiveis
- Sem vulnerabilidades críticas detectadas pelo scanner de segurança
- Deploy realizado em staging e validado
DoD para um time de frontend
- Componente funciona nos navegadores suportados (Chrome, Firefox, Safari, Edge)
- Design responsivo verificado em mobile, tablet e desktop
- Testes unitarios para lógica de negócio nos componentes
- Acessibilidade verificada (contraste, navegação por teclado, leitor de tela)
- Code review aprovado
- Storybook atualizado para componentes novos ou modificados
- Sem erros no console do navegador
- Performance: Largest Contentful Paint abaixo de 2.5s
DoD para uma user story completa
- Todos os critérios de aceitação foram atendidos e verificados
- DoD técnica (backend e/ou frontend) cumprida
- Product Owner validou a funcionalidade em staging
- Testes de regressao passando
- Feature flag configurada para rollout gradual (se aplicavel)
- Métricas de monitoramento e alertas configurados
- Release notes redigidas
Definition of Done vs. Critérios de Aceitação
Uma confusao comum e misturar Definition of Done com Critérios de Aceitação. São conceitos complementares, mas diferentes:
Critérios de Aceitação são específicos para cada user story ou tarefa. Eles descrevem o comportamento esperado da funcionalidade. Por exemplo: "O usuário deve poder filtrar pedidos por data" ou "O campo de email deve validar o formato antes de submeter o formulário".
Definition of Done e universal para todas as tarefas. Ela descreve os padrões de qualidade e processó que se aplicam independentemente do que está sendo construído. Escrever testes, fazer code review é atualizar documentação são exemplos de DoD.
Ambos precisam ser atendidos para que uma tarefa esteja verdadeiramente pronta. Os Critérios de Aceitação garantem que a coisa certa foi construída, enquanto a DoD garante que foi construída da maneira certa.
Desafios comuns e como supera-los
"A DoD atrasa nossas entregas"
Esse e o argumento mais frequente contra a DoD, e é fundamentalmente equivocado. A DoD não atrasa entregas; ela torna visível o trabalho que já deveria estar sendo feito. Se pular testes e code review faz a tarefa parecer "pronta" mais rápido, o custo aparece depois em forma de bugs, retrabalho e incidentes em produção. A DoD simplesmente move esse custo para o momento certo, onde é mais barato resolve-lo.
"Nem toda tarefa precisa de tudo isso"
E verdade que uma correcao de typo não precisa de testes de integração. A DoD pode ter níveis: uma DoD básica para tarefas pequenas e uma DoD completa para features. Mas cuidado com exceções demais: o valor da DoD está justamente na sua universalidade. Se cada tarefa negocia quais critérios se aplicam, você voltou ao ponto de partida.
"O time não segue a DoD"
Se o time consistentemente não consegue cumprir a DoD, ela provavelmente e ambiciosa demais para o momento atual. Reduza para algo alcancavel e evolua gradualmente. Também é importante que a DoD seja respeitada nas cerimônias: na Sprint Review, so apresente itens que cumpriram a DoD completa. Isso cria accountability natural.
"Temos pressa, vamos pular a DoD desta vez"
Essa e a ladeira escorregadia. Uma vez que a DoD e negociavel por pressao de prazo, ela perde todo o seu valor. Se frequentemente não ha tempo para cumprir a DoD, o problema está no planejamento da sprint, não na DoD. O Scrum Master deve proteger a DoD como uma das responsabilidades mais importantes do seu papel.
DoD e ferramentas de gestão de projetos
A integração da DoD com suas ferramentas de gestão de projetos e crucial para que ela não seja apenas um documento esquecido. Ferramentas modernas como o GalagoWork permitem:
- Checklists automáticos: Cada nova tarefa criada já vem com a DoD como checklist, garantindo visibilidade constante.
- Bloqueio de movimentação: Configure o board para impedir que um card seja movido para "Done" sem que todos os itens da DoD estejam marcados.
- Integração com CI/CD: Status do pipeline, resultado dos testes e aprovação de code review podem ser atualizados automaticamente no card.
- Métricas de conformidade: Acompanhe ao longo do tempo quantas tarefas cumpriram a DoD completa versus quantas tiveram exceções.
Evoluindo a Definition of Done
A DoD deve crescer com o time. Um time que está começando pode ter uma DoD simples com cinco itens. Um time maduro pode ter uma DoD com quinze itens que inclui verificação de segurança, testes de performance e observabilidade. O importante e que cada evolução seja uma decisão consciente e coletiva do time.
Use as retrospectivas para identificar oportunidades de evolução. Pergunte: "Que tipo de problema recorrente poderiamos prevenir adicionando um critério a DoD?" Se bugs de regressao são frequentes, talvez seja hora de adicionar testes de regressao automatizados. Se incidentes em produção são comuns após deploys, adicione validação em staging como critério obrigatório.
Conclusão: a DoD como alicerce da qualidade
A Definition of Done e um dos conceitos mais simples e poderosos das métodologias ágeis. Ela cria um contrato social dentro do time que eleva a qualidade, melhora a previsibilidade e reduz o retrabalho. Não e uma burocracia a mais: e um investimento em sanidade que se paga a cada sprint.
Comece com uma DoD simples que seu time consiga cumprir consistentemente. Torne-a visível em todas as ferramentas e cerimônias. Resista a tentação de ignora-la sob pressao. E evolua-a continuamente conforme o time amadurece. Com o tempo, a DoD se tornara tao natural que o time nem precisara pensar nela: ela sera simplesmente a forma como as coisas são feitas.
Porque no final das contas, "pronto" so significa pronto quando todos concordam que está pronto.