Melhores Práticas de Definição de Pronto

A Definição de Pronto (DoD) é uma lista de verificação compartilhada que define quando o trabalho está verdadeiramente completo. Sem uma DoD clara, "pronto" significa coisas diferentes para pessoas diferentes—levando a trabalho incompleto, problemas de qualidade e surpresas tardias no processo. Este guia cobre a criação e manutenção de uma DoD efetiva.

Propósito da DoD

Criando uma DoD

Construindo Sua Lista de Verificação

MODELO DE DEFINIÇÃO DE PRONTO
═════════════════════════════

QUALIDADE DO CÓDIGO:
─────────────────────────────────────
☐ Código segue padrões da equipe
☐ Sem erros de linting
☐ Sem avisos do compilador
☐ Auto-documentado ou comentado
☐ Código revisado e aprovado

TESTES:
─────────────────────────────────────
☐ Testes unitários escritos e passando
☐ Testes de integração passando
☐ Todos os testes existentes ainda passam
☐ Casos extremos cobertos
☐ Nenhum bug conhecido

DOCUMENTAÇÃO:
─────────────────────────────────────
☐ README atualizado se necessário
☐ Documentação da API atualizada
☐ Documentação do usuário atualizada
☐ Notas de versão redigidas
☐ Comentários para lógica complexa

IMPLANTAÇÃO:
─────────────────────────────────────
☐ Mesclado na branch principal
☐ Implantado em staging
☐ Testes de fumaça passando
☐ Sem regressão em staging
☐ Feature flag configurado (se usado)

ACEITAÇÃO:
─────────────────────────────────────
☐ Critérios de aceitação atendidos
☐ Product Owner aceitou
☐ Demonstrável para stakeholders
☐ Atende requisitos de performance
☐ Acessível (se aplicável)

COMPLETO:
─────────────────────────────────────
☐ Todos os itens acima marcados
☐ Pronto para produção
☐ Nenhuma tarefa de acompanhamento necessária
☐ Equipe concorda que está pronto

Personalizando para Sua Equipe

PERSONALIZAÇÃO DA DOD
══════════════════════

COMECE SIMPLES:
─────────────────────────────────────
DoD inicial (equipe nova):
☐ Código revisado
☐ Testes passando
☐ Mesclado na principal
☐ PO aceitou

Comece com o essencial.
Adicione conforme a equipe amadurece.

EQUIPE MADURA:
─────────────────────────────────────
DoD avançada:
☐ Código revisado (2 aprovadores)
☐ Testes unitários (>80% cobertura)
☐ Testes de integração
☐ Verificação de segurança limpa
☐ Benchmarks de performance atendidos
☐ Documentação atualizada
☐ Implantado em staging
☐ Testes E2E passando
☐ PO aceitou
☐ Notas de versão redigidas

Mais rigorosa conforme a capacidade cresce.

ESPECÍFICA DO CONTEXTO:
─────────────────────────────────────
Adicione com base nas suas necessidades:

Indústria regulada:
☐ Revisão de conformidade aprovada
☐ Trilha de auditoria documentada

App mobile:
☐ Testado em dispositivos alvo
☐ Acessibilidade verificada

Equipe de API:
☐ Documentação da API atualizada
☐ Mudanças disruptivas documentadas
☐ Versionamento correto

Personalize para seu contexto.

Aplicando a DoD

No Sprint

DOD NA PRÁTICA
═══════════════

DURANTE O DESENVOLVIMENTO:
─────────────────────────────────────
Desenvolvedor usa DoD como lista de verificação:
├── Trabalhando na tarefa
├── Código do recurso completo
├── Execute mentalmente pela DoD
├── "Escrevi os testes?"
├── "Foi revisado?"
├── Verificação própria antes de declarar pronto
└── DoD = verificação pessoal de qualidade

ANTES DE MOVER PARA PRONTO:
─────────────────────────────────────
Tarefa só pode mover para Pronto quando:
├── Cada item da DoD marcado
├── Sem conclusão parcial
├── Equipe pode verificar
├── "Se não está pronto pronto, não está pronto"
└── Adesão rigorosa

NA REVISÃO DO SPRINT:
─────────────────────────────────────
Ao demonstrar:
├── "Isso atende nossa DoD"
├── Testes passando ✓
├── Implantado em staging ✓
├── Documentado ✓
├── Stakeholders veem qualidade
└── Confiança na completude

RESPONSABILIDADE DA EQUIPE:
─────────────────────────────────────
Toda equipe responsável:
├── Qualquer um pode questionar "isso está pronto?"
├── Revisor de código verifica DoD
├── QA verifica itens da DoD
├── Propriedade coletiva
└── Qualidade é responsabilidade da equipe

DoD vs Critérios de Aceitação

