Estimativa de uma atualização da estrutura
Como estimar uma atualização de framework: por que um salto de versão principal é um projeto, e não um ticket, e como dividi-lo em histórias que você possa realmente dimensionar.
Atualizações de versão principal não são tickets. São projetos.
Versões de patch são tickets. Versões menores geralmente são tickets. Versões principais — aquelas com mudanças compatíveis, 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 história que diz “atualizar para o React 19” ou “Postgres 16” não é o trabalho em si; é o invólucro 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 estrutura 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 se fala 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 é só isso?”
Perguntas que vale a pena fazer antes de votar
- Quantas alterações que quebram a compatibilidade se aplicam à nossa base de código — basta ler o changelog e contar?
- 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 superfícies 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 — vamos planejá-lo dessa forma” e, em seguida, 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 preceder a estimativa. Confira os outros exemplos práticos de estimativa.