Nesses casos, a melhor abordagem é alinhar como essas definições devem ser criadas, caso devam ser criadas, com os stakeholders que têm maior influência e impacto no projeto. Vou deixar aqui outro artigo que escrevi sobre esse tema chamado “Como usar a matriz de stakeholders para aumentar sua influência e melhorar a comunicação do projeto.”

Se você já é uma liderança com influência e autonomia suficientes, primeiro vou compartilhar os conceitos do SAFe e, em seguida, explicar como os uso na prática. Esse também é o tipo de problema que o Saint Jude ajuda líderes a observarem com mais clareza: tarefas que entram no board sem clareza suficiente, estimativas que não correspondem à realidade e riscos criados por uma definição ruim das tarefas.

Definição de ready e definição de done no SAFe

Shift learning left

O desenvolvimento de produtos inclui muitos cenários desconhecidos que o time descobrirá conforme o projeto avança, e o mesmo acontece com as tarefas individuais. Quanto mais tarde esses cenários são descobertos, mais difícil e caro se torna ajustá-los, impactando escopo, qualidade, cronograma e custos. Por esse motivo, ter um processo para verificar e validar possíveis cenários antecipadamente se torna essencial para o bom andamento de um projeto.

Pair programming e peer review

Essa é uma prática valiosa e bastante conhecida, mas ainda pouco utilizada de forma consistente por times de tecnologia. Dois profissionais trabalham juntos na mesma tarefa: um foca na construção da solução, enquanto o outro atua como navegador, oferecendo feedback e sugerindo melhorias em tempo real. A ideia é trazer mais de uma perspectiva sobre como a tarefa deve ser construída, aumentando não apenas o conhecimento sobre o produto, mas também o entendimento do time sobre como o produto funciona internamente.

Collective ownership e habilidades T-shaped

Aqui, o SAFe nos diz que toda pessoa dentro do time deveria ter as habilidades e a autoridade suficientes para modificar uma entrega, independentemente do momento do processo em que ela esteja. Nenhum profissional é dono da entrega ou do produto. Outro ponto importante nesse conceito é ter profissionais que, mesmo sendo especialistas em um tipo de trabalho, também entendam o projeto como um todo.

Padrões de artefatos e definição de done

As entregas muitas vezes dependem de processos manuais para mover tarefas entre profissionais dentro do mesmo time, o que pode gerar atrasos. Dentro desses processos de construção de produto, também há perda de tempo inspecionando tarefas ou procurando componentes que já existem e poderiam ser reutilizados para acelerar a entrega ou melhorar a performance. Automatizar esses processos ajuda a reduzir tempo e custos, aumentar a produtividade e melhorar os padrões de entrega.

Automação de workflow

Workflows geralmente incluem passagens manuais de tarefas entre profissionais dentro do mesmo time, criando atrasos e reduzindo a eficiência do fluxo. Durante esses processos de construção, os times também podem perder tempo inspecionando tarefas manualmente ou procurando componentes que já foram criados e poderiam ser reutilizados para acelerar a entrega ou melhorar a performance.

Automatizar esses processos ajuda a reduzir tempo e custos, aumentar a produtividade e melhorar os padrões de entrega. Na prática, isso está muito conectado ao que o Saint Jude busca tornar visível: onde as tarefas estão esperando, onde o fluxo está ineficiente e como trabalhos pouco claros podem impactar cronograma, custo e performance de entrega.

Esses conceitos fazem parte do que o SAFe entende como qualidade embutida. Como você deve ter percebido, a Definição de Ready (DoR) e a Definição de Done (DoD) não são ideias isoladas. Elas fazem parte de algo maior: qualidade.

Agora, vamos ver como uso esses conceitos para criar uma melhor Definição de Ready e Definição de Done nos projetos que gerencio.

Definição de ready/done e qualidade na prática

Para criar clareza e melhorar a documentação, uso um tripé formado por PO, UI e tech leader para construir a Definição de Ready de qualquer tarefa, usando a seguinte estrutura:

• UI documenta o fluxo esperado e os fluxos alternativos
• PO documenta o que é esperado como entrega de negócio
• Tech leader documenta como deve ser construído

Por quê? Honestamente, nunca vi um projeto em que todos os membros do time tivessem as habilidades e a autoridade para tomar todas as decisões. Por causa disso, torna-se necessário criar uma liderança técnica e de negócio entre as partes interessadas para guiar e validar as tarefas. Com base na experiência que adquiri, ter alguém para orientar tecnicamente o time é necessário até que o próprio time se torne autossustentável.

Para a Definição de Done, também uso esses profissionais para validar e finalizar formalmente a entrega. Dito isso, agora vou explicar esse ponto com mais detalhes usando os conceitos do SAFe.

Shift learning left

