8.DoR e DoD

8. DoR e DoD

Esta seção apresenta os conceitos de Definition of Ready (DoR) e Definition of Done (DoD), que são fundamentais para assegurar a fluidez e a qualidade no ciclo de vida do desenvolvimento de software. O DoR garante que um item de trabalho esteja suficientemente bem definido antes de ser iniciado, evitando retrabalhos e ambiguidades. Já o DoD define os critérios mínimos para considerar um item como concluído, assegurando que a entrega atenda aos requisitos funcionais e não funcionais esperados.

8.1 Definition of Ready (DoR)

O Definition of Ready estabelece os critérios mínimos que uma user story, caso de uso ou cenário deve atender antes de ser considerado pronto para desenvolvimento. Esses critérios visam garantir clareza, completude e viabilidade técnica do item de trabalho.

Os critérios adotados neste projeto para o DoR são:

O requisito está associado a uma User Story (US)?
A US segue os princípios INVEST (Independente, Negociável, Valioso, Estimável, Pequeno e Testável)?
Os critérios de aceitação estão definidos e descritos na US?
As regras de negócio estão claras, completas e descritas na US?

Esses critérios permitem que o time de desenvolvimento inicie o trabalho com uma compreensão clara do que precisa ser feito, minimizando incertezas e impedimentos.

8.2 Definition of Done (DoD)

O Definition of Done especifica os critérios que devem ser cumpridos para que uma funcionalidade, tarefa ou item de backlog seja considerado concluído. Ele assegura que o trabalho esteja completo, testado, revisado e pronto para entrega ou implantação.

Os critérios adotados neste projeto para o DoD são:

A funcionalidade cumpre todos os critérios de aceitação definidos?
O código foi implementado e revisado de acordo com as especificaçes do requisito(descritas pela US associada)?
Os testes unitários foram realizados e aprovados?
As regras de negócio foram satisfeitas na implementação?
O deploy foi realizado com sucesso?
A funcionalidade foi validada com o engenheiro de requisitos principal da sprint?

Esses critérios ajudam a garantir que as entregas tenham qualidade e estejam alinhadas com as expectativas dos stakeholders. perceba que o engenheiro de requisitos é definido no início de cada sprint por nós, cada membro da equipe ficou sendo o "engenherio de requisitos" chefe em cada sprint. Ele esteve a frente e puxou mais tarefas que os outros membros, mas não signifca que todos os outros membros não participaram das atividades da ER