Pular para o conteúdo

Diferença entre esses conceitos de Definition of Ready (DOR) e Definition of Done (DOR)

O funcionamento dos conceitos DOR (Definition of Ready) e DOD (Definition of Done), que, quando aplicados corretamente, auxiliarão no planejamento e entrega bem-sucedida do desenvolvimento de seus itens do backlog do produto.

Você sabe como as atribuições de DOR e DOD podem ajudar a entregar seu produto com sucesso?

Ao desenvolver um produto gerenciar as expetativas dos participantes é importante e um dos maiores desafios é manter o dominio do negócio, que no framework Scrum é representado pelo Product Owner (PO) alinhado com os membros da equipe de desenvolvimento.

Esse alinhamento mantém a transparência, um dos pilares do Scrum, que por definição exige que todo trabalho seja claramente definido e conhecido por todas as partes envolvidas.

Aqui, iremos mostrar funcionamento de dois conceitos, que, quando aplicados corretamente, auxiliarão no planejamento e na entrega bem-sucedida do desenvolvimento de seus itens do backlog do produto.


Quem é o Product Owner (Dono do Produto)

Ser um product owner não significa fazer tudo sozinho. O proprietário do produto é um membro da equipe Scrum e trabalha em estreita colaboração com os outros membros, é responsável por realizar o trabalho planejado e precisa do apoio dos outros membros da equipe em relação dependências de recursos ou problemas de tecnologia.

Nesse contexto, ao longo deste artigo pretende-se expressar as dificuldades achadas pela função de Product Owner e quais características levam o responsável por esta função a ter maior engenhosidade ao longo das etapas de desenvolvimento do projeto em interação com todos os membros envolvidos.

Entenda o conceito de Definition of Ready (DOR)

Definition of Ready
Getty Images

Muitas vezes, é difícil para os proprietários de produtos entender se cada item em sua lista de necessidades está preparado o suficiente para entrar no backlog do sprint.

Para um melhor entendimento, é necessário entender o espaço de negócios e a equipe técnica, representada no Scrum como uma equipe de Desenvolvimento.

Se, por um lado, o negócio está com dificuldade de entender o técnico, e por outro, há uma barreira de conhecimento do negócio por parte da equipe técnica.

Nesse cenário, para superar essas barreiras e manter a transparência seguindo a definição do Scrum, os backlogs do produto serão refinados para alinhar todos os stakeholders.

A melhoria ocorre à medida que o Sprint progride e geralmente aloca 10 % do tamanho do Sprint para melhorar o produto excelente.

Nesse caso, a equipe de desenvolvimento entende o intento dos próximos itens priorizados pelo PO, elenca os desafios técnicos, alinhando as expectativas com o setor de negócios.

DOR: Definição De pepaRação (Definition of Ready)

Para apoiar este esclarecimento Surgiu o primeiro conceito DOR, que traduzido para o português significa definição de prontidão. DOR é uma lista de requisitos necessários para que uma história ou tarefa específica seja incluída no backlog em execução.

Normalmente esta lista está associada a tarefas. E cada item será marcado como respondido ou não.

O histórico só deve ser movido para o sprint backlog quando todos os itens coletados durante o processamento forem revisados, caso contrário, ele ainda não estará pronto para entrar na linha de produção.

Um exemplo de uma história que você precisa consultar com outros aplicativos. Podemos citar alguns elementos na lista DOR, por exemplo:

  • As histórias de usuário devem ser criadas de acordo com o padrão.
  • Os critérios de elegibilidade são claros.
  • Serviços integrados de consultoria
  • Preparação HTML
  • Dados de teste
  • Projeto finalizado

Entendendo o conceito definição de pronto (Definition of Done)

Definition of Done
Getty Images

Na primeira parte deste artigo, listamos a importância de definir o dor quando aplicá-lo e como ele pode ajudar a refinar cada elemento do backlog. Até agora, cobrimos um item no processo de planejamento.

Agora necessitamos entender o segundo conceito e como ele pode ajudar a determinar o status de pronto.

DOD – Definição de Pronto

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 oficial de pronto que todas as organizações e equipes de desenvolvimento devam seguir, pois cada produto tem sua complexidade.

Cada equipe discute constantemente as dificuldades do produto as ferramentas tecnológicos a serem colocadas, as necessidades do usuário e muito mais. Com isso em mente, você precisa criar uma definição pronta.

Essa definição foi criada antes do início do desenvolvimento do produto Usualmente antes mesmo da primeira execução.

Evolui ao longo da vida do produto e quanto mais matura a equipe mais rigorosa é a definição de feito, o que consequentemente leva a um aumento na qualidade da entrega do sprint.

Quando há necessidade de revisar a definição de Pronto, este é o momento mais adequado na Retrospectiva da Sprint.

Semelhante ao dor você pode aplicar a mesma estratégia configurando uma lista que é verificada quando a tarefa é desenvolvida. A tarefa pode ser considerada pronta somente se estiver de acordo com os pontos anexados ao DOD.

De acordo com o exemplo mencionado Podemos especificar os seguintes pontos como DOD:

  • Tratamento de retorno de API negativo básico (interface de programação de aplicativos)
  • Codificação verificado por outro membro da equipe
  • As características atendem aos critérios de aceitação.

Como nós chegamos Embora houvesse alguma confusão. Mas entender os conceitos de DOR e DOD é uma parte essencial do desenvolvimento ágil de produtos.

É importante ressaltar que esses conceitos podem variar de projeto para projeto, mas é fundamental que toda a equipe esteja atenta a esses conceitos para ter sucesso.


Como você pode agregar valor ao seu projeto?

Algumas organizações têm dificuldade em encontrar a pessoa certa para atuar como proprietário do produto.

Como resultado, eles dividiram a responsabilidade por esse papel em várias pessoas.

Por exemplo, o gerente de projeto é responsável pela satisfação do cliente enquanto o scrum master é responsável pelo sucesso e colaboração do projeto mesclando conceitos e métodos.

Ao tombar nessa armadilha, as empresas perdem parte do potencial do papel de Product Owner e uma grande oportunidade de mudar (para melhor) o desenvolvimento do projeto.

O papel de proprietário do produto para várias pessoas só faz sentido se várias equipes estiverem trabalhando no mesmo projeto.

Nesse caso, você normalmente trabalha com uma equipe de proprietários do produto e uma pessoa responsável por todo o projeto (às vezes chamado de proprietário principal do produto .

Também há problemas ao misturar a função Scrum Master com o proprietário do produto. No Scrum, o proprietário do produto é responsável pelos conceitos e ideias (backlog, etc.), e o Scrum Master é responsável pela execução e qualidade do projeto.

Os proprietários de produtos exigem mais funcionalidade, enquanto o Scrum Master se concentra na execução e integridade, bem como no alcance de metas.

Consequentemente, essa combinação de papéis não é recomendada, pois é necessário ter uma pessoa com aptidões únicas para assumir tal responsabilidade, o que é bastante difícil de fazer.


LEIA TAMBÉM:

nv-author-image

Joao A M Santos

Com uma carreira atuante na área de Projetos de Tecnologia de Informação, desenvolvo trabalhos voltados para a gestão das atividades da área, atuando em empresas do segmento de saúde e consultorias em tecnologia.

Deixe sua opnião ...

O seu endereço de e-mail não será publicado.