DoR e DoD
8. DoR e DoD
8.1 Definition of Ready (DoR)
O DoR, em português Definição de Preparado, é o agrupamento de critérios definidos entre a equipe e o Product Owner (PO) que estabelece se um requisito está preparado para ser trabalhado em uma sprint ou não. A importância de sua aplicação consiste na garantia de que os requisitos estejam bem declarados, para que o desenvolvimento não seja prejudicado. Sendo assim, segue a lista de itens que definem se o requisito vai para o "Ready":
- O requisito contém os critérios de aceitação informados? Através do que foi informado pelo stakeholder, o requisito deve conter critérios de aceitação que assegurem sua definição.
- O requisito está claro tanto para a equipe quanto para o stakeholder? Com o objetivo de evitar ambiguidades e mensurar o requisito, é importante que os desenvolvedores e o stakeholder estejam alinhados sobre ele.
- O requisito encaixa na sprint? O tamanho do requisito deve ser compatível com a duração da sprint, de modo que possa ser finalizado sem comprometer o prazo.
- O requisito possui apresentação através de história de usuário? O requisito deve estar representado como uma história de usuário, o que auxilia na compreensão da equipe.
- O requisito foi revisado pelo analista de requisitos? O analista de requisitos é responsável por realizar a última verificação do requisito, o que garante a sua inserção na sprint para ser trabalhada.
8.2 Definition of Done (DoD)
O DoD, em português Definição de Pronto, é o agrupamento de critérios definidos pela equipe que define a qualidade do requisito elaborado e a satisfação dos membros com o esforço realizado. Caso o requisito não atenda a todos os critérios, ele não está liberado, tanto para implementação no produto quanto na apresentação na Sprint Review. Dessa forma, segue a lista de itens que definem se o requisito atende o "Done":
- Alcança os critérios de aceitação determinados? A funcionalidade precisa apresentar o comportamento esperado, conforme informado pelo stakeholder.
- Atende às políticas da equipe estabelecidos para issues, branches e pull requests? O trabalho do responsável pela funcionalidade deve seguir as políticas da equipe para manter a organização do versionamento do projeto.
- Está desenvolvida por completo? A funcionalidade deve estar totalmente implementada, com todas as suas partes integradas e operando conjuntamente.
- Está disponível para acesso pelo stakeholder? A funcionalidade deve estar liberada e acessível ao stakeholder para uso.
- Foi incorporada à branch principal com ausência de conflitos? A branch de desenvolvimento da funcionalidade deve estar integrada à branch principal sem conflitos.
- Foi revisada pelo analista de QA? O analista de QA deve revisar a funcionalidade, garantir a conformidade com a LGPD, se aplicável, e assegurar uma cobertura mínima de testes de 80%.
Histórico de Versão
| Data | Versão | Descrição | Autor(es) | Revisor(es) |
|---|---|---|---|---|
| 18/05/2025 | 1.0 | DoR e DoD | Willian Silva | Caio Venâncio |
| 26/05/2025 | 1.1 | Correção do DoD | Willian Silva |