Estimativa de uma atualização da estrutura

As atualizações de versão principal não são tickets. São projetos.

Versões de patch são tickets. Versões secundárias geralmente são tickets. Versões principais (aquelas com mudanças que quebram a compatibilidade, ciclos de descontinuação, cascatas de dependências entre componentes e a frase “recomendamos migrar para…” no changelog) são projetos, e o planning poker não é a ferramenta adequada para estimar o tamanho delas como um todo. A tarefa que diz “atualizar para o React 19” ou “Postgres 16” não é o trabalho em si; é a embalagem em torno do trabalho.

Tratar a atualização como uma única estimativa resulta em um único modo de falha: a equipe vota em 13, fica sem tempo na terceira semana e entrega uma base de código parcialmente migrada, que contém os bugs da nova estrutura e as convenções da antiga. A atitude correta é dividir a atualização em uma sequência de histórias menores, cada uma estimável de forma independente, tendo a própria atualização como projeto guarda-chuva.

O que é dito na sala

Engenheiro: “O codemod cuida da maior parte disso.”

Líder: “A maior parte do quê? O que é que ele não consegue lidar?”

SRE: “Todas as nossas dependências já são compatíveis com a nova versão?”

Pergunta: “Qual é a nossa estratégia de testes de regressão para o diff?”

PM: “Vamos entregar mais alguma coisa neste sprint, ou esse é o sprint?”

Perguntas que vale a pena fazer antes de votar

• Quantas alterações que causam quebra de compatibilidade se aplicam à nossa base de código (leia o changelog e conte)?
• As dependências entre pares são compatíveis com a versão de destino, ou devemos aplicar a dependência em cascata?
• Codemod ou manualmente? Qual é a cobertura do Codemod?
• Cobertura de testes nas áreas alteradas: é adequada ou devemos adicionar testes primeiro?
• Qual seria a estratégia de reversão caso as coisas não corram bem no meio do sprint?
• Um PR ou vários? Se forem vários, qual é a ordem de dependência?

O resultado correto dessa conversa costuma ser: “isso não é uma história, é um projeto, então vamos planejá-lo dessa forma”, e depois dividi-lo em partes que cada membro da equipe possa estimar com base em uma história de referência.

Não atribua um único número a uma grande atualização. Divida-a em histórias e, em seguida, avalie o tamanho de cada uma delas.

Consulte técnicas de estimativa para trabalhos mais vagos ou de maior porte, e estimativa de um pico de pesquisa para a investigação que deve anteceder a estimativa. Confira os outros exemplos práticos de estimativa.