DoR E DoD: Dois conceitos que podem revolucionar a forma como sua empresa planeja e realiza entregas

Muitas equipes enfrentam diariamente problemas em seus projetos, gerando muito estresse para os profissionais e resultando em equipes desmotivadas.

Esse cenário é bastante comum, mas que pode ser amenizado e até mesmo superado, através do uso de técnicas simples e muito eficazes. Evitando assim, muita dor de cabeça.

Neste artigo, vamos apresentar os conceitos de Definition of Ready (DoR) e Definition of Done (DoD), como cada um funciona, seus benefícios e tudo o que você precisa saber para garantir um bom planejamento e sucesso nas entregas de um projeto.

DoR e DoD, apesar de possuírem conceitos semelhantes, tem objetivos diferentes. DoR, diz respeito, aos critérios necessários para que uma história possa ser iniciada. Já o conceito de DoD pode ser entendido, como uma lista de critérios a serem atingidos para que uma história possa ser considerada concluída.

Abaixo vamos explicar cada um desses conceitos, assim como, seus benefícios e desafios.

Vem com a gente!

Definition Of Ready (DoR)

Definition of Ready (DoR), em tradução livre para o português significa “Definição de preparado”, que consiste em uma técnica de qualidade e gestão de risco.

O DoR é composto por um conjunto de critérios, elaborados pelo time, visando detalhar as condições que uma story ou tarefa, necessita ter ou atingir, para que ela possa ser trabalhada pelo time.

É comum também, que DoR seja utilizado, como um critério de entrada no backlog de uma sprint. Normalmente, essa listagem de critérios fica vinculada a tarefa, onde cada item é marcado com “check” se for atendido.

Nesse contexto, a história só deverá ser movida para o backlog da Sprint se todos os itens listados estiverem marcados como cumpridos, caso contrário, ela ainda não está suficientemente preparada para ingressar na esteira de produção.

Através do uso da técnica de DoR, é possível garantir a qualidade de uma história, épico, tarefa, sprint ou produto, e assim, iniciar o trabalho.

Um ponto importante a ser destacado é, que apesar do DoR estar amplamente ligado ao framework Scrum, ele não é restrito a nenhum framework específico e pode ser utilizado por diversas outras metodologias ágeis.

De forma resumida, o DoR consiste nos pré-requisitos necessários de itens de um backlog, para que ele seja considerado apto para ter o desenvolvimento inciado.

5 Problemas Que o Uso do DoR Pode Ajudar a Evitar:

Em quais situações o uso DoR é indicado e que problemas ele pode ajudar a evitar? Para responder essa pergunta, separamos 5 situações-problema. São elas:

1. Times que frequentemente, possuem bloqueios na etapa de desenvolvimento;
2. Sensação constante que o projeto não anda, pois, nunca conseguem lançar nada em produção, por estar sempre lidando com um bloqueio ou com algo novo que apareceu;
3. Dificuldade constante em atingir a meta do sprint, e em cumprir os prazos de entrega. Situação que gera desgaste e desmotivação em todo time;
4. Inúmeras linhas de código já escritas e armazenadas, aguardando o início da produção que nunca acontece;
5. Time totalmente desmotivado, pois se sente frustrado diante do trabalho realizado e culpado por não conseguir cumprir com os prazos e entregas.

Componentes do DoR

Você deve estar se perguntando: mas, afinal…Como eu sei o que deve conter no DoR?

Para ajudar a identificar o que é importante, vamos realizar uma sequência de 5 questionamentos, que vão nos ajudar a encontrar uma resposta juntos. Vamos lá!

Para identificar o que é importante estar no DoR, responda as seguintes questões:

1. O que o time de desenvolvimento precisa ter para iniciar o trabalho?
2. O que já precisa estar pronto para dar início ao processo de desenvolvimento?
3. Quais documentos, acessos, ferramentas, e ambientes o projeto e os profissionais precisam ter para iniciar o desenvolvimento?
4. Quais permissões e aprovações são necessárias para iniciar o desenvolvimento?
5. Quais práticas e técnicas precisam ser realizadas para iniciar o desenvolvimento?

A partir das perguntas listadas acima, foi possível perceber que existem componentes que são muito importantes para o sucesso dessa técnica.

Normalmente, um DoR irá conter:

• Uma definição de valor nítida e totalmente compreendida por todos os profissionais do time;
• Critérios de aceite definidos e claros;
• Identificação das dependências;
• Identificação de requisitos não funcionais, tais como: Performance, Segurança e Escalabilidade;
• Estimativa de esforços em alto nível.