Nesse caso, com a documentação inicial fornecida pelo meu tripé de profissionais, o time de desenvolvimento pode começar a construir a tarefa por meio de testes, usando a famosa abordagem TDD, enquanto o time de QA já pode trabalhar nos cenários de teste usando BDD. Também posso trazer aqui um conceito do mundo ágil: se o time não entende o que deve ser feito durante os eventos de refinamento, a tarefa não está pronta para entrar na sprint. A partir desse ponto, devolvemos a tarefa para o tripé com todas as perguntas levantadas pelo time e refinamos a documentação até que a tarefa esteja cristalina para todos.

Pair programming e peer review

Eu gosto muito de pair programming, mas vou trazer uma verdade desconfortável que quase ninguém tem coragem de dizer:

“Se você coloca duas pessoas para trabalhar em uma tarefa em vez de duas pessoas trabalhando em duas tarefas diferentes, ou você tem uma influência considerável dentro da sua empresa, ou seu chefe talvez não fique feliz com você.”

A verdade é que quase ninguém quer sacrificar tempo em favor da qualidade. Dito isso, uma ação que sempre aplico com meus times é fazer com que meu tripé — PO, UI e tech leader — sirva como um grupo de oráculos durante o processo de construção. Não importa quanto tempo gastemos documentando o que precisa ser feito, perguntas ainda podem surgir no meio do trabalho. Quanto mais rápido respondermos a essas perguntas, mais rápido avançamos. Em geral, peço que esse tripé reserve uma hora por dia para responder dúvidas. Funciona quase como uma daily, mas com mais tempo para explicações complexas.

Collective ownership e habilidades T-shaped

Aqui novamente, confio no meu tripé de profissionais como as pessoas responsáveis por qualquer modificação nas tarefas. Mas por quê?

No início de um projeto, ou mesmo quando novos profissionais entram, o conhecimento e a experiência deles geralmente são zero ou muito baixos em relação às regras de negócio, ao que precisa ser feito e ao que se espera das entregas. Por esse motivo, eles dependem do conhecimento das pessoas que têm mais tempo no projeto ou mais experiência, como PO, tech leader e UI. Essas são as pessoas que têm as chaves para entrar e modificar qualquer processo ou entrega. Com o tempo, o time ganha confiança e passa a conseguir intervir em qualquer fase do processo.

No entanto, existe um ponto específico aqui: seres humanos naturalmente se apegam à autoridade que conquistaram. Se você remove de repente a autoridade previamente conquistada por alguém, pode criar problemas comportamentais, às vezes chegando até a pedidos de demissão ou desligamentos. Por outro lado, quando esses profissionais saírem de férias, você já terá um time treinado e capaz de modificar entregas quando necessário.

Por fim, sobre habilidades T-shaped: usando a regra de Pareto, eu diria que em 80% dos casos isso simplesmente não acontece. Primeiro, porque leva muito tempo para adquirir conhecimento amplo, e os projetos nem sempre duram o suficiente. Segundo, porque é difícil encontrar profissionais interessados em aprender um pouco sobre cada novo tema envolvido na construção de um produto.

Padrões de artefatos e definição de done

Agora vamos entrar um pouco mais na Definição de Done, mas primeiro vou começar pelos padrões. Todo profissional tem padrões de trabalho e, quando esses padrões são documentados, eles se tornam os padrões do projeto. Vou abrir uma exceção para padrões que vêm de fora, como padrões da empresa ou do PMO. De qualquer forma, padrões existem e influenciam como o trabalho é entregue.

Em relação à Definição de Done, mencionei antes que um dos pontos principais é a validação e aceitação formal pelo meu tripé. Além disso, uso casos de teste e automação de testes unitários como parte da Definição de Done. O principal motivo é criar uma trava de segurança e evitar problemas em produção. Se os testes falham, o produto não está pronto para os meus clientes.

Automação de workflow

Para trazer mais agilidade ao processo de finalização das tarefas, desde o momento em que elas começam até sua conclusão, a melhor abordagem é equilibrar o que precisa ser feito com a quantidade de pessoas disponíveis para fazê-lo. Se você precisar escolher, é melhor ter pessoas esperando por tarefas do que tarefas esperando por pessoas. No fim, queremos entregar um produto rapidamente e com alta qualidade, não é?

Em relação à inspeção de tarefas, quando os casos de teste e os testes unitários são automatizados, a inspeção manual se torna menos necessária. Por fim, a busca por componentes pode ser descrita na documentação inicial da tarefa. Se não estiver, um dos nossos oráculos deve ser capaz de responder. É também aqui que ferramentas como o Saint Jude podem criar curiosidade para lideranças: quando clareza da tarefa, estimativas, fluxo, cronograma e custo são analisados juntos, fica mais fácil entender se o time está realmente produtivo ou apenas ocupado.

Chego ao fim deste artigo. Aqui, você aprendeu alguns conceitos do SAFe sobre qualidade e como eu os uso para criar Definições de Ready e Done eficientes para meus projetos.

Quer continuar essa conversa? Dê um like no artigo, comente no LinkedIn ou compartilhe nas suas redes sociais.

Até breve!

Erik Scaranello