Criando Definition of Done efetiva

Quando "feito" significa coisas diferentes para pessoas diferentes, você tem trabalho incompleto, stakeholders surpresos e dívida técnica. Uma Definition of Done (DoD) clara cria entendimento compartilhado do que completude parece, garantindo qualidade consistente e entrega previsível.

Por que DoD importa

Componentes DoD

Categorias a cobrir

CATEGORIAS DE DEFINITION OF DONE
════════════════════════════════

QUALIDADE DE CÓDIGO:
├── Código compila sem erros
├── Sem avisos de linting
├── Segue padrões de codificação
├── Sem code smells óbvios
└── Código auto-documentado

TESTING:
├── Testes unitários escritos e passando
├── Testes de integração passando
├── Sem diminuição na cobertura
├── Casos extremos testados
└── Teste manual completo

CODE REVIEW:
├── PR criado com descrição
├── Review solicitado
├── Feedback endereçado
├── Pelo menos 1 aprovação
└── Sem comentários não resolvidos

DOCUMENTAÇÃO:
├── Comentários de código onde necessários
├── README atualizado se necessário
├── Documentação de API atualizada
├── Documentação de usuário atualizada (se UI)
└── Entrada de changelog adicionada

DEPLOYMENT:
├── Merged para branch main
├── Deployed para staging
├── Teste smoke passou
├── Sem erros no monitoramento
└── Pronto para produção

Definições de exemplo

DoD básica (equipe pequena)

DEFINITION OF DONE (Básica)
═══════════════════════════

Antes de marcar tarefa "Done":

CÓDIGO:
- [ ] Código compila sem erros
- [ ] Sem erros de linting
- [ ] Segue guia de estilo da equipe

TESTING:
- [ ] Testes escritos para novo código
- [ ] Todos os testes passando
- [ ] Teste manual completo

REVIEW:
- [ ] PR aprovado por 1 reviewer
- [ ] Feedback endereçado

DEPLOY:
- [ ] Merged para main
- [ ] Deployed para staging
- [ ] Verificado funcionando

DoD abrangente (enterprise)

DEFINITION OF DONE (Enterprise)
════════════════════════════════

DESENVOLVIMENTO COMPLETO:
- [ ] Funcionalidade completa por critérios de aceitação
- [ ] Código compila no pipeline CI
- [ ] Sem avisos de análise estática
- [ ] Dívida técnica documentada (se houver)
- [ ] Feature flag configurado (se aplicável)

TESTING COMPLETO:
- [ ] Testes unitários: >80% cobertura no novo código
- [ ] Testes de integração escritos e passando
- [ ] Testes E2E para fluxos de usuário (se UI)
- [ ] Performance testado (se aplicável)
- [ ] Scan de segurança passou
- [ ] Acessibilidade testada (WCAG 2.1 AA)

REVIEW COMPLETO:
- [ ] Descrição de PR completa
- [ ] 2+ code reviews aprovados
- [ ] Todos comentários de review resolvidos
- [ ] Aprovação de arquitetura (se mudança major)
- [ ] Review de segurança (se manipulação de dados)

DOCUMENTAÇÃO COMPLETA:
- [ ] Documentação inline no código
- [ ] Documentação de API (se mudança de API)
- [ ] Documentação de usuário (se mudança UI)
- [ ] Runbook atualizado (se impacto ops)
- [ ] ADR criado (se decisão arquitetural)

DEPLOYMENT COMPLETO:
- [ ] Merged para branch main
- [ ] Pipeline CI/CD verde
- [ ] Deployed para staging
- [ ] Sign-off QA no staging
- [ ] Alertas de monitoramento configurados
- [ ] Pronto para deployment de produção

HANDOFF COMPLETO:
- [ ] Product owner verificou
- [ ] Demo gravado (se funcionalidade major)
- [ ] Equipe de suporte informada (se customer-facing)
- [ ] Release notes redigidos

DoD por tipo de tarefa

DoD POR TIPO DE TAREFA
══════════════════════

CORREÇÃO DE BUG:
├── Causa raiz identificada
├── Correção implementada
├── Teste de regressão adicionado
├── Sem issues relacionados
└── Deployed e verificado

FUNCIONALIDADE:
├── Todos critérios de aceitação atendidos
├── Testes abrangentes
├── Documentação atualizada
├── Reviewed e aprovado
└── Sign-off do produto

DÍVIDA TÉCNICA:
├── Problema endereçado
├── Sem mudança de funcionalidade
├── Testes ainda passando
├── Performance mantida
└── Aprendizados documentados

