Conceitos
O Definition of Ready (D.O.R) ou Definição de Pronto é um conceito utilizado normalmente em conjunto com metodologias ágeis para garantir que as informações necessárias estejam disponíveis antes que uma demanda tenha a sua construção iniciada.
Quando me refiro a demanda, falando de ágil, normalmente são User Story ou Task, mas pode se tratar de qualquer outra forma de documentar uma solicitação. Também utilizo construção, pois não somente desenvolvimento de software utiliza de gestão ágil.
Mas o ponto central está nas “informações mínimas necessárias” essa é a essência do D.O.R. Podemos fazer uma analogia que seria como tentar enviar uma encomenda sem indicar ao entregador o endereço da entrega (país, estado, cidade, rua, número do imóvel). Trazendo para algo mais moderno (2025), seria o mesmo que tentar mandar uma mensagem de Whatsapp sem saber o número telefônico da pessoa.
Então, de forma geral a preocupação do D.O.R é garantir no mínimo os dados mais básicos para que uma determinada tarefa seja realizada com sucesso. Contudo, também é possível usar esse conceito de forma a apresentar todas as informações necessárias da demanda, como o objetivo, o contexto, impactos entre outras informações que irão favorecer a melhor construção da solução. Visto que falar sobre o problema, munir de informação proporciona uma visão ampla e maior capacidade de decisão.
É possível encontrar outros conceitos relacionados com o D.O.R como: critérios INVEST [1]; análise e desmembramento de user story [2], similar à identificação e refatoração de code smells; ou na organização de fluxos de trabalho [3].
Use o + abaixo e veja os aspectos relacionados a impactos, aplicabilidade e cases.
Impactos
Quanto aos impactos da utilização do D.O.R são positivos, na maioria das situações que compreendo. Na implementação desse conceito acontecem alguns eventos como:
- • levantamento das informações chaves que constituem a demanda;
- • reunião dos envolvidos para estabelecer a definição de pronto;
- • criação de guia, treinamentos, ou incorporação dos itens do D.O.R ao respectivos templates;
- • revisão para garantia da consistência, mudança ou melhoria contínua;
Em relação aos resultados obtidos:
- • melhoria da comunicação entre os envolvidos (devido à compreensão de informações em comuns e como estas devem ser tratadas);
- • redução de conflitos (sim, conflitos, pois, entender as informações com a mesma compreensão favorece que todos tenham o mesmo foco para o tema em questão, evitando ruídos de comunicação);
- • redução dos ciclos de revisão de documentação/solicitação;
- • aumento de produtividade;
- • redução de retrabalho;
Talvez a única questão a ponderar é que o D.O.R pode acrescentar algum esforço a mais na documentação/solicitação visto a sua necessidade de atender a parâmetros mínimos.
Contudo, os fatores citados em sua maioria reduzem uma grande quantidade de desentendimentos, sobrando tempo que proporciona aos envolvidos mais foco no aprendizado contínuo e adaptação rápida as mudanças.
Aplicabilidade
O D.O.R deveria ser aplicado desde a implantação da governança voltada para construção ou sustentação de soluções. Porém, nem sempre é assim. Contudo não há impedimento para implantações tardias. Só vale lembrar que essa última lidará com a mudança de cultura estabelecidas, o que é um desafio a mais, porém nada impossível.
Tentarei apresentar algumas formas de implementação que eu vivenciei, e antes de mais nada, nem sempre o contexto, contrato e definições são puristas. Tenho essa observação visto que nem tudo projeto é puramente ágil, nem toda user story pode contemplar todas as nuances necessárias para a sua construção, então, citarei o melhor do que já vi em alguns cenários.
Primeiro, em um olhar mais próximo do Scrum e das user story já pode ser aplicado os critérios INVEST que seguem como um guia da qualidade da user story:
- Independente. Assim é história é suficiente por si só para a sua construção, existia certa unicidade, e autossuficiência na história.
- Negociável. Tanto mais generalista no backlog, porém ser bem formulada quanto ao seu propósito antes de seguir para construção.
- Valiosa. Entregar valor aos envolvidos.
- Estimável. Ser mensurável, possível de compreender a sua dimensão quanto a tamanho, esforço, etc…
- Sucinta. Ser pequena no que tange o que será construído ou autocontida, gerando apenas um resultado de construção, além de caber no ciclo da entrega (ex.: Sprint, Release).
- Testável. Fazer conhecer o resultado esperado após a construção, que servirá de guia ao que deve ser alcançado com a história.
Então, para gerar um D.O.R eficaz é necessário compreender quais informações são necessárias para quem irá realizar a construção da solicitação. Lembre-se não tem como você receber sua encomenda em casa, se não informar o seu endereço ao entregador, ou então imagina informar a rua, porém sem o número… quantas casas, prédios e condomínios fazem parte a sua rua? Não informar o número da moradia, tornaria possível você receber a sua encomenda!
A definição de pronto também se torna um instrumento para a tomada de decisão, pois, uma vez que se tem visibilidade de quão pronta uma demanda está, é possível definir entre:
- 😠 -> não iniciar a construção por não tem o mínimo necessário;
- 😳 -> iniciar a construção, com algumas definições faltantes, assumindo um risco moderado ou baixo;
- 😉 -> iniciar a construção com os dados necessário para compreensão da demanda.
Cases
CASE 1 - D.O.R em Caso de uso
Aqui vai um case fictício baseado no Appresumos. Vamos considerar o seguinte caso de uso para desenvolver o Login. Nossa ênfase será no item 9. Interface de Usuário, que é uma categoria candidata para um D.O.R baseado em um checklist.
# Caso de Uso: Login no Appresumos
## 1. Nome do Caso de Uso
Login no Appresumos
## 2. Descrição
Este caso de uso descreve o processo pelo qual um usuário realiza login no sistema **Appresumos** para acessar suas funcionalidades, como geração de resumos de PDFs e gerenciamento de arquivos.
[...]
## 5. Fluxo Principal
1. O usuário acessa a página de login do **Appresumos**.
2. O sistema exibe o formulário de login com os campos:
- Nome de usuário.
- Senha.
3. O usuário preenche os campos obrigatórios e clica no botão **"Entrar"**.
4. O usuário pode tentar novamente, caso tenha inserido informações incorretas.
[...]
## 9. Interface de Usuário
- **Campos do Formulário**:
- Nome de usuário (campo de texto).
- Senha (campo de senha).
- **Botões**:
- **Entrar**: Envia as credenciais para validação.
- **Registre-se**: Redireciona para a página de registro.
[...]
|
Validação
|
Status
|
|---|---|
|
O nome dos campos estão definidos?
|
|
|
Os campos obrigatórios foram definidos?
|
|
|
As mensagens para os usuários foram definidas?
|
|
Esse exemplo simplificado de checklist atenderia o conceito do D.O.R.
CASE 2 - D.O.R em User Story
Existem algumas situações aplicáveis do D.O.R em user story é além de fazer a validação utilizando o INVEST, pode adicionar outros elementos como os Teste de Aceitação. Aqui é uma visão holística do processo, em que o T do INVEST precisa garantir que a user story é testável e porque não adicionar outro conceito importante como o teste de aceitação…
Abaixo segue uma tabela possíveis itens de validação e a relação com o conceito. Logo abaixo um template de user story com o teste de aceitação
|
Critério/Conceito
|
Validação
|
Status
|
|---|---|---|
|
INVEST -> N (Negociável)
|
A user story foi refinada?
|
|
|
INVEST -> E (Estimável)
|
A user story foi estimada?
|
|
|
INVEST -> T (Testável)
|
Existe massa de teste disponível?
|
|
|
INVEST -> T (Testável)
|
A user story tem pelo menos 1 critério de aceite?
|
|
User Story: Login no Appresumos
Como usuário do Appresumos
Quero acessar minha conta por meio de login
Para que eu possa visualizar meus resumos e conteúdos personalizados
Critérios de Aceitação (Formato Dado, Quando, Então)
✅ Cenário 1: Login bem-sucedido
Dado que o usuário tem um cadastro válido e está na tela de login
Quando ele insere suas credenciais corretas e confirma
Então ele deve ser autenticado e redirecionado para a página inicial
✅ Cenário 2: Login falha por senha incorreta
Dado que o usuário está na tela de login
Quando ele insere um email válido, mas uma senha incorreta
Então ele deve ver uma mensagem de erro informando que a senha está errada
CASE 3 - D.O.R em Solicitações
Também é possível pensar no D.O.R incorporado ao template (documento, tela de solicitação, etc…). Desta forma, o que se espera como informação já está sendo indicada no template.
O exemplo que veremos sugere um arquivo de solicitação de demanda de construção. Para que o seu preenchimento será facilitado algumas guias de orientação ou formatos como tabelas são adicionado direto no template para facilitar o preenchimento. A segmentação por em seções também ajudará
Template de Solicitação de Demanda
Solicitação
<Deve indicar a necessidade, o produto relacionado e o objetivo. Ex.: (necessidade) Solicito o desenvolvimento da funcionalidade de cadastro de usuários (relacionado) para o Appresumos (objetivo) para que os próprios usuários possam se cadastrar no app.>
Seção 1: Campos
<Criar uma lista indicando o nome do campo da tela, o tipo de dado e a obrigatoriedade do campo. Os itens devem seguir esse formato: • [nome do campo] [tipo] [obrigatório: S ou N]>
Seção 2: Perfis de acesso
<Preencha a tabela abaixo. No campo Elemento considerar a tela, campo, pasta ou outros itens do sistema.>
|
Elemento |
Perfil |
Permissão |
|
|
|
|
|
|
|
|
Indicações
[1] Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo – Jeff Sutherland
[2] Agile Estimating and Planning – Mike Cohn
[3] Kanban: Mudança Evolucionária de Sucesso para Seu Negócio de Tecnologia – David J. Anderson
Esse post contemplou de forma breve o conceito de Definition of Ready, ou Definição de Pronto que estabelece as informações necessárias para uma demanda ser construída.
A implantação do D.O.R ajuda a evitar os desentendimentos entre os envolvidos proporcionando entre outros fatores, redução de retrabalho e aumento de produtividade. Além disso, a sua aplicabilidade é flexível, por se tratar de um conceito e desta forma se bem adaptativo.
Por fim, tivemos dois cases entre modelos mais tradicional de desenvolvimento de software e outro caso mais voltado para o ágil com user story.
Bom agora é com você. Já conhecia o D.O.R ? Se não conhecia, curtiu o conceito, é aplicável a sua realidade?
Compartilhe as suas impressões ou experiências!
