A Definição de Pronto: Vantagens e Perigos

Menos utilizada do que a Definition of Done, a Definition of Ready é usada por algumas equipes para definir quais itens do Product Backlog podem ser incluídos em uma iteração.

Você pode imaginar a Definition of Ready como um segurança grande e forte parado na porta da próxima iteração. Assim como um segurança que só deixa certas pessoas entrarem no clube – os jovens, descolados e bem vestidos – a Definition of Ready também só permite que certas User Stories entrem na iteração.

E assim como um clube pode decidir por si mesmo quem os seguranças deixam entrar ou não, cada equipe ou organização pode decidir qual é a sua Definition of Ready. Não existe uma Definition of Ready universalmente válida para todas as equipes.

Um modelo para a Definition of Ready

Que tipo de Stories nosso segurança poderia deixar entrar na iteração? Ele poderia, por exemplo, deixar entrar Stories que atendam a estes ou critérios semelhantes:

• As Conditions of Satisfaction para a respectiva Story foram completamente definidas.

• A Story foi estimada e tem um tamanho máximo definido. Se a equipe trabalha com Story Points, por exemplo, os membros da equipe definem uma quantidade específica de Story Points e só permitem que Stories que correspondam a essa quantidade ou sejam menores entrem na iteração. Frequentemente, esse tamanho máximo é cerca da metade da Velocity da equipe.

• O User Interface Designer já criou um mock-up ou o design completo para as telas relacionadas à Story.

• Dependências externas foram eliminadas, independentemente de serem dependências internas ou externas à equipe.

Uma Definition of Ready define as pré-condições

Uma Definition of Ready permite que a equipe estabeleça critérios que devem ser atendidos antes que uma story possa ser incluída em uma iteração. O objetivo é prevenir problemas antes mesmo que eles tenham a chance de ocorrer.

Dizer que apenas stories até um determinado tamanho máximo podem ser incluídas em uma iteração, por exemplo, evita que uma story seja iniciada quando é grande demais para ser concluída em uma única iteração.

Da mesma forma, não permitir que uma story com dependências externas entre na iteração pode proteger contra o risco de que essas dependências comprometam a story ou toda a iteração, caso a outra equipe não consiga cumprir seu compromisso.

Imagine, por exemplo, que sua equipe às vezes dependa de outra equipe concluir primeiro uma parte do trabalho. Suas User Stories só podem ser finalizadas quando a outra equipe tiver concluído seu trabalho – e a tempo para que sua equipe ainda tenha a chance de integrar essas entregas.

Se essa equipe já deixou sua equipe na mão regularmente porque não conseguiu terminar algo no prazo prometido, seria lógico que sua equipe decidisse não incluir mais stories em uma Iteração quando ainda existe uma dependência pendente com a outra equipe.

Uma Definition of Ready que estabelece que todas as dependências externas devem ser eliminadas antes que uma story possa ser incluída na iteração poderia fazer sentido para uma equipe assim.

Uma Definition of Ready nem sempre é uma boa ideia

Algumas regras do nosso porteiro são claramente uma boa ideia. Por exemplo, não tenho problema se um time decide que nenhuma story acima de um determinado tamanho pode ser trazida para uma iteração.

No entanto, algumas regras que vejo frequentemente na Definition of Ready podem causar problemas – grandes problemas. Deixa eu explicar.

A Definition of Ready é como o portão para a iteração. Regras são estabelecidas e nosso porteiro cuida para que apenas stories que correspondam a essas regras entrem.

Se essas regras determinam, entre outras coisas, que algo precisa estar 100% concluído antes que uma story possa ser incluída na iteração, a Definition of Ready se torna um passo bem grande em direção a uma abordagem sequencial de Stage-Gate. Isso impede o time de ser ágil.

Uma Definition of Ready pode levar a etapas e portões de controle

Deixe-me explicar isso brevemente. Uma abordagem Stage-Gate é caracterizada por uma série de fases (stages) para o desenvolvimento. Além disso, na abordagem Stage-Gate são definidos os chamados portões (gates) ou checkpoints. Os trabalhos só podem passar de uma fase para a próxima quando atravessam um portão.

