Eu vejo diariamente muitos projetos enfrentando sempre os mesmos problemas e, como consequência, muito estresse e equipes desmotivadas. Uma técnica bem simples, porém muito eficaz, consegue evitar muita dor de cabeça. O Definition of Ready (DoR)!
Mas que problemas o Definition of Ready poderia evitar, você deve estar se perguntando. O DoR consegue ajudar em certas situações, por exemplo:
- Seu time tem bloqueios na etapa de desenvolvimento constantemente?
- Parece que nunca conseguem lançar nada em produção, pois sempre há um bloqueio ou algo novo que aparece?
- Vocês estão sempre errando feio nos prazos de entrega e a meta da sprint nunca é atingida?
- Muito código em estoque, mas nada em produção, pois dependem de outros projetos?
- Time desmotivado, pois se sente culpado por não realizar as entregas no prazo estabelecido?
E aí, quer conhecer mais sobre Definition of Ready (DoR)? Então continue lendo!
Vamos lá, o que é Definition of Ready (DoR)?
Definition of Ready (DoR), que traduzindo para o português significa a “Definição de preparado”, é uma técnica de qualidade e gestão de risco que apoia a entrada de uma história para o delivery. Basicamente são pré-requisitos de um backlog, para que seja considerado apto para iniciar o desenvolvimento.
O Definition of Ready (DoR) garante a qualidade de uma história, épico, tarefa, sprint ou produto para que o trabalho possa ser iniciado. Você vai notar que irei utilizar DoR apenas para o conceito de história, mas o conceito é o mesmo para épico, tarefa, sprint ou DoR de um produto.
O uso do DoR não é restrito ao framework Scrum, ele pode ser utilizado também no Kanban e outras metodologias ágeis.
Observação. Talvez você já tenha ouvido falar também sobre Definition of Done (DoD). DoR e DoD tem objetivos diferentes, DoD são os critérios para considerar uma história como concluída. Já DoR, como eu já descrevi, são os critérios necessários para que uma história possa ser iniciada. Porém, nesse artigo iremos falar apenas do Definition of Ready (DoR).
O que é importante estar no DoR?
Para te ajudar a identificar o que é importante estar no DoR, faça as seguintes perguntas:
- O que o devTeam precisa ter para iniciar o desenvolvimento?
- O que precisa estar pronto para iniciar o desenvolvimento?
- Quais acessos, ferramentas, documentação e ambientes precisamos possuir para iniciar o desenvolvimento?
- Quais permissões e aprovações precisam ser realizadas para iniciar o desenvolvimento?
- Quais práticas e técnicas precisam ser feitas para iniciar o desenvolvimento?
Exemplos de Definition of Ready (DoR)
A seguir, vamos ver alguns exemplos práticos de critérios de Definition of Ready (DoR).
Exemplo 1: Equipe Front-End – História XYZ
- Protótipo de alta fidelidade pronto e validado com o usuário.
- Protótipo de alta fidelidade pronto e entregue para devs.
- Protótipo de acessibilidade pronto e entregue para devs.
- Todas histórias refinadas pelo time de desenvolvimento.
- Todas histórias estimadas pelo time de desenvolvimento.
- Todas as APIs prontas e validadas pelo time.
Exemplo 2: Produto Open Banking
- As histórias devem estar escritas utilizando o modelo INVEST.
- Todas histórias refinadas.
- Possuir massa para testes.
- APIs dos parceiros prontas e validadas, que iremos utilizar na jornada X.
- Arquitetura desenhada.
- Ambientes de desenvolvimento pronto e devs com acesso.
- Ambiente de homologação pronto.
Caso algum critério não seja cumprido no DoR, posso iniciar o desenvolvimento?
Depois de todos os critérios serem descritos, é muito importante que todos sejam cumpridos, pois os itens que foram levantados são critérios importantes para se iniciar o desenvolvimento. Caso esses critérios não sejam cumpridos ou sejam deixados de lado, pode haver bloqueios e dificuldades na etapa do desenvolvimento. Dessa forma haverá retrabalho, prazos atrasados e estresse para todo time.
Vamos imaginar a seguinte situação utilizando o Exemplo 2. O critério APIs dos parceiros prontas e validadas, não está pronto e muito menos validado, é o último critério que resta para iniciar a sprint, porém há uma pressão externa para que o desenvolvimento seja iniciado.
Caso a história seja iniciada, todo o desenvolvimento e testes será feito e baseado em mocks e não nas apis, correto? Tudo isso até que as APIs estejam prontas. Dessa forma, em algum momento haverá um retrabalho e até impactar o prazo e objetivo da sprint.
Sendo bem objetivo na resposta da pergunta acima. Caso algum critério não seja cumprido no DoR, posso iniciar o desenvolvimento? Poder pode, mas o risco é bem alto.
Digamos que você irá iniciar o desenvolvimento utilizando mocks. É muito importante mapear os riscos dessa decisão e alinhar muito bem as expectativas com todos os stakeholders do projeto. Acredito que você já tenha ouvido algo parecido com isso: “Pode iniciar o desenvolvimento, as APIs estarão prontas quando você precisar”. Na minha experiência elas nunca estão prontas quando o time precisa. Porém, sempre vale avaliar o contexto para não acabar engessando o processo.
Responsabilidades no Definition of Ready
Já deu para perceber que o Definition of Ready (DoR) pode ajudar muito a produtividade do time, mas a quem certas responsabilidades são atribuídas? É o que vamos ver a seguir:
Quem é responsável por definir o DoR?
A responsabilidade de definir o DoR é de todas as pessoas no time. É muito importante envolver todas as partes, pois assim podemos mapear os critérios de uma forma sistêmica, trazendo critério de documentação, testes, arquitetura, negócio e desenvolvimento.
Porém, depois disso feito, poucas mudanças devem ocorrer, aí basta seguir o DoR.
Quem é responsável por tornar um critério Ready?
A responsabilidade por tornar um critério ready é das lideranças do projeto, por exemplo, Team Lead, Scrum Master, Tech Lead e Product Owner.
Obviamente o devTeam pode ser envolvido para ajudar a tornar os critérios Ready, mas as lideranças têm a responsabilidade de garantir e mapear os riscos, caso algum dos critérios não esteja Ready.
Benefícios do DoR
Alguns dos benefícios de um DoR bem feito e cumprido por toda a equipe eu já citei ao longo do texto. Por exemplo, evitar bloqueios na etapa de desenvolvimento, cumprimento dos prazos estabelecidos, pois não teremos nenhuma surpresa, time motivado por enxergar seu código sendo entregue na data correta.
Além disso, ao longo do tempo haverá uma queda do próprio Lead Time e do time-to-market. Pois agora o desenvolvimento é contínuo, com pouquíssimas interrupções e pessoas motivadas por enxergarem o progresso de suas entregas.
Desafios do DoR
Definition of Ready pode ser uma ferramenta muito útil, porém ela pode se tornar uma muleta para seu time e gerar uma burocracia desnecessária ao invés de agilidade.
A equipe pode inserir critérios do DoR que engessam o processo. Por exemplo, APIs do parceiro disponibilizada pelo Swagger, porém o parceiro nunca documentou suas APIs pelo Swagger ou História documentada no padrão XYZ, porém a história é muito simples, talvez a documentação dê mais trabalho que o próprio desenvolvimento.
Outro desafio comum é a adesão do DoR. Não é fazendo uma lista de itens que os problemas irão se resolver magicamente. É muito importante que o time compreenda a importância e como isso será benéfico para o seu dia a dia, até que a técnica vire parte da cultura do grupo.
Com algumas repetições, o hábito de antecipar possíveis riscos será natural e muitos irão acabar sendo identificados na própria Inception. Comece pequeno, colete os feedbacks e vá evoluindo. ?
Definition of Ready (DoR): uma boa gestão de requisitos e seu projeto vai fluir melhor
Espero que tenha ficado claro em como montar os critérios do Definition of Ready (DoR) e como ele pode ajudar, para que uma entrega possa ser realizada com sucesso. Quem não quer entregas no prazo, clientes com satisfação alta e time motivado, não é mesmo?
Mas agora eu quero ouvir você! Ficou com alguma dúvida sobre Definition of Ready (DoR)? Já adota o DoR no seu time? Conta para a gente nos comentários!
