User Story - Definition of Ready e Definition of Done

Desenvolver software é uma atividade complexa, repleta de riscos e normalmente realizada por equipes que atuam em um fluxo de trabalho. Uma boa gestão sobre esse fluxo, pode gerar uma série de benefícios que impactam positivamente nas entregas realizadas para os usuários.

Em equipes ágeis que inspecionam e adaptam os seus processos de maneira recorrente, existem dois tipos de acordo que auxiliam na transparência do fluxo, reduzindo assim a necessidade de processos pesados e burocráticos, são eles o Definition of Ready (DoR) e o Definition of Done (DoD).

Compartilho aqui um pouco sobre esses dois e acordos e algumas dicas para ajudar a construí-los.

Fluxo de desenvolvimento

Um fato interessante é que tanto o DoR como o DoD podem ser utilizados com o Scrum ou com o Kanban. É comum que eles tenham forte peso em duas etapas no fluxo, o DoR quando a equipe inicia uma demanda e o DoD quando a demanda está preste a ser concluída.

Com o uso do Scrum, o DoR auxilia a equipe a saber quais demandas podem ser puxadas para o Sprint Backlog. Já o DoD quando a demanda pode ser considerada como pronta.

Já com o Kanban não existe uma cerimônia para isso, depende das políticas de limite de WIP definido pela equipe. Nesse caso, é bem importante que as demandas mais ao topo do backlog estejam de acordo com o DoR. O DoD acaba também não dependendo de cerimônias, tendo em vista que o fluxo de entrega é contínuo.

Como faço para criar esses acordos?

É muito importante que esses acordos sejam criados em conjunto com a equipe. Inicialmente não precisam ser muito grandes, pois a ideia justamente é ter leveza no processo. Comece com uma versão simples, com os critérios que a sua equipe já considera importante no momento. Faça isso pareado e compartilhe com os demais membros da equipe para obter feedbacks :-).

E se tiverem mudanças? Isso é comum, faz parte. Mudanças nesses acordos sempre são bem vindas, não hesite incluir, remover ou editar alguns itens. Uma dica importante, como esse acordo é da equipe, é importante envolver as outras pessoas nas alterações. Essas mudanças acontecem normalmente como resultado de brainstorming, retrospectivas e reuniões de refinamento de backlog.

Um exemplo de cada

Abaixo dois exemplos, um para o DoR e o outro para o DoD. Como pode ser visto, são acordos leves escrito de uma forma simples.

Definition of Ready:

• Está claro qual é o propósito da história;
• Foi realizado uma reunião de refinamento com ao menos 2 membros da equipe;
• Os critérios de aceitação estão escritos no card;
• A história possui uma estimativa (P, M ou G);
• Está descrito na história quais são suas dependências.

Definition of Done:

• O código está coberto com testes automatizados;
• Revisão de código foi realizado por um par;
• Teste de aceitação foi realizado por um par;
• Informações reutilizáveis foram documentadas;
• A última mensagem no ticket detalha a solução.

Conclusão

É comum que o fluxo de desenvolvimento seja repleto de incertezas e riscos, buscar alternativas que possam mitigá-los sempre é válido. Isso se torna mais importante quando existe uma equipe com várias pessoas trabalhando neste fluxo. Ter acordos que tornem transparente a forma de trabalho da equipe traz muitos benefícios. Das experiências que tive trabalhando com times ágeis, os principais benefícios foram:

• Redução de conflitos em virtude de divergência no entendimento dos acordos da equipe;
• Aumento de transparência do esforço necessário para trabalhar em uma demanda;
• Histórias de usuário não tão longas, porém com os detalhes necessários para iniciá-las;
• Ações e melhorias no processo passam a ser mais valorizadas;
• Onboarding de novos membros da equipe, pois esses critérios já serão utilizados como um mecanismo para ententer como a equipe trabalha.