DOCUMENTAÇÃO:
├── Conteúdo preciso
├── Verificado ortografia
├── Links verificados
├── Reviewed por SME
└── Publicado

SPIKE/PESQUISA:
├── Pergunta respondida
├── Achados documentados
├── Recomendação feita
├── Equipe informada
└── Tarefas de follow-up criadas

Implementando DoD

Criando sua DoD

PROCESSO DE CRIAÇÃO DE DoD
══════════════════════════

PASSO 1: Workshop da equipe (60 min)
─────────────────────────────────────
- Que problemas trabalho incompleto causou?
- O que sempre esquecemos?
- Como "feito" deve parecer?

PASSO 2: Rascunhar categorias
─────────────────────────────────────
Agrupar sugestões em:
├── Código
├── Testing
├── Review
├── Documentação
├── Deployment

PASSO 3: Priorizar
─────────────────────────────────────
- Must have (não-negociável)
- Should have (padrão)
- Nice to have (aspiracional)

PASSO 4: Começar pequeno
─────────────────────────────────────
Começar com 5-8 itens. Expandir conforme
equipe amadurece e capacidades crescem.

PASSO 5: Tornar visível
─────────────────────────────────────
- Postar no wiki do projeto
- Link do GitScrum
- Referência no standup
- Review nas retros

DoD no GitScrum

ENFORÇANDO DoD NO GITSCRUM
══════════════════════════

TEMPLATE DE TAREFA:
─────────────────────────────────────
Incluir checklist DoD na descrição da tarefa

## Definition of Done
- [ ] Código reviewed e aprovado
- [ ] Testes escritos e passando
- [ ] Documentação atualizada
- [ ] Deployed para staging
- [ ] Verificado funcionando

AUTOMAÇÃO:
─────────────────────────────────────
Regra: Prevenir mover para "Done" se
checklist DoD não estiver completa

VISIBILIDADE:
─────────────────────────────────────
Exibir % de completude DoD no cartão da tarefa

Tratando violações DoD

QUANDO DoD NÃO É ATENDIDO
═════════════════════════

NÃO FAÇA:
✗ Deixar passar "só desta vez"
✗ Culpar a pessoa
✗ Adicionar burocracia

FAÇA:
✓ Discutir na retro
✓ Entender por que aconteceu
✓ Ajustar processo ou DoD
✓ Fornecer suporte para atender

EXCEÇÕES VÁLIDAS:
├── Correção de produção emergencial (documentar dívida técnica)
├── Trabalho experimental/protótipo
├── Skip explicitamente acordado (documentado)

MESMO ENTÃO:
Criar tarefa de follow-up para completar
os itens DoD pulados

Evolução de DoD

Amadurecendo sua DoD

NÍVEIS DE MATURIDADE DoD
════════════════════════

NÍVEL 1: BÁSICO
├── Código compila
├── Testes passam
├── Código reviewed
└── Merged

NÍVEL 2: PADRÃO
├── Tudo no Nível 1
├── Requisitos de cobertura
├── Documentação
├── Deployment staging
└── Verificação

NÍVEL 3: MADURO
├── Tudo no Nível 2
├── Scanning de segurança
├── Testing de performance
├── Acessibilidade
├── Monitoramento configurado
└── Pronto para produção

NÍVEL 4: EXCELENTE
├── Tudo no Nível 3
├── Feature flags
├── Pronto para A/B testing
├── Plano de rollback
├── Suporte treinado
└── Analytics configurado

Progrida pelos níveis conforme
capacidade da equipe e ferramentas melhoram.

Melhores práticas

Para Definition of Done

1. Comece pequeno — 5-8 itens, não 20
2. Torne visível — Todos veem constantemente
3. Enforce — DoD é não-negociável
4. Revise regularmente — Trimestral no mínimo
5. Propriedade da equipe — Todos concordam

Anti-padrões

ERROS DE DEFINITION OF DONE:
✗ DoD existe mas ninguém segue
✗ Muitos itens (irrealístico)
✗ Não revisado ou atualizado
✗ Equipes diferentes, DoDs diferentes (sem padrão)
✗ DoD violado "por causa do deadline"
✗ DoD é apenas testing (ignora outros aspectos)
✗ Ninguém sabe onde DoD está documentado

Soluções relacionadas

• Criando critérios de aceitação claros
• Configurando gates de qualidade para releases
• Melhorando qualidade de code review