5. DoR e DoD
Histórico de revisão
| Data | Versão | Descrição | Autores |
|---|---|---|---|
| 15/12/2024 | 0.1 | Criação do DoR e DoD | Marcos |
5.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 Sprint. Alguns itens que podem ser verificados para determinar se um requisito está "Ready" são:
- O requisito possui informação necessária para ser trabalhado? O requisito deve conter todos os detalhes necessários para que a equipe de desenvolvimento possa entender o que precisa ser feito.
- Está livre de ambiguidades? A descrição do requisito deve ser clara, sem inconsistências ou interpretações duvidosas.
- O requisito cabe em uma Sprint? O escopo do requisito deve ser pequeno o suficiente para ser concluído em uma única Sprint.
- O requisito está representado por uma história de usuário? O requisito deve ser descrito no formato de uma história de usuário, facilitando o entendimento pelo time.
- Prioridade definida: O requisito deve estar priorizado no backlog, com base em valores de negócio e complexidade técnica.
- Viabilidade técnica confirmada: A equipe de desenvolvimento deve entender como implementar o requisito e confirmar que possui as ferramentas e recursos necessários para tal.
5.2 Definition of Done (DoD)
O DoD é um acordo que demonstra a qualidade do requisito produzido, indicando que “Done” comprova a satisfação de todos com o trabalho realizado. Se um requisito não atende ao “Done”, ele não deve ser liberado ou apresentado na Sprint Review. Alguns itens que devem ser verificados para determinar se um requisito está "Done" são:
- Entrega um incremento do produto? A funcionalidade desenvolvida deve agregar valor ao produto como um todo, resultando em um incremento utilizável.
- Desenvolvimento Completo: A funcionalidade foi implementada por completo, de acordo com os requisitos estabelecidos.
- Testes Unitários e de Integração Realizados: Todos os testes unitários e de integração foram executados e aprovados, garantindo que o sistema funcione corretamente e se integre adequadamente.
- O código foi revisado por pelo menos um membro da equipe: O processo de revisão deve garantir qualidade e aderência aos padrões estabelecidos pela equipe.
- A funcionalidade foi integrada com sucesso ao repositório principal: Todas as alterações foram aplicadas no repositório principal sem conflitos e estão disponíveis para as próximas etapas do fluxo de desenvolvimento.