Definition of Done (DoD)

Critérios que definem quando uma tarefa está realmente completa.

O que é Definition of Done?

Definition of Done é uma checklist acordada pelo time que define quando uma tarefa pode ser considerada pronta.

Por que ter uma DoD?

✅ Alinha expectativas - Todo mundo sabe o que "pronto" significa
✅ Mantém qualidade - Evita código "pronto mas bugado"
✅ Facilita onboarding - Juniors sabem exatamente o que entregar
✅ Reduz retrabalho - Menos idas e vindas no review
✅ Nivela o time - Padrão igual para plenos e juniors

Status Atual

FASE 1 ATIVA

Estamos na FASE 1 - DoD mínima para construir cultura.

---

Definition of Done - FASE 1

Fase 1

Uma tarefa só está PRONTA quando:

✅ Checklist Obrigatória

• [ ] Funcionalidade testada e funcionando

  • Testada localmente
  • Casos principais validados
  • Sem erros visíveis

• [ ] Código revisado antes de solicitar aprovação

  • Autor fez auto-revisão
  • Código está limpo e legível
  • Comentários desnecessários removidos

• [ ] Conventional Commits seguidos

  • Todos commits seguem o padrão
  • Mensagens claras e objetivas
  • Ver: Conventional Commits

• [ ] Documentação atualizada (se aplicável)

  • README atualizado se mudou setup
  • Variáveis de ambiente documentadas
  • API documentada se mudou endpoints
  • Ver quando documentar abaixo ↓

• [ ] CI/CD passou sem erros

  • Pipeline verde no GitLab
  • Todas validações passaram
  • Sem warnings críticos

• [ ] Aprovado por 1 revisor

  • Maintainer ou Lead Técnico
  • Sem comentários pendentes
  • Ver: Merge Requests

Definition of Done - FASE 2 (Futuro)

FASE 2 - PLANEJADA

Quando o time estiver mais maduro, evoluiremos para critérios mais rigorosos.

Fase 2

FASE 2 - PLANEJADA

Quando o time estiver mais maduro, evoluiremos para critérios mais rigorosos..

Critérios adicionais planejados:

• [ ] Cobertura de testes mínima

  • Ex: 70% de cobertura em código novo
  • Testes unitários obrigatórios para lógica crítica

• [ ] Documentação obrigatória para contratos públicos

  • APIs públicas sempre documentadas
  • Contratos de integração formalizados

• [ ] Performance validada em features críticas

  • Queries otimizadas (sem N+1)
  • Tempo de resposta aceitável
  • Carga testada se aplicável

• [ ] Segurança revisada

  • Input validation
  • Proteção contra injeção
  • CSRF/XSS prevenidos

Status: 🔮 Planejado para revisão trimestral

---

Quando Documentar?

Nem toda tarefa precisa atualizar documentação. Use este guia:

✅ Documentar quando:

• Adicionou/mudou variável de ambiente → Atualizar .env.example
• Mudou API (endpoint, request, response) → Atualizar docs de API
• Mudou fluxo de setup/deploy → Atualizar README ou docs de deploy
• Adicionou comando novo (Makefile, script) → Atualizar README
• Mudou como alguém usa a feature → Atualizar documentação da feature

❌ Não precisa documentar:

• Refatoração interna (ninguém fora do código nota)
• Fix de bug (comportamento volta ao esperado)
• Ajuste de estilo/lint
• Mudanças que não afetam uso externo

---

Aplicação da DoD

Onde a DoD se aplica?

Atualmente:

• ✅ Merge Requests (principal)
• ✅ Tarefas em geral

Futuramente:

• 🔮 Releases em produção
• 🔮 Hotfixes
• 🔮 Spikes/POCs (critérios adaptados)

Quem valida a DoD?

• Autor: Auto-revisão antes de pedir MR
• Revisor: Valida no Code Review
• CI/CD: Valida automaticamente (commits, pipeline)
• Lead Técnico: Visão geral de qualidade

---

Como Usar a DoD

Para Desenvolvedores

Antes de abrir MR:

# Auto-checklist mental:
✅ Testei tudo localmente?
✅ Revisei meu próprio código?
✅ Commits seguem o padrão?
✅ Precisa documentar algo?
✅ Pipeline vai passar?

No template de MR:

• Checklist da DoD já está incluso
• Marque cada item ao completar
• Justifique se algo não se aplica

Para Revisores

Ao revisar MR:

# Checklist de revisão:
✅ DoD foi seguida?
✅ Checklist do MR está completa?
✅ Justificativas fazem sentido?
✅ Qualidade está aceitável?

Não aprovar se:

• ❌ DoD não foi seguida sem justificativa
• ❌ Pipeline está quebrado
• ❌ Documentação necessária faltando

---

Exceções

Quando flexibilizar a DoD?

Casos válidos:

• Hotfix crítico em produção (documentar depois)
• Spike/POC experimental (DoD adaptada)
• Docs-only (alguns itens não aplicam)

Como proceder:

1. Deixar explícito no MR que é exceção
2. Justificar o motivo
3. Criar issue para regularizar depois (se necessário)

Nunca flexibilizar:

• ❌ CI/CD quebrado
• ❌ Conventional Commits (sempre obrigatório)
• ❌ Aprovação (sempre precisa)

---

FAQ

Por que não temos testes unitários obrigatórios?

Testes estão sendo adotados progressivamente projeto por projeto. Na FASE 1, foco está em construir cultura de padrões básicos. Testes virão na FASE 2 quando o time estiver mais maduro.

Quem decide quando migrar para FASE 2?

Lead Técnico em conjunto com o time. Critérios: FASE 1 funcionando naturalmente por pelo menos 3 meses, time demonstrando maturidade, pedido do próprio time para mais rigor.

E se eu discordar de algum critério?

Discussões sobre DoD são bem-vindas! Leve para o Lead Técnico ou discuta no canal #dev. DoD deve fazer sentido para o time todo.

Posso adicionar critérios extras no meu projeto?

Sim! DoD é o mínimo. Projetos podem ter critérios adicionais se fizer sentido (ex: projeto crítico pode exigir testes mesmo na FASE 1).

---

Atualizações

Data	Mudança	Responsável
01-2025	DoD FASE 1 implementada	Lider Técnico
-	DoD FASE 2 planejada	-

Próxima revisão: Semestral (Julho 2025)

---

Recursos Relacionados

Sobre Definition of Done:

• Merge Requests - Template de MR usa a DoD
• Conventional Commits - Parte da DoD
• Code Review - Onde DoD é validada

Dúvidas?

Consulte o Lead Técnico ou canal #dev.