Outro ponto importante de ser destacado, é que apesar dos critérios parecerem complexos e difíceis de serem alcançados, as stories não precisam estar 100% definidas. O mais importante nesse contexto, é que o time esteja confortável com os critérios estabelecidos, e que a story possua um nível de detalhamento considerado suficiente pelo time. Sendo possível, inclusive, que os profissionais trabalhem no desenvolvimento de dependências em paralelo.

Caso algum critério não seja cumprido, é possível iniciar o desenvolvimento?

Após a descrição de todos os critérios, é muito importante que todos eles sejam cumpridos, pois, os itens que foram levantados e listados, são critérios importantes para que o processo de desenvolvimento seja iniciado.

Caso esses critérios não possam ser cumpridos ou sejam ignorados, poderão gerar bloqueios e dificuldades na etapa do desenvolvimento. Resultando em retrabalho, não cumprimento de prazos e uma alta carga de estresse para todos os profissionais do time.

Dessa forma, é recomendado que os riscos, da decisão de avançar no projeto, mesmo sem o cumprimento de todos os critérios, sejam mapeados e muito bem alinhados com as expectativas dos stakeholders. Porém, cada situação deve ser muito bem avaliada para que, ao mesmo tempo, não se criem novos problemas e também, para não permitir os processos se tornem engessados.

EXEMPLOS PRÁTICOS:

Abaixo, iremos apresentar 2 exemplos práticos da utilização do DoR:

Exemplo 1: 

Contexto: Equipe de Front-End

História: ABC

Critérios:

• Protótipo de alta fidelidade finalizado e validado com o usuário;
• Protótipo de alta fidelidade concluído e entregue ao time de desenvolvimento;
• Protótipo de acessibilidade pronto e entregue para os desenvolvedores;
• Todas as histórias passaram pelo processo de refinamento do time de desenvolvimento;
• Todas as histórias estimadas pelo time de desenvolvimento;
• Todas as APIs prontas e validadas pelo time.

Exemplo 2:

Contexto: Desenvolvimento de Produto

Critérios:

• Histórias já escritas;
• Refinamento de todas as histórias pelo time;
• Conteúdo suficiente para testes;
• APIs dos parceiros, concluídas e já validadas;
• Arquitetura desenvolvida e desenhada;
• Ambientes de desenvolvimento pronto e com acesso para os profissionais de desenvolvimento;
• Ambiente de homologação concluído e disponível para uso.

Responsabilidades no DoR

Quem é responsável por definir o DoR?

A responsabilidade pela definição do DoR é de todos os profissionais do time. Pois, é muito importante que todas as partes estejam envolvidas e alinhadas para assim, conseguirem mapear os critérios de forma organizada e sistemática. Apresentando critérios de documentação, testes, arquitetura, negócio e desenvolvimento.

Porém, as lideranças possuem a responsabilidade de garantir e mapear os riscos, caso algum dos critérios não esteja preparado. Dessa forma, a responsabilidade pelo detalhamento das stories visando o atendimento do DoR, é primordialmente do Product Owner (PO), mas, em alguns contextos, a função também pode ser exercida por outras lideranças do projeto, como: Team Lead, Scrum Master, Tech Lead.

Benefícios do DoR

O DoR pode trazer muitos benefícios para seu time, através dele, é possível mapear as informações e expectativas relevantes para o projeto, e diminuir consideravelmente as incertezas e os problemas de comunicação e compreensão do que está sendo levantado.

Além disso, um DoR realizado da forma correta e cumprido por toda a equipe pode trazer os seguintes benefícios:

• Evitar bloqueios na etapa de desenvolvimento;
• Facilitar o cumprimento dos prazos estabelecidos;
• O projeto poderá ter desenvolvimento é contínuo, ou com pouquíssimas interrupções;
• Um ambiente profissional mais motivado, pois, os profissionais envolvidos conseguem enxergar as etapas do processo e o progresso de suas entregas.

Desafios do DoR

O Definition of Ready pode ser uma ferramenta muito útil, porém, ela não pode se tornar uma muleta para o time, pois assim, estará gerando processos burocráticos desnecessários, ao invés de agilidade.

Um time sem compreensão do conceito de DoR pode acabar inserindo critérios que engessam o processo e atrapalham o andamento do projeto.

Outro desafio bastante comum nos times, está relacionado à adesão do DoR. Tudo que é novo tende a gerar desconfiança e se não compreendido de forma correta, pode levar muitos profissionais a acreditarem que ao criar uma lista de itens, os problemas irão se resolver automaticamente. Dessa forma, é fundamental, que o time compreenda a importância dessa técnica e perceba como ela pode ser benéfica para o seu trabalho, até que a técnica seja incorporada e faça parte da cultura do grupo.

