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 Agile. 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
  • Identifique todas as atividades necessárias para preparar uma história de usuário para o planejamento de iteração / um recurso pronto para as equipes de planejamento de PI ou Agile escreverem histórias de usuário.
    • Foco em atividades que agregam valor
    • Essas atividades podem variar amplamente dependendo do produto (software, hardware, mainframe, design ou artefatos conceituais, etc.)
  • Selecione apenas as atividades que ocorrem novamente para quase todas as histórias de usuário / recurso para ficar pronto
  • Registre todas essas atividades recorrentes em uma lista abrangente de critérios potenciais para DoR
  • Priorizar a lista de atividades de cima para baixo
  • Faça uma lista restrita apenas dos critérios que podem ser atendidos de forma realista antes que uma história de usuário seja puxada para o planejamento / recurso de iteração para as equipes de planejamento de PI ou Agile para escrever histórias de usuário
    • A equipe decide o quão completo e perfeito eles querem seu DoR neste ponto
    • Preste atenção em como a estimativa de Recursos deve ser feita antes das Histórias de Usuário associadas
    • Estimativa e depois que as Histórias de Usuário são estimadas
  • Obtenha a concordância e o compromisso da equipe com os critérios selecionados, que agora são o DoR para Histórias de usuários / recursos
  • Identifique todas as atividades necessárias para concluir uma história de usuário / um recurso.
    • Foco em atividades voltadas para a qualidade do produto (Qualidade Integrada).
    • Essas atividades podem variar amplamente dependendo do produto (software, hardware, mainframe, design ou artefatos conceituais, etc.)
    • Atividades de aprovação ou assinatura com partes externas e partes interessadas que estão fora do controle da equipe podem ser omitidas.
  • Selecione apenas as atividades que ocorrem novamente para que quase todas as histórias de usuário / recurso sejam concluídas.
  • Registre todas essas atividades recorrentes em uma lista abrangente de critérios potenciais para DoD
  • Priorizar a lista de atividades de cima para baixo
  • Faça uma lista restrita apenas dos critérios que podem ser atendidos de forma realista antes que uma história / recurso de usuário seja concluída o A equipe decide o quão completo e perfeito eles querem seu DoD neste ponto
    • Preste atenção ao que fazer se um recurso pode ser considerado completo, mas ainda está associado
    • Histórias de usuários abertas
  • Obtenha a concordância e o compromisso da equipe com os critérios selecionados, que agora são o DoD para Histórias de usuários / recursos

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 PI 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 está pronta se, por exemplo:
    Possui critérios de aceitação que podem ser testados objetivamente
  • Estimado por toda a equipe de desenvolvimento
    Socializado com toda a equipe
  • Tem o tamanho certo que pode ser concluído em uma Sprint, de preferência de 2 a 3 dias ou não maior do que [certos] pontos da história
  • Está em conformidade com o Modelo de INVEST (Independente, Negociável, Valioso, Estimativa, Pequeno, Testável) e não tem dependências externas
  • Carregado / criado na ferramenta / ambiente Agile da equipe
  • Escrito no formato de voz do usuário:
    QUEM <alguém>, O QUE <fazer algo>, POR QUE <algum resultado ou benefício>. Por exemplo.:
    COMO <alguém>, EU QUERO <fazer algo>, ASSIM QUE <algum resultado ou benefício>
Uma história de usuário é concluída se, por exemplo:

  • Atende aos seus critérios de aceitação
  • Testado (por exemplo, para software / hardware)
  • Validado (por exemplo, para documentos de design, modelos)
  • Demonstrado para as partes interessadas
  • Não há mais defeitos que devem ser corrigidos
  • Documentado
  • Aceito pelo Dono do Produto
Programa:

Features

Um recurso está pronto se, por exemplo:

  • Possui critérios de aceitação que podem ser testados objetivamente
  • Tem o tamanho certo que pode ser concluído em um PI
  • Tem histórias de usuário definidas
  • Carregado na ferramenta / ambiente Agile da equipe
  • Estimado (pontos da história, tamanho da camiseta, …)
  • Escrito na Matriz de Recursos e Benefícios:

Feature – Uma frase curta que fornece um nome e contexto;
Hipótese de benefício – O benefício mensurável proposto para o usuário final ou empresa

Um recurso é concluído se, por exemplo:

  • Atende aos seus critérios de aceitação
  • Testado e integrado
  • Demonstrado para as partes interessadas
  • Documentado e treinamento fornecido
  • Não há mais defeitos que devem ser corrigidos
  • Suas histórias de usuário necessárias são concluídas e todas as histórias de usuário restantes são cuidadas, por exemplo, desacopladas do recurso e movidas para o backlog, ou excluídas, ou …
  • Aceito pela Gestão de Produto
Solução em larga escala:

Capacidades

Uma capacidade está pronta se, por exemplo:

  • Tem o tamanho certo que pode ser concluído em um PI, embora por vários ARTs
  • Seus facilitadores associados para o trabalho técnico necessário são identificados
  • Socializado com a Gestão de Produto das ARTs relevantes
  • Descrito usando uma frase e hipótese de benefícios, semelhante a Características:

Capacidade – Uma frase curta que fornece um nome e contexto;
Hipótese de benefício – O benefício mensurável proposto para o usuário final ou empresa

Uma capacidade é realizada se, por exemplo:

  • Seus recursos associados estão concluídos
  • É implantado no ambiente de teste
  • Seus NFRs associados são atendidos
  • Integração de ponta a ponta, testes, validação e verificação são feitos
  • Não há mais defeitos que devem ser corrigidos
  • Demonstrado para as partes interessadas
  • Documentado e treinamento fornecido
  • Aceito pela Gestão da Solução
Lançamento do produto
Uma liberação está pronta se, por exemplo:
• Todos os recursos / capacidades são concluídos
• Teste de integração ponta a ponta é feito
• Teste de regressão é feito
• A documentação de liberação está completa
• Não há mais defeitos que devem ser corrigidos
• O guia do usuário é criado
• O treinamento do usuário é criado
• Aprovado por Gerenciamento de Produto / Solução
• Aprovado pelo Gerenciamento de Liberação
Uma liberação é realizada se, por exemplo:
• Testes de integração ponta a ponta e V&V são realizados
• Teste de regressão é feito
• O teste de desempenho é feito
• NFRs são atendidos
• Não há mais defeitos que devem ser corrigidos
• Os padrões estabelecidos são atendidos
• O treinamento é entregue
• Aprovado pelo Produto / Solução
Gerenciamento e Gerenciamento de Liberação

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 Framework 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.

Referências

  • Built-in-Quality by the Scaled Agile Framework Inc. https://www.scaledagileframework.com/built-in-quality/
  • The Dangers of a Definition of Ready by Mike Cohn. https://www.mountaingoatsoftware.com/blog/the-dangers-of-a-definition-of-ready
  • Adaptado de: Definition of Ready & Definition of Done – Joseph Barjis PhD, SAFe® SPC 4.6 – Contributor to SAFe® Framework

No comments yet.

Leave a comment

Your email address will not be published.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.