Definição de Pronto e Definição de feito (DoR e DoD)
PARTE 1: Definição de DoR e DoD
Os conceitos de Definição de Pronto (DoR) e Definição de feito (DoD) são termos usados para reforçar a Transparência, garantir a Qualidade Integrada e definir as expectativas corretas para os itens de trabalho a serem planejados, desenvolvidos e concluídos durante o desenvolvimento de um produto Ágil.
Porque?
Primeiramente a escrita de DoR e DoD são ferramentas de comunicação entre as partes, por exemplo, Dono do Produto e Equipe de Desenvolvimento para definir expectativas claras – Transparência.
Visto que é um padrão formalmente acordado e um entendimento comum reduzirão retrabalhos e defeitos, cuidando da qualidade durante a construção do produto, e não por meio da inspeção do produto – Qualidade Integrada.
Inclusive DoR e o DoD definem um padrão de qualidade para todos os participantes envolvidos, portanto, é crucial que as próprias equipes criem seus DoR e DoD, os possuam e os sigam. Na criação dessas definições, duas coisas são cruciais: consultar os princípios do Agile (SAFe) e garantir o acordo total da equipe.
Como?
O DoR e o DoD devem ser vistos como critérios de entrada e saída, com o DoR servindo como uma pré-condição para verificar se um item está pronto para ser levado para a etapa atual e testar o DoD se um item está pronto para ser movido para a próxima etapa.
DoR e DoD podem ser aplicados em qualquer nível (por exemplo, equipe, programa, grande solução, portfólio, empresa, etc.) e a diferentes itens (por exemplo, histórias de usuário, recursos, capacidades, epopeias, iterações, lançamentos, incrementos de programa e até mesmo um programa piloto Agile completo).
A aplicação mais comum e básica dos conceitos DoR e DoD é vista no nível da equipe à medida que são aplicados às Histórias de Usuário.
Essas definições devem ser visíveis no ambiente de trabalho da equipe e usadas quando os itens são movidos de uma etapa para outra, especialmente quando os itens são levados para execução e quando são movidos para concluídos!
Os itens aos quais essas definições são aplicadas devem ter um resultado binário: Concluído ou Não Concluído. Evite a tentação de “quase pronto”, “meio que feito” ou “99% feito”.
Evolução DoR e DoD
DoR e DoD são acordos vivos que evoluem à medida que os usuários aprendem melhores maneiras de fazer seu trabalho, eles adquirem excelência em seu trabalho, sua prática amadurece, sua pista arquitetônica ou ambiente de desenvolvimento melhoram, eles adquirem melhores ferramentas, o contexto de suas mudanças de trabalho, surgem novos regulamentos ou requisitos de conformidade, etc.
DoR e DoD são um reflexo da realidade atual e não devem impor um padrão que seja irreal.
Com o tempo, o DoR e o DoD melhoram, levando os padrões e a qualidade cada vez mais alto. Em certo sentido, DoR e DoD podem ser usados como um indicador da maturidade das equipes Agile e sua jornada Agile.
As equipes passam de um DoR e DoD de alto nível para um nível mais detalhado, de um nível mais flexível para outro mais rigoroso, e eventualmente alcançando a capacidade de “Produto Potencialmente Remetível” a cada Iteração.
Essa abordagem é um reflexo do princípio do Manifesto Ágil “Atenção contínua à excelência técnica e um bom design aumenta a agilidade”.
DoR e DoD vs Critérios de Aceitação (AC)
Tendo em vista que DoR e DoD são mais genéricos e frequentemente aplicáveis a um amplo conjunto de itens, enquanto os Critérios de Aceitação (AC) são específicos para um item.
Por exemplo, no nível da equipe, DoR e DoD se aplicam a todos os itens do backlog da equipe, como User Stories, enquanto no nível do programa, eles se aplicam a todos os itens do backlog do programa, como Features, e assim por diante.
Já que DoD e AC são conceitos ortogonais e ambos são obrigados a considerar um item Concluído.
Entretanto DoD é uma espécie de superconjunto de AC. Juntos, DoR e DoD garantem a qualidade de um item e o AC garante sua funcionalidade. Por meio do AC, os itens de trabalho ficam mais específicos.
Ou seja a AC valida que o item certo foi construído. O DoD verifica se o item foi construído corretamente, portanto, as equipes podem incluir NFRs (requisitos não funcionais) relevantes em seu DoD como restrições no design local e nas decisões de implementação.
Para esclarecimento a diferença entre os dois é que o DoD é comum para todas as histórias de usuário, enquanto os critérios de aceitação são aplicáveis a histórias de usuário específicas. Os critérios de aceitação de cada história de usuário serão diferentes com base nos requisitos dessa história de usuário.
O DoR e o DoD facilitam as mudanças culturais e promovem uma nova mentalidade, enquanto o AC visa a excelência técnica.
DoR e DoD são a autoridade da equipe, enquanto o AC é a autoridade do cliente ou de seus representantes (Product Owner / Manager).
Autonomia vs Conformidade
Uma empresa pode ter certos requisitos nos níveis de programa ou solução que devem ser incorporados ao DoR e DoD. Por exemplo, o uso de certas ferramentas, uma certa forma de relatório, teste, financiamento, etc.
Embora as equipes tenham autonomia para criar seus próprios DoR e DoD, alguns requisitos podem vir como parte da política ou padrão corporativo que exige a conformação das equipes. Esses últimos requisitos farão parte dos, digamos, critérios fixos para o DoR e o DoD.
Cuidado com o anti-padrão DoR
Por outro lado o DoR pode facilmente cruzar a linha entre Agile e Waterfall quando a equipe não consegue realizar nenhum trabalho ou trabalho suficiente para uma iteração até que algo mais seja concluído. É quando um DoR se transforma em um anti-padrão.
Visto que é normal permitir a entrada de algumas histórias de usuários se eles não estiverem 100% reclamando das regras. Lembre-se de que o princípio iterativo e incremental também se aplica às regras contidas no DoR.
De acordo com Mike Cohn:
“quando um DoR inclui uma regra de que algo deve ser feito antes que a próxima coisa possa começar, ele move a equipe perigosamente perto do processo de passagem de estágio
… E pior, pode ser um grande e perigoso passo para trás em direção a um abordagem em cascata ”.
Entretanto algumas regras no DoR devem ser atendidas, como Critérios de Aceitação e Estimativa para Histórias de Usuário, enquanto algumas das regras podem ser apenas desejadas.
Conforme as equipes amadurecem em sua prática, seu DoR pode se tornar redundante. É apenas no início da jornada ágil que as equipes precisam seguir algumas diretrizes acordadas por escrito.
PARTE 2: Diretrizes para a criação de DoR e DoD
Essas diretrizes são desenvolvidas de forma genérica e podem ser adaptadas a qualquer nível (Equipe, Programa, Grande Solução, Portfólio) ou propósito e atividade, como Liberação, Iteração, Incremento do Programa ou um programa Piloto Ágil completo.
Facilite um workshop com toda a equipe ágil1. Certifique-se de que este seja um exercício de equipe inteira. Dependendo do nível e da finalidade do DoR e do DoD, os participantes podem incluir o proprietário do produto, gerenciamento de produto, gerenciamento de solução, gerenciamento de liberação, arquitetos, equipes de desenvolvimento, equipe de sistema, escritório jurídico, clientes, fornecedores e muito mais. Providencie participantes online, se necessário.
Dependendo do nível e do tamanho da equipe, recomenda-se uma sessão de 2 a 4 horas. Uma sessão (ou sessões) de acompanhamento pode ser organizada, se necessário.
Certifique-se de que a sala tenha um quadro branco, suprimentos como post-its, marcadores e agulhas e espaço suficiente para colaboração e interação. Acomode-se para colaboração online, se necessário.
| Criação de DoR para histórias de usuários / features | Criação do DoD para histórias de usuários / features |
|
|
Uma vez que o DoR e o DoD são criados, eles devem ser publicados, mantidos visíveis, de preferência na área de trabalho da equipe e nas ferramentas Agile que usam. Imprima-o como um pôster colorido que chama a atenção para enfatizar sua importância.
Repita todo o exercício descrito nas diretrizes acima em uma cadência regular, como fim da Iteração ou PI2 para expandir e refinar ainda mais o DoR e o DoD. Use os critérios restantes da lista abrangente inicialmente criada e quaisquer novos critérios devem ser adicionados.
PARTE 3: Exemplos DoR e DoD
Os exemplos DoR e DoD abaixo contêm critérios gerais para diferentes níveis. Conforme declarado, DoR e DoD são acordos informados pela realidade por todos os participantes, portanto, a tabela deve ser considerada apenas como um exemplo.
| Desenvolvimento de Produto | ||
| Definition of Ready | Definition of Done | |
| Time:
Histórias de usuários |
|
Uma história de usuário é concluída se, por exemplo:
|
| Programa:
Features |
Um recurso está pronto se, por exemplo:
Feature – Uma frase curta que fornece um nome e contexto; |
Um recurso é concluído se, por exemplo:
|
| Solução em larga escala:
Capacidades |
Uma capacidade está pronta se, por exemplo:
Capacidade – Uma frase curta que fornece um nome e contexto; |
Uma capacidade é realizada se, por exemplo:
|
| Lançamento do produto | ||
Uma liberação está pronta se, por exemplo:
|
Uma liberação é realizada se, por exemplo:
|
Conclusão
DoR e DoD são uma lista de verificação para verificar se todas as atividades de valor agregado e orientadas pela qualidade foram concluídas. Essa abordagem aparentemente simples tem um impacto tremendo na qualidade, entrega, previsibilidade e precisão do produto com a estimativa de trabalho.
Embora DoR e DoD sejam genéricos para todos os itens na categoria, nem todas as suas atividades podem ser aplicáveis a cada item (história de usuário, recurso, etc.). Portanto, a autoridade e a discrição da equipe são necessárias para lidar com as exceções.
Frequentemente, essas definições são uma lista abrangente para garantir que todas as atividades importantes sejam consideradas.
Ao desenvolver o DoR e o DoD, se uma precaução deve ser tomada, não defina a barra de qualidade muito alta para torná-la irreal. Não defina-o para a altura da melhor equipe realizadora para ver apenas as novas equipes fracassarem ou lutarem para alcançá-lo.
Qualquer coisa que não seja realista para ser alcançada no nível atual pode ser movida para o próximo nível superior. Por exemplo, se o teste de integração não for possível dentro da Iteração, mova-o para o Incremento do Sistema, se não, mova-o para Release, etc. Isso é o que se considera atingir maturidade Agile com o tempo. Claro, o objetivo é mudar constantemente a qualidade para a esquerda.
Finalmente, como o SAFe Framework3 como um todo, o DoR e o DoD também são escaláveis, ou seja, os critérios são cumulativos em cada nível.
Cada definição de nível superior assume todos os critérios dos níveis inferiores. Por exemplo, o DoD no nível do programa assume todos os critérios do nível da equipe mais os novos critérios do nível do programa e assim por diante.
Da mesma forma, os critérios de liberação assumem todos os níveis predecessores mais aqueles específicos para a liberação.
- The Dangers of a Definition of Ready by Mike Cohn. https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready
- Built-in-Quality by the Scaled Agile Framework Inc. https://www.scaledagileframework.com/built-in-quality/
- Built-in-Quality by the Scaled Agile Framework Inc. https://www.scaledagileframework.com/built-in-quality/
Deixe uma resposta
Want to join the discussion?Feel free to contribute!