Entendendo a Diferença

DOD VS CRITÉRIOS DE ACEITAÇÃO
═════════════════════════════

CRITÉRIOS DE ACEITAÇÃO:
─────────────────────────────────────
Requisitos específicos da história.
"O que esse recurso faz?"

Exemplo de história: Login do Usuário
Critérios de Aceitação:
├── Credenciais válidas → dashboard
├── Credenciais inválidas → mensagem de erro
├── 5 falhas → conta bloqueada
├── Link "Esqueci a senha" funciona
└── Específico PARA ESTA história

DEFINIÇÃO DE PRONTO:
─────────────────────────────────────
Padrões universais de qualidade.
"Como verificamos qualquer trabalho?"

Definição de Pronto:
├── Código revisado
├── Testes escritos
├── Documentação atualizada
├── Implantado em staging
└── Aplica-se a TODAS as histórias

AMBOS OBRIGATÓRIOS:
─────────────────────────────────────
História está completa quando:

1. Critérios de Aceitação atendidos
   (Recurso funciona corretamente)

E

2. Definição de Pronto atendida
   (Padrões de qualidade alcançados)

Faltando qualquer um = não pronto.

EXEMPLO:
─────────────────────────────────────
História: Login do Usuário

Critérios de Aceitação: ✓
├── Login funciona corretamente
├── Tratamento de erro funciona
├── Todos os cenários passam

Definição de Pronto: ?
├── Código revisado: ✓
├── Testes escritos: ✗ (faltando!)
├── Implantado: ✓
└── NÃO PRONTO (testes faltando)

Mantendo a DoD

Evolução

MANUTENÇÃO DA DOD
══════════════════

REVISÃO REGULAR:
─────────────────────────────────────
Na retrospectiva, pergunte:
├── Nossa DoD está funcionando?
├── Algum item sempre pulado?
├── Algo faltando que causa problemas?
├── Devemos adicionar/remover itens?
└── Evolua com a equipe

QUANDO ADICIONAR:
─────────────────────────────────────
Adicione à DoD quando:
├── Problemas recorrentes de etapa faltante
├── Capacidade da equipe aumentou
├── Novo requisito de conformidade
├── Problemas de qualidade persistem
└── Algo deve sempre acontecer

QUANDO REMOVER:
─────────────────────────────────────
Remova da DoD quando:
├── Automatizado e não precisa mais verificar
├── Nunca relevante (errado para contexto)
├── Sobrecarga excessiva, baixo valor
├── Mesclado em outro item
└── Mantenha DoD enxuta e relevante

HISTÓRICO DA DOD:
─────────────────────────────────────
Acompanhe mudanças:
├── Versione sua DoD
├── Data das mudanças
├── Anote por que mudou
├── Referencie em retrospectivas
└── Documento vivo

DoD no GitScrum

Implementação

DOD NO GITSCRUM
═══════════════

LISTA DE VERIFICAÇÃO DA TAREFA:
─────────────────────────────────────
Cada tarefa tem lista de verificação DoD:
├── Preenchida automaticamente do modelo
├── Marque conforme concluído
├── Progresso visual
├── Não pode fechar até todos marcados
└── Conclusão forçada

MODELO:
─────────────────────────────────────
Projeto → Configurações → Modelo DoD

Defina itens da lista de verificação:
├── Código revisado
├── Testes passando
├── Documentação atualizada
├── Implantado em staging
├── Aceitação verificada
└── Aplicado a todas as tarefas

REGRA DE WORKFLOW:
─────────────────────────────────────
Automação:
"Se DoD incompleta, não pode mover para Pronto"
├── Previne conclusão falsa
├── Porta de qualidade
├── Padrão consistente
└── Aplicação do sistema

RELATÓRIOS:
─────────────────────────────────────
Métricas DoD:
├── Taxa de conclusão
├── Itens frequentemente pulados
├── Tempo para completar DoD
├── Correlação de qualidade
└── Dados para melhoria

Melhores Práticas

Para Definição de Pronto

1. Equipe cria em conjunto — Propriedade compartilhada
2. Comece simples — Adicione conforme amadurece
3. Aplique consistentemente — Sem exceções
4. Revise regularmente — Evolua com a equipe
5. Torne visível — Todos conhecem a DoD

Anti-Padrões

ERROS DA DOD:
✗ Nenhuma DoD
✗ DoD criada só pelo gerente
✗ Muitos itens (esmagador)
✗ Itens rotineiramente pulados
✗ Nunca revisada/atualizada
✗ Diferente para pessoas diferentes
✗ Não aplicada
✗ Confundida com critérios de aceitação

Soluções Relacionadas

• Escrevendo critérios de aceitação claros
• Melhores práticas de garantia de qualidade
• Executando retrospectivas efetivas