Sorry, this entry is only available in Brazilian Portuguese. For the sake of viewer convenience, the content is shown below in the alternative language. You may click the link to switch the active language.

Há alguns anos entendemos que entender o que é pronto em uma entrega é ponto inquestionável. Um conceito que permeia toda a agilidade.

A tal frase “mas na minha máquina funciona” não faz mais sentido para nossos padrões avançados de uso de métodos e frameworks. Do mesmo modo que times de alto desempenho aumentaram seus conhecimentos e expertise técnica, também aumentaram o nível de exigência na qualidade de entrada de requisitos que direcionarão uma iteração.

Práticas como “Refinement Backlog”, uma reunião que pode acontecer duas ou três vezes em uma semana, com objetivo de clarificar o entendimento de um item de backlog entre P.O. e time é cada vez mais usual, tornando as Sprint Planning Meeting assertivas.

No entanto, práticas como “Refinement Backlog Meeting”, escrita de Definition of Done (DoD) e Definition of Ready são comuns em times que tiveram alguns ciclos de aprendizado completos. Ou seja, experimentaram as dores de conviver com um backlog sem granularidade, as dores de ter uma Sprint falha ou até mesmo cancelada por falta de entendimento do que era pronto para entrega e só então entenderam a importância desses acordos e encontros.

 

Em 2012, Alexandre Magno escreveu aqui no Blog sobre essas tais dores:

 

“Uma reclamação frequente de times de desenvolvimento (Dev Team) em Scrum é que, com o discurso de agilidade, requisitos chegam nas Sprints com baixa qualidade. Não é difícil encontrar Product Owners que mantém no topo do Product Backlog itens com granularidade ruim, pouco (ou nenhum) detalhamento e – pior – baixo entendimento do próprio Product Owner sobre o que está sendo pedido. Isso, na maioria das vezes, transforma a Sprint Planning Meeting em uma reunião arrastada e com muitas perguntas não respondidas. Consequentemente, times fazem um planejamento de baixa qualidade e são surpreendidos ao longo das Sprints com impactantes descobertas do Product Owner sobre aquele item, o que resulta em mudanças no objetivo e desenvolvimento. Resultado: Time desmotivado. Sprint não consegue atingir meta. Product Owner insatisfeito com o time. Sistema em colapso.”

 

E nos esclareceu sobre o uso dos dois acordos de trabalho DoD e DoR, nos exemplificando o uso:

Requisitos Ready se transformam em entregáveis Done

 

Uma prática que tem ajudado bastante nestes casos é a adição ao Scrum do conceito de “Definition of Ready”. Este conceito age de forma bem parecida com a conhecida “Definition of Done”, mas enquanto “Done” garante qualidade na saída da Sprint, “Ready” garante qualidade na entrada da Sprint.

Enquanto o Dev Team tem o compromisso de entregar ao Product Owner apenas funcionalidades Done, este por sua vez assume o compromisso em manter apenas itens Ready no topo do Product Backlog.

 

Um exemplo de Definition of Ready

Uma “Definition of Ready” precisa ser capaz de expressar o mesmo significado para todos que a leem, principalmente Dev Team e Product Owner. Um exemplo:

Um Product Backlog, que aqui trataremos como Team Backlog Itens está Ready quando:

– Está escrito como uma User Story INVEST;
– Possui um Teste de Aceitação automatizável;
– Possui um Wireframe de baixa fidelidade;

Caso você trabalhe com itens de diferentes tipos no seu Product Backlog, como por exemplo: itens de negócio, itens técnicos, spikes, bugs, etc., você pode optar por ter uma Definition of Ready diferente para cada um deles; afinal de contas pode não fazer sentido gerar um Wireframe para um Spike intitulado “Escolha de solução para Pagamento de Cartão de Crédito”, certo?”

 

Nos dias atuais está cada vez mais comum precisarmos entender esses conceitos em escala.

Profissionais que atuam em empresas que vem utilizando o SAFe como seu framework de escala ágil carregam o desafio de levar este conceito para além times de desenvolvimento ágil. Precisam deixar claro para Product Managers, Business Owners e demais envolvidos na entrega final de um produto o que esperam ver concretizado como produto pronto.

Por sua vez, times ágeis que trabalham em paralelo entre si e com times de sistemas, infraestrutura, arquitetura e devops precisam se fazer entender e estar alinhados quanto ao que necessitam como requisitos para produção do produto final.

 

Já sabemos, “Quem tem a responsabilidade de tornar um item Ready, em um único time ágil?

 

