DoR e DoD

Esta seção estabelece os acordos de trabalho da equipe para a Definition of Ready (DoR) e a Definition of Done (DoD). A DoR assegura que um requisito está claro e preparado para o desenvolvimento, enquanto a DoD garante que o trabalho entregue possui a qualidade necessária para ser considerado concluído.

Definition of Ready (DoR)

A DoR é um acordo entre a equipe e o Product Owner (PO) que define os critérios mínimos para um requisito ser considerado pronto para ser selecionado em uma Sprint. Isso garante que a equipe de desenvolvimento possa trabalhar de forma eficiente e sem ambiguidades. Um requisito é considerado "Ready" quando atende aos seguintes critérios:

Informação Suficiente: O requisito possui todos os detalhes necessários para que a equipe de desenvolvimento entenda o que precisa ser feito, sem margem para dúvidas ou interpretações vagas.
Formato de História de Usuário: O requisito está descrito no formato de uma história de usuário, facilitando a compreensão do valor que será entregue ao usuário final.
Critérios de Aceite Claros: O requisito possui critérios de aceitação objetivos e, se necessário, exemplos práticos que descrevem o comportamento esperado. Isso garante que todos saibam como a funcionalidade deve funcionar e como ela será validada.
Tamanho Adequado: O requisito foi dimensionado para ser pequeno o suficiente para ser concluído dentro de uma única Sprint.
Interface Mapeada: Caso o requisito envolva uma interface de usuário, os mockups ou wireframes necessários já estão definidos e disponíveis para consulta.

Definition of Done (DoD)

A DoD é o acordo de qualidade da equipe e define o que significa um trabalho estar verdadeiramente "concluído". Se um requisito não atende a todos os critérios da DoD, ele não pode ser apresentado na Sprint Review nem considerado para entrega. Um requisito é considerado "Done" quando atende aos seguintes critérios:

Critérios de Aceite Atendidos: Todos os critérios de aceitação definidos na história de usuário foram completamente satisfeitos e validados.
Código Implementado e Integrado: O desenvolvimento da funcionalidade foi concluído e o código foi integrado à branch main do projeto.
Aderente aos Padrões de Codificação:O código segue os padrões de qualidade e consistência da equipe, o que significa que ele adere ao guia de estilo da linguagem, utiliza nomes de constantes e variáveis em português e não contém código 'morto' (linhas comentadas) antes do merge.
Revisão de Código Realizada: O código foi revisado e aprovado por, no mínimo, outro membro da equipe de desenvolvimento.
Testes Realizados e Aprovados: A funcionalidade passou com sucesso pela suíte de testes de regressão automatizados (unidade e integração), e também foi validada manualmente para garantir que a funcionalidade opera corretamente, não introduz problemas e atende aos requisitos do projeto.
Validação da Qualidade (QA): A funcionalidade foi testada e aprovada pela equipe de QA, que verificou a conformidade com todos os requisitos, incluindo os de segurança.
Performance Preservada: A nova funcionalidade atende aos requisitos de desempenho, mantendo o tempo de resposta abaixo de 3 segundos.
Documentação Atualizada: A documentação técnica (API/Swagger, README) foram revisadas e atualizadas para refletir as novas implementações.