Você vai ler sobre:
Você sabe como a definição de DOR e DOD pode ajudar no sucesso da entrega do seu produto? No desenvolvimento de um produto é importante administrar as expectativas dos envolvidos. Um dos grandes desafios é manter a área de negócio, a qual dentro do Framework Scrum é representada pelo Product Owner (PO) alinhada com os membros do time de desenvolvimento. Esse alinhamento mantém a transparência, um dos pilares do Scrum, que por definição prevê que todo o trabalho deve ser claramente definido e conhecido por todas as partes envolvidas.
Neste artigo, será apresentado o funcionamento de dois conceitos, que utilizados da forma correta, ajudarão no planejamento e no sucesso da entrega do desenvolvimento dos itens do seu backlog do produto.
Entendendo o conceito de DOR
É muito comum que o Product Owner tenha dificuldades em saber quando cada item da sua lista de necessidades está preparado o suficiente para entrar no backlog da Sprint. Para uma maior compreensão é necessário um entendimento entre a área de negócio e a equipe técnica, representada no Scrum como o Time de Desenvolvimento. Se por um lado existe uma dificuldade de compreensão técnica pela área de negócio, por outro existe uma barreira de conhecimento de negócio por parte do time técnico.
Mediante esse cenário, com o intuito de romper esses obstáculos e manter a transparência seguindo a definição do Scrum, surge o refinamento do backlog do produto com o intuito de alinhar todas as partes interessadas. O refinamento ocorre durante o andamento da Sprint e normalmente destina-se 10% do tamanho da Sprint para o refinamento do backlog do produto. Neste evento o time de desenvolvimento entende o propósito dos próximos itens priorizados pelo PO, elenca os desafios técnicos, alinhando as expectativas com a área de negócio.
DOR - Definition of Ready
Para apoiar esse refinamento, surge o primeiro conceito, o DOR (Definition of Ready) que traduzindo para o português, significa a definição de preparado. O DOR, trata-se de uma listagem de requisitos que determinada história ou tarefa necessita para que possa estar apta a entrar no backlog da Sprint. Normalmente essa lista fica vinculada a tarefa e cada item é marcado com check se está atendido ou não. A história só deve ser movida para o backlog da Sprint se todos os itens levantados durante o refinamento estiverem marcados, caso contrário a mesma ainda não está preparada para entrar na esteira de produção.
Exemplificando uma história, na qual necessitará consultar outra aplicação, podemos citar na lista do DOR alguns itens como:
- Histórias de usuário devem ser escritas no padrão BDD
- O(s) critério(s) de aceite estão claros
- Serviço de Integração disponível para consulta
- Design pronto
- HTML pronto
- Dados para teste
- Acesso GET/POST a aplicação
Entendendo o conceito de DOD
Na primeira parte deste artigo, elencamos o quanto a definição de DOR é importante, quando é aplicada e como ela pode ajudar no refinamento de cada item backlog. Até o momento falamos de um item em sua fase planejamento, agora precisamos entender o segundo conceito, e como ele pode ajudar a definir o seu status de pronto.
DOD - Definition of Done
O conceito de DOD (Definition of Done), ou traduzindo definição de feito, ajuda o time a elencar os pontos necessários para que uma determinada tarefa seja classificada como concluída. Não existe uma definição de pronto oficial que deve ser seguida por todas as organizações e equipes de desenvolvimento, até porque, cada produto tem sua complexidade. Cada equipe deve desenvolver sua definição de pronto, levando sempre em consideração o desafio do produto, as ferramentas tecnológicas que estão sendo utilizadas, as necessidades dos usuários e etc.
Essa definição é gerada antes de iniciar o desenvolvimento do produto, normalmente antes mesmo da primeira Sprint. Sua evolução ocorre no caminhar da vida útil do produto e quanto mais maduro o time, mais rigorosa a definição de concluído, o que gera como resultado o aumento na qualidade da entrega do sprint. Caso seja necessário rever a definição de pronto, o momento mais adequado é no evento de retrospectiva da Sprint.
Assim como no DOR, pode-se aplicar a mesma estratégia montando uma lista que será verificado no momento de desenvolvimento da tarefa. A tarefa só pode ser considerada pronta se atender os itens anexados ao DOD.
Seguindo o exemplo citado, podemos especificar como DOD os seguintes pontos:
- Teste de caixa preta executado
- Tratar os principais retornos negativos da API (Application Programming Interface)
- Código revisado por outro membro do time
- Funcionalidades atende aos critérios de aceite
Como vimos, embora possa haver certa confusão, conseguir entender os conceitos de DOR E DOD é peça chave no desenvolvimento ágil de produtos. É importante ressaltar que esses conceitos podem até variar de acordo com cada projeto, mas para o sucesso da sua entrega é fundamental que toda a equipe esteja por dentro desses conceitos.
A Lumis é uma empresa especializada em soluções de Experiência Digital, oferecendo o LumisXP como sua plataforma principal de Digital Experience Platform (DXP). O LumisXP permite às organizações criar, gerenciar e otimizar experiências digitais de forma integrada e eficiente. Com funcionalidades avançadas de gerenciamento de conteúdo, personalização e entrega multicanal, o LumisXP capacita as empresas a oferecerem experiências personalizadas e consistentes em todos os pontos de contato com seus clientes. Além disso, a plataforma é robusta e escalável, adaptando-se às necessidades específicas de cada negócio e ajudando a impulsionar o crescimento e a inovação digital. Conheça o LumisXP.
Sobre o autor