A responsabilidade é do Product Owner, mesmo que para isso precise envolver outras pessoas. Enquanto o Dev Team trabalha, por exemplo, na Sprint 3, o Product Owner tem que garantir que os itens do topo do Product Backlog estejam Ready para a Planning Meeting da Sprint 4. Caso ele precise envolver o Dev Team neste trabalho, seria interessante “oficializar” reunião(ões) de “Refinement”(no texto original era citado o “Grooming” – porém por respeito à alguns países de língua inglesa, que utilizam a palavra com conotação ruim de assédio infantil, a substituição tem sido mais do que recomendada) que já fossem previstas no TimeBox da Sprint.

O uso de “Definition of Ready” não está limitado ao Scrum, e pode ser muito útil também quando trabalhando com Kanban e outros métodos. (Alexandre Magno – 2012).

Agora a nova pergunta se repete para escala. E essa mesma lógica da relação time <-> P.O. é utilizada pelo SAFe para produtos desenvolvidos com times escalados.

Para que vários times entendam qual a expectativa de Produto Pronto, de um Product Manager ou de Bussiness Owner, quem deve deixar os itens Ready?

Um P.M. (Product Manager) tem a missão de entender o produto, escrever e compartilhar essa Visão, o time-to-market ideal, o principal problema que este produto resolve com o Bussiness Owner, que entendemos normalmente como um diretor ou executivo patrocinador da ideia de um novo produto ou novas funcionalidades e mapear as primeiras métricas que funcionarão como feedback sobre o sucesso do produto.

Ou seja, esse P.M. é nosso P.O. escalado, atua no Program Backlog, que contém Features, entendendo-o, priorizando-o e refinando-o.  No entanto, pela complexidade e tamanho do produto, não mais sozinho, ele tem um time. O time de P.Os., que transformará seu entendimento sobre as funcionalidades do produto em requisitos granulares, refinados e priorizados para alcance do time, as user stories.

Um time ágil entrega pronto itens do Team Backlog em uma iteração, aqui temos um nível de Definition of Done e Definition of Ready. Vários times ágeis terão suas entregas integradas para um novo incremento de produto, ou incremento do sistema, aqui temos um próximo nível de Definition of Done e Definition of Ready.

 

 

  • Veja um exemplo dos níveis de Definition of Ready citados:
Incremento do Time Incremento do Programa (ou sistema)
• As users stories estão escritas no padrão 3Ws.

• Todas as user stories possuem critérios de aceitação.

• Ambiente de desenvolvimentos (equipamento, linguagem e frameworks) disponível para escrita de código com TDD.

• Controlador de versão disponível para o Agile Team.

 

• Visão compartilhada com todos Agile Teams, stakeholders e business owners.

• Top 10 Features compondo o Backlog de Programa com descrição de benefício chave e critérios de aceitação.

• Features prontas para P.Os quebrarem em User Stories​.

• Artefatos que esclarecem os objetivos dos programas como documentos de arquitetura, resultados de spikes de iterações anteriores, requisitos não funcionais e entregas prévias devem estar disponíveis e compartilhadas para os demais times afim de facilitar o design emergente, as integrações e estimativas.

Então o P.M. tem uma visão de uma ou mais Features (funcionalidades) prontas, mesmo que estas sejam desenvolvidas por mais de um time trabalhando ao mesmo tempo. O que nos dá ganho de time-to-market. Essa visão deve ser compartilhada entre todos os P.Os., Scrum Masters e times de desenvolvimento. E, pensando SAFe, essa Visão também deve estar compartilhada com os demais comprometidos com a entrega: como arquitetos, RTE, devops, system team, time de lean-ux e outros. Todos entendem a expectativa de produto pronto e sinalizam o que deve estar “ready” para a completar entrega.

Percebemos então que na medida que o ágil cresce em aplicação dentro de uma corporação e a necessidade de coordenação escalada também cresce, as práticas de qualidade devem acompanhar este crescimento. Por isso recomendamos o DoD e DoR em dois níveis.

Como sua corporação está aplicando e escalando estes acordos de trabalho? Compartilhe conosco nos comentários.

This Post Has 2 Comments

  1. Excelente artigo. Só recomendaria, na minha humilde opinião, que substituam o termo “grooming” por refinamento. Este termo (grooming) tem ganhado uma conotação muito ofensiva com relação às crianças. (Grooming is when someone builds an emotional connection with a child to gain their trust for the purposes of sexual abuse, sexual exploitation or trafficking.)

    1. Corretíssimo Marcelo, essa é uma recomendação internacional. Eu não quis mexer no texto original citado, de 2012, mas coloquei a observação no artigo seguindo sua sugestão. Grata

Leave a Reply

Close Menu