Quando eu ainda era criança, minha mãe usava uma abordagem Stage-Gate para o jantar. Eu só ganhava sobremesa se tivesse comido tudo. Não podia comer o jantar e a sobremesa ao mesmo tempo.

Para usar um exemplo do desenvolvimento de produtos, imagine um processo com fases separadas de design e codificação. Para passar da fase de design para a fase de codificação, os trabalhos precisam atravessar um portão de revisão de design. O portão deve garantir a completude e a qualidade do trabalho na fase anterior.

Então, se uma Definition of Ready contém uma regra de que algo precisa estar done antes que outra coisa possa ser iniciada, isso leva a equipe perigosamente perto de um processo Stage-Gate. E isso vai prejudicar a capacidade da equipe de ser ágil. Uma abordagem Stage-Gate é, afinal, apenas outra palavra para um processo em cascata.

Equipes Ágeis devem praticar o desenvolvimento simultâneo

Assim que uma tarefa não pode ser iniciada antes de outra estar concluída, o trabalho da equipe não pode mais acontecer simultaneamente. A execução simultânea de trabalhos é, no entanto, um dos indicadores mais óbvios de que uma equipe é ágil. Uma equipe ágil deve sempre realizar um pouco de trabalho de análise, design, teste e codificação ao mesmo tempo. Ao introduzir portões no processo de desenvolvimento, impede-se exatamente isso.

Equipes ágeis devem praticar o desenvolvimento simultâneo, onde as diferentes atividades para entregar software funcionando se sobrepõem. Atividades como análise, design, escrita de código e testes nunca acontecerão completamente ao mesmo tempo – e esse também não é o objetivo. O objetivo é que essas atividades simplesmente se sobreponham o máximo possível.

Pelo fato de que numa abordagem Stage-Gate certas atividades precisam estar 100 % concluídas, impede-se que outras atividades possam ser iniciadas. E uma Definition of Ready pode levar diretamente a uma abordagem Stage-Gate assim, se regras desse tipo forem incluídas na Definition of Ready.

Por esse motivo, recomendo à maioria das equipes não trabalhar com uma Definition of Ready. Frequentemente é esforço desnecessário. E o que é muito pior, pode ser um grande e perigoso passo de volta a um processo em cascata.

Em alguns casos, no entanto, uma Definition of Ready pode reconhecidamente resolver problemas e, portanto, valer a pena ser utilizada.

Como usar corretamente a Definition of Ready

Para utilizar a Definition of Ready com sucesso, você deve evitar regras que exijam que algo esteja 100% pronto antes que uma story possa entrar na iteração – talvez com exceção de dependências de determinadas equipes ou fornecedores. Além disso, você deve optar por diretrizes em vez de regras na sua Definition of Ready.

Aqui está um exemplo de uma regra que a equipe deveria reformular: "Toda story deve ter mock-ups detalhados para todas as novas telas."

Uma regra assim representa uma barreira. Ela impede que trabalhos aconteçam simultaneamente. Uma equipe com essa regra não consegue praticar desenvolvimento simultâneo. Enquanto não houver um design detalhado elaborado para cada story individual, não há trabalho do outro lado da barreira.

A melhor alternativa seria: "Quando uma story inclui novas telas importantes, já devem existir mock-ups suficientes dessas novas telas para que a equipe possa esclarecer as questões e problemas restantes ao longo da iteração."

Pequena mudança, grande impacto na Definition of Ready:

1. A regra se torna uma diretriz.
2. Ao dizer que os mock-ups só precisam ser suficientes em vez de prontos, permitimos trabalhos simultâneos.

Essas duas mudanças trazem um pouco mais de subjetividade ao uso de uma Definition of Ready. Ainda estamos dizendo ao porteiro que queremos pessoas jovens, descoladas e bem vestidas em nosso clube. No entanto, damos a ele mais liberdade para decidir por si mesmo o que "bem vestido" realmente significa.  

Este texto é do blog de Mike Cohn e foi traduzido por nós para o português.