Definition of Ready (DoR) e Definition of Done (DoD)¶
Histórico de Revisão
Data | Versão | Descrição | Autor |
---|---|---|---|
01/11 | 1.0 | Criação do tópico de Backlog do Produto | Maykon Júnio dos Santos Soares |
15/12 | 2.0 | Adição dos artefatos | Pedro Miguel M. de O. dos Santos, Maykon Júnio dos Santos Soares |
Sobre
O DoR é um conjunto de critérios que fala sobre quando um item, independente de ser uma história, tarefa ou épico, está pronto para a equipe de desenvolvimento trabalhar nela ou outro grupo no projeto. O que significa que é um acordo feito entre as partes interessadas – Product Owner, equipe de desenvolvimento, stakeholders, etc. o qual garante clareza, alinhamento e pré-requisitos para o trabalho poder ser feito. Os critérios para realização do DoR serão listados abaixo:
Critério | Descrição |
---|---|
Clareza | A descrição da história deve estar clara e bem compreendida. Deve seguir o formato “Eu como… quero… para…” com detalhes suficientes para a equipe entender o que precisa ser feito. |
Critérios de Aceitação | Os critérios de aceitação devem estar definidos para garantir que os objetivos do requisito sejam entendidos. |
Priorização | O requisito deve ter sido priorizado e ter um valor definido para o negócio, alinhado com os objetivos do projeto. |
Dependência | Todas as dependências do requisito precisam ser identificadas e tratadas para que o desenvolvimento possa prosseguir. |
Validação | O requisito deve ser analisado e aprovado pelo Product Owner para garantir que está alinhado com as necessidades dele. |
Tamanho | O item precisa ter um tamanho adequado para ser completado dentro de uma sprint ou período estipulado. |
Sobre
O Definition of Done (DoD) é usado para garantir a qualidade e a consistência do trabalho entregue pela equipe a partir de uma definição clara e objetiva de critérios que precisam ser atendidos para que um item do backlog (User Story) seja considerado como concluído. A seguir, será apresentado os critérios escolhidos pela equipe para composição do DoD:
Critério | Descrição |
---|---|
Código segue os padrões do projeto | O código deve respeitar os padrões estabelecidos pela equipe, como padronização de tecnologias, bibliotecas, nomenclaturas e comentários de código. |
Código submetido a testes | O código deve passar por testes unitários, de integração e end to end. |
Respeitar os critérios de aceite da User Story | O código deve atender aos critérios de aceitação específicos da User Story. |
Código aprovado pelo QA | O código deve passar por uma revisão de QA e ser aprovado antes da entrega. |
Entrega segue os padrões definidos no protótipo | O código deve estar conforme o design prototipado, ser responsivo e seguir as diretrizes de acessibilidade da WCAG. |
Código da User Story deve estar documentado | A nova funcionalidade deve ser documentada para facilitar manutenção futura. |
Código deve estar livre de bugs | O código deve ser verificado para garantir que não tenha bugs de qualquer severidade. |