Pular para conteúdo

DoR & DoD

8 DoR e DoD

Esta seção apresenta os conceitos de Definition of Ready (DoR) e Definition of Done (DoD), que ajudam a garantir que o trabalho esteja bem definido antes de ser iniciado e que esteja completo antes de ser considerado pronto para entrega.

8.1 Definition of Ready (DoR)

O DoR é um acordo entre o time e o Product Owner (PO), indicando quando um requisito estará preparado para ser puxado para uma Timebox. Ele define os critérios que devem ser atendidos para que uma user story, cenário esteja pronto para ser desenvolvido. Isso garante clareza nos requisitos e ausência de impedimentos.

Para um item do backlog ser considerado Ready:

  • O requisito possui informações necessárias para ser trabalhado, com detalhes suficientes e sem ambiguidades.
  • O requisito cabe em uma Timebox, é suficientemente pequeno para ser concluído no ciclo.
  • Está representado por uma história de usuário, facilitando o entendimento pelo time.
  • Possui critérios de aceitação.
  • Está mapeado para uma interface, quando necessário.
  • Suas dependências estão mapeadas.
  • Já foi estimado em esforço.
  • Está alinhado com os objetivos do produto e possui valor claro agregado.

8.2 Definition of Done (DoD)

O DoD é um acordo que define quando uma funcionalidade pode ser considerada concluída com qualidade, demonstrando que o time e o PO estão satisfeitos com o resultado. Um requisito que não atenda completamente ao DoD não deve ser liberado ou apresentado na Timebox Review session.

Para um item do backlog ser considerado Done:

  • Entrega um incremento funcional do produto, com valor claro.
  • Contempla os critérios de aceite estabelecidos previamente.
  • Está documentado para uso, manutenção e compreensão por outros membros ou stakeholders.
  • Está aderente aos padrões de codificação definidos pela equipe.
  • Mantém os índices de performance esperados, sem prejudicar o desempenho geral do sistema.
  • O desenvolvimento está completo, conforme o escopo e requisitos definidos.
  • Foram realizados e aprovados testes unitários e de integração, garantindo funcionamento correto e integração com os módulos.
  • Foi realizada revisão de código por outro desenvolvedor e validado pela equipe de QA.
  • Requisitos legais foram respeitados.
  • A documentação foi atualizada e o feedback do cliente foi incorporado.

Histórico de Versão:

Data Versão Descrição Autor Revisores
25/05/2025 1.0 Criação do Documento Isabelly Henrique Carvalho