Com algumas repetições dessa técnica, o hábito de antecipar possíveis riscos acabará se tornando natural e muitos problemas poderão ser identificados na própria Inception.

Definition Of Done (DoD)

Definition of Done (DoD), em tradução livre para o português, significa: “definição de feito”. E se refere a um conceito que auxilia os times a realizarem o levantamento dos pontos necessários, para que uma determinada tarefa possa ser considerada pronta ou concluída.

Nesse sentido, não existe uma definição única e oficial para “pronto”. E que possa ser seguida por todas as empresas e equipes. Isso porque, cada projeto e cada produto tem suas próprias características e complexidades.

Dessa forma, cada equipe deve buscar desenvolver sua própria definição de “pronto”, considerando sempre, os desafios do produto, as ferramentas disponíveis, as necessidades dos usuários e outros elementos que possam ser importantes para o projeto.

Normalmente, as definições da DoD são geradas antes de iniciar o desenvolvimento do produto, e até mesmo, antes da primeira Sprint. Sendo bastante comum, que elas evoluam no decorrer do projeto e se tornem mais rigorosas, conforme o time vai se tornando mais experiente e mais maduro e resultando no aumento da qualidade das entregas.

Benefícios e Desafios da DoD

Uma dúvida que assombra os pensamentos de muitos Product Owners(PO), é saber quando cada item da sua lista de necessidades está suficientemente preparado para ingressar no backlog da Sprint. Pois, é bastante comum nesse processo, que existam dificuldades de compreensão técnica por parte da área de negócio e uma barreira de conhecimento de negócio por parte do time técnico.

Dessa forma, a DoD foi pensada e desenvolvida para evitar esse tipo de confusão dentro das equipes, e evitar mal-entendidos, ruídos de comunicação e problemas de expectativas causados pela falta de compreensão e má comunicação entre o time e as demais partes interessadas, como: gestores, clientes, etc.

Uma das técnicas utilizadas para superar essas dificuldades e manter a transparência, é o refinamento do backlog, que tem como um de seus objetivos, alinhar todas as partes interessadas.

O refinamento do backlog ocorre durante o andamento da Sprint e normalmente, possui 10% do tamanho da Sprint destinado para esse processo. Durante o refinamento, o time de desenvolvimento poderá compreender o propósito dos próximos itens priorizados pelo PO, elencar os desafios técnicos e alinhar as expectativas com a área de negócios.

Componentes da DoD

Idealmente, a Definition of Done é desenvolvida ainda no início do projeto, e vai evoluindo conforme as necessidades do time. A DoD, assim como no DOR, pode ser aplicada através da criação de uma lista, onde determinada tarefa só poderá ser considerada pronta se atender aos itens anexados a DoD.

Podendo ser uma checklist que contêm, por exemplo:

• Informações sobre a disponibilidade e local de testes do código;
• Confirmação que as integrações com outros componentes foram testadas e estão funcionando;
• Disponibilidade dos Dados para testes e que as cargas foram realizadas com sucesso;
• Notificações de que o código já foi testado pela equipe de qualidade;
• Informações sobre o teste de performance/segurança do componente, se foi realizado e se atende aos requisitos estabelecidos;
• Confirmação de que todas as atividades pretendidas foram concluídas.

Além dos elementos citados acima, uma DoD pode conter os seguintes pontos:

• Teste de caixa preta executado;
• Tratar os principais retornos negativos da Application Programming Interface (API);
• Confirmação de que o código já foi revisado por outro membro do time;
• Confirmação de que todas as funcionalidades atendem aos critérios de aceite.

Organização da DoD:

A Definition of Done (DoD) é uma checagem por onde cada item produzido do backlog do sprint vai passar, para garantir que o item possua o nível que necessário para ser considerado como concluído.

Uma dúvida comum entre os profissionais da área, é se DoD deve ser organizada por Produto, Item de Backlog, Sprint, Time ou Projeto?

A resposta para essa pergunta é bastante ampla, pois, vai depender das preferências e necessidades de cada equipe.

A DoD pode ser organizada das seguintes formas:

• Por Produto: para o Produto A existe uma DoD e para o produto B existe outra DoD.
• Por Item de Backlog: para a User Story X existe uma DoD e para a User Story Y existe outra DoD.
• Por Sprint: para o Sprint 1 existe uma DoD e para o Sprint 2 existe outra DoD.

