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. Edison Santos 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.   Também já lidei com implementação estilo checklist voltadas para Casos de Uso, onde eram estabelecidos os critérios de pronto incorporados ou não ao documento. Nesse caso os critérios envolvidos foram definidos por categorias relacionas a solução, que se tratava do desenvolvimento de sistemas. Desta forma compreender as definições de interface, lógica de negócio, banco de dados, e interações com outras partes do sistema eram pertinentes para que as informações de pronto estivessem disponíveis.Até mesmo na Engenharia de Dados é possível estabelecer um D.O.R. Nas experiências nesta frente implementei uma forma simplificada de matriz de necessidade, caracterizada por um checklist em Excel. Dado que os KPIs padrão foram estabelecidos, validar as informações sobre a disponibilidade da fonte de dados, a frequência de atualização e a granularidade dos dados se mostrou suficiente para comunicar, logo que o checklist fosse preenchido quais KPIs poderiam ser implementados e quais tinham pendências. 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