DoD e DoR, você sabe a diferença?

Definition of Ready (DoR)

O DoR é um conjunto de critérios definidos pelo time, que detalha as condições que uma story precisa atingir/conter para que possa ser trabalhada pelo time. Basicamente, é também um critério de entrada no backlog da sprint. 

Normalmente, um DoR conterá: 

• Definição de valor está clara e é compreendida pelo time todo 
• Critério de aceite está definido 
• As dependências foram identificadas 
• Se há requisitos não funcionais como: Performance, Segurança, Escalabilidade 
• A estimativa de esforço em alto nível (ex. T-Shirt sizes) 

Você pode criar um modelo de DoR seguindo o conceito de INVEST, por exemplo. 

• https://www.visual-paradigm.com/scrum/3c-and-invest-guide/  

A responsabilidade pelo detalhamento das stories para atendimento do DoR é primariamente do Product Owner (PO).

O benefício do DoR para seu time é ajudá-lo a ter as informações e expectativas relevantes no momento em que a story será desenvolvida, diminuindo as incertezas e os problemas de comunicação e entendimento.  

Importante é não tornar o DoR um “phase-gate” em seu projeto. Ou seja, as stories não precisam estar 100% definidas mas o time precisa estar confortável com um nível de detalhamento “suficiente”. Pode haver, inclusive, desenvolvimento de dependências em paralelo. 

Definition of Done (DoD)

Assim como DoR, o DoD também é definido pelo time. Ele ajudará a equipe a identificar os critérios que uma task/story precisa atender para que seja classificada como concluída (“Done”). Como cada equipe tem produto, maturidade e cultura diferenciada, não há uma definição padronizada. 

Se você já trabalhou com desenvolvimento de software ou projetos de TI, já deve ter escutado as frases: 

• “Está pronto. Só falta testar.” 
• “Está pronto. Só falta fazer o deploy pro ambiente de testes.” 
• “Está pronto. Só falta fazer a carga de dados.” 

O DoD é desenvolvido para evitar este tipo de confusão dentro da equipe e evitar os ruídos de comunicação e os problemas de expectativas causados pela má comunicação do time com as partes interessadas, gestores, clientes, etc. 

Idealmente, o Definition of Done é desenvolvido no início do projeto, evoluindo conforme as lições aprendidas e necessidades do time. Pode ser um checklist contendo por exemplo: 

• Código está disponível no ambiente de testes correto; 
• Integrações com outros componentes (ex. APIs) foi testado e funciona; 
• Dados estão disponíveis para testes e as cargas foram realizadas com sucesso; 
• Código já foi testado pelo QA ou, por peer review; 
• Teste de performance / segurança do componente foi realizado e atende aos requisitos estabelecidos; 
• Todos as atividades pretendidas foram concluídas. 

Definition of Ready, Definition of Done e Agilidade 

Como podem perceber, DoR e DoD trazem transparência ao processo de desenvolvimento. Com o uso apropriado destas ferramentas, times podem trabalhar com maior eficiência e estarem 100% focados na entrega de valor para seu projeto. 

Precisa de ajuda?

Escolher uma consultoria para seu projeto ágil é um desafio! Na Macher Tecnologia não trabalhamos com soluções prontas mas customizamos o projeto conforme sua nacessidade, nível de maturidade em gestão de projetos ágeis, seu projeto e a complexidade de sua organização. Entre em contato conosco e fale com um de nossos especialistas!