Ou todas essas variações podem ser utilizadas de forma combinada. Tudo vai depender das características e necessidades de cada projeto.

Mas, caso seja necessário rever a definição de “pronto”, o momento mais indicado para isso, é durante o evento de retrospectiva da Sprint.

Exemplos Práticos de Definition Of Done (DoD)

Abaixo, iremos apresentar 2 exemplos de DoD, em dois contextos diferentes, que podem contribuir para a compreensão do conceito.

Exemplo 1

Contexto: Time Web

Definition of Done:

• Histórias de usuários de interface gráfica devem possuir Testes de Interface do Usuário (UI) automatizados para 100% dos fluxos principais.
• Histórias de usuários de back end com escopo de integração, devem possuir testes de integração automatizados em todos os métodos da API.
• Itens do tipo User Story, Débito Técnico ou Habilitador Técnico devem estar implantados no ambiente de produção.
• Itens considerados “Bugs” devem estar implantados no ambiente de produção e as evidências dos testes devem estar anexadas na ferramenta de Gerenciamento do Ciclo de Vida de Aplicações.
• Itens do tipo Spike devem ser dados como concluído pelo desenvolvedor responsável, que deverá apresentar o resultado na reunião de Review da Sprint.
• Os artefatos de código criados no desenvolvimento devem ter cobertura de 80% de testes unitários.

Exemplo 2:

Contexto: Time de BI e Analytics

Definition of Done:

• Itens do tipo História do Usuário, Débito Técnico ou Habilitador Técnico devem estar implantados no ambiente de produção.
• Itens considerados “Bugs” devem estar implantados no ambiente de produção e as evidências dos testes devem estar anexadas na ferramenta de Gerenciamento do Ciclo de Vida de Aplicações
• Itens do tipo “Spike”, devem ser dados como concluído pelo desenvolvedor responsável, que deverá apresentar o resultado na reunião de Review da Sprint.
• Pacotes de extração, transformação e carga de dados devem atender aos “Requisitos Não Funcionais” de performance estabelecidos pelo time.
• Itens do tipo “Relatório” não devem possuir mais que 8 filtros para seleção de dados.
• Relatórios Gerenciais precisam ter sido validados pelo time, sem a necessidade de envolver a área usuária.
• Relatórios Contábeis devem, obrigatoriamente, ser validados pela área usuária.

Responsabilidades na DoD

Assim como DoR, a DoD também é definida pelo time. Ela irá auxiliar a equipe a identificar os critérios que uma tarefa ou história necessitam atender para que seja classificada como pronta ou concluída.

Como cada equipe possui conhecimento sobre um determinado produto, nível de maturidade e cultura diferenciada, não existe uma definição única.  Sendo importante destacar, que quando falamos de time, nos referimos a participação ativa de todos os profissionais de forma coletiva, sem deixar espaço para pensamentos individualistas, que minam o ambiente e o clima de trabalho.

Garantir que a DoD está funcionando é responsabilidade de todos. Já o PO (Product Owner) possui a responsabilidade de aceitar que apenas itens prontos sejam dados como concluídos pelo time de desenvolvimento.

O time de desenvolvimento possui autonomia para aceitar somente itens “Ready”, porém, possui também a responsabilidade de entregar esses itens como “Done”.

O Scrum Master é responsável por garantir que o Time de Scrum tenha conhecimento do que se trata e de que está aplicando a técnica de forma correta.

Além disso, todo o time é responsável por garantir uma DoD que todos estejam de acordo, e de que ela esteja sendo utilizada corretamente. A cada Sprint a DoD deve revisitada para os ajustes necessários sejam realizados.

DoR E DoD + Agilidade

Como vimos no decorrer desse artigo, compreender os conceitos de DoR e DoD pode ser decisivo para o sucesso de um projeto. Eles são conceitos fundamentais no desenvolvimento ágil. Sendo muito importante, que as equipes compreendam verdadeiramente esses conceitos para que possam garantir o sucesso das entregas.

Através, dos conceitos e técnicas de DoR e DoD é possível trazer maior transparência aos processos de desenvolvimento, e com o uso adequado destas ferramentas, os times poderão trabalhar com maior eficiência e totalmente focados na entrega de valor para seu projeto.

Precisa de ajuda?

Escolher uma consultoria para seu projeto ágil não é uma tarefa fácil. Mas você pode contar com a gente! Aqui na CSP Tecnologia, nós entregamos soluções digitais para desafios reais!

Entre em contato conosco e fale com um de nossos especialistas!