Melhoria do processo e retrospetivas
Dados, causas, ações verificáveis e ciclos de aprendizagem na equipa.
Cinco pedidos de integração esperaram 2, 2, 3, 4 e 4 dias até à primeira revisão. “Temos de trabalhar mais” não explica onde se perdeu tempo. A melhoria do processo começa por observar essa espera, formular hipóteses e experimentar uma mudança que a equipa consiga avaliar.
Produto e processo
A Sprint Review pergunta o que aprendemos sobre o produto e o que deve mudar no backlog. A Sprint Retrospective pergunta como melhorar a forma de trabalhar, a qualidade e a colaboração.
Uma retrospetiva pode acontecer depois de uma iteração, entrega ou projeto. Não é uma sessão para classificar pessoas. Precisamos de um ambiente em que alguém possa explicar uma dificuldade sem receio de ser culpado por a revelar.
Separar factos de interpretações ajuda: “três pedidos esperaram mais de dois dias por revisão” é uma observação, enquanto “ninguém se interessa pela qualidade” é uma interpretação que os dados não demonstram.
Preparar a conversa
Define um objetivo concreto e um limite de tempo. “Perceber a espera por revisão” orienta melhor do que discutir todos os problemas do semestre.
Todos devem ter oportunidade de participar. Podemos começar com reflexão individual e depois agrupar observações. A pessoa que fala primeiro ou com mais confiança não deve definir sozinha a interpretação.
A diretiva de partida das retrospetivas propõe compreender o trabalho tendo em conta o conhecimento, competências, recursos e circunstâncias de cada pessoa. Isso não impede identificar uma decisão errada; ajuda a procurar condições que podemos melhorar.
Cinco passos
- Preparar o contexto. Acordar objetivo, regras e duração.
- Reunir dados. Construir uma visão partilhada de acontecimentos, resultados e dificuldades.
- Gerar interpretações. Procurar relações, causas possíveis e padrões.
- Decidir ações. Escolher poucas experiências que a equipa consegue realizar.
- Fechar e acompanhar. Registar decisões, responsáveis e momento de avaliação.
Uma linha temporal ajuda a ligar alterações e resultados. Dados de versões, feedback de utilizadores e medidas do fluxo podem complementar lembranças. Uma escala de satisfação mostra perceções; não mede diretamente a qualidade do produto.
Do sintoma à causa
Na aplicação, cinco pedidos esperaram 2, 2, 3, 4 e 4 dias até à primeira revisão. A média é dias. A mediana é o terceiro valor da lista ordenada, também 3 dias. A equipa recolhe datas de abertura, primeira revisão e integração. Descobre que os três pedidos mais lentos tinham muitas mudanças e que a pessoa que sabia rever a parte de dados estava ausente.
Há pelo menos duas hipóteses: pedidos grandes dificultam a revisão e conhecimento concentrado limita a capacidade. Não conseguimos concluir que dividir pedidos resolve tudo, mas podemos experimentar pedidos menores e uma revisão em par para partilhar conhecimento.
Perguntar “porquê?” várias vezes ajuda a explorar causas, sem transformar a última resposta numa prova. Confirma-a com observações e considera outras explicações.
Uma ação verificável
“Comunicar melhor” não diz o que fazer nem como avaliar. Uma ação mais concreta é:
No próximo Sprint, preparar alterações pequenas por comportamento e reservar uma sessão diária de revisão em par. Comparar o tempo até à primeira revisão com o Sprint anterior.
A ação tem responsável ou acordo de equipa, prazo e medida; o critério SMART lembra que objetivos devem ser específicos, mensuráveis, realizáveis, relevantes e delimitados no tempo. Não uses a medida como fim isolado: reduzir o tempo de revisão pode esconder revisões superficiais. Observa também defeitos descobertos depois e perceções da equipa.
Avaliar a experiência
Antes da experiência, os cinco pedidos esperaram 2, 2, 3, 4 e 4 dias, mediana 3. Depois, esperaram 0, 1, 1, 2 e 2 dias, mediana 1. A espera diminuiu, mas isso ainda não demonstra que a nossa intervenção causou a melhoria. Precisamos de comparar tamanhos dos pedidos, disponibilidade e tipo de trabalho.
Os Happiness Meters do projeto acrescentam perceções de assiduidade, ajuda, eficiência, iniciativa e qualidade entre colegas. São sinais de colaboração; não medem objetivamente a qualidade do produto nem substituem a retrospetiva.
Se o Sprint seguinte tiver menos alterações ou trabalho mais simples, parte da diferença pode vir daí. A equipa decide manter, ajustar ou abandonar a prática com base no conjunto da evidência.
Para executar a decisão, escreve a melhoria como um cartão no backlog e leva-a ao planeamento do próximo Sprint, com capacidade reservada e acompanhamento. Uma ação acordada mas ausente do plano pode nunca acontecer. Testar uma mudança delimitada permite aprender; escolher dez ações e executar nenhuma deixa as hipóteses por verificar.
Problemas frequentes
| Problema | Efeito | Resposta possível |
|---|---|---|
| Não há dados | A memória mais forte domina | Recolher acontecimentos e exemplos |
| Há demasiados assuntos | Nenhuma decisão ganha detalhe | Escolher um foco |
| Ações fora do controlo da equipa | O plano fica parado | Separar ações locais e pedidos externos |
| Não há acompanhamento | Repetimos a discussão | Rever a experiência seguinte |
| Uma pessoa domina | Perdemos outras perspetivas | Dar tempo individual e participação equilibrada |
A melhoria é um ciclo: observar, interpretar, experimentar e voltar a observar. Não existe uma prática que dispense conhecer a equipa e o problema.
Exercícios
Uma melhoria que podemos avaliar
A retrospetiva escolheu comunicar melhor. Substitui por uma experiência que trate a espera por revisão.
Pista
Solução
No próximo Sprint, fazemos revisão em par diariamente e comparamos a espera até à primeira revisão. A equipa acorda quem participa e reserva tempo. Também observa qualidade e tamanho dos pedidos, para não confundir revisão rápida com revisão superficial.
Confere a tua resposta:
- Escolhi uma ação concreta dentro do controlo da equipa.
- Indiquei prazo e responsável ou acordo de equipa.
- Indiquei uma medida de efeito e um risco de a interpretar isoladamente.
Erros frequentes
Uma intenção sem ação ou acompanhamento não permite avaliar melhoria. Não escolhas apenas uma meta numérica que possa ser cumprida escondendo problemas.
Melhorou, mas porquê?
Antes os pedidos esperaram 2, 2, 3, 4 e 4 dias, mediana três. Depois de dividir pedidos de integração, esperaram 0, 1, 1, 2 e 2 dias, mediana um. Conclui-se que a divisão causou toda a melhoria?
Pista
Duas medições não isolam todas as diferenças entre Sprints.
Solução
O resultado é compatível com a hipótese, mas não prova que a divisão explique toda a diferença. Ordenados, os valores antes são 2, 2, 3, 4, 4 e depois 0, 1, 1, 2, 2. Falta comparar tamanho e volume de trabalho, disponibilidade de revisores e defeitos posteriores. Podemos manter a experiência e recolher mais observações.
Confere a tua resposta:
- Reconheci evidência compatível com melhoria.
- Considerei capacidade, tamanhos e tipos de trabalho.
- Propus continuar a observar antes de atribuir toda a causa.
Erros frequentes
Não negues o resultado observado. Também não o transformes automaticamente numa prova causal universal.