Estimativa de uma atualização de dependência
Como estimar uma atualização de dependências: o aumento gradual que esconde N picos em um único ticket. Leia primeiro os registros de alterações e, em seguida, faça uma estimativa do que você encontrou.
As correções e as alterações menores são ruído. As alterações maiores em N bibliotecas correspondem a N picos — estime o pior cenário, não a média.
As atualizações de dependências se apresentam de duas formas que parecem idênticas na saída do gerenciador de pacotes. A primeira: um conjunto de patches e atualizações menores que a equipe deve agrupar, submeter à suíte de testes e mesclar em um único PR sem graça. Essa história recebe nota 1, às vezes 2, e a única razão para votar nela é confirmar que a equipe concordou que é chata. A segunda forma: uma atualização significativa em uma ou mais bibliotecas, em que o changelog tem uma seção de “mudanças que quebram a compatibilidade” e a equipe precisa lê-la. Essa é a história que fica à vista de todos, mas passa despercebida. A equipe vota com um 3 porque “é só uma atualização” e a libera com um 13 três sprints depois.
Isso não é uma atualização de framework. Uma atualização de framework é uma biblioteca para a qual você se planejou durante um trimestre; a equipe sabe que se trata de um projeto. Uma atualização de dependência é aquele ticket de manutenção discreto que alguém abre porque a verificação de segurança sinalizou seis bibliotecas, e ninguém leu os registros de alterações. A armadilha está na distribuição: das seis atualizações, quatro são triviais, uma é uma exportação renomeada e uma é uma reformulação completa da API. A estimativa que calcula a média delas está errada em ambos os sentidos.
O que se fala na sala
Engenheiro A: “São seis saliências. Duas para cada um. 13 no total.”
Líder: “São todos menores de idade?”
Engenheiro A: “Três menores, três maiores.”
Engenheiro B: “Alguém leu os principais registros de alterações?”
Engenheiro A: “…deixa eu dar uma olhada.”
Líder: “Ainda não temos uma estimativa. Temos três picos.”
A introdução está correta. Não há um único número para essa história porque não existe uma história única. Os pequenos problemas se somam como um conjunto à parte; cada problema grave é um pico à parte até que alguém leia o changelog e saiba o que está causando o problema.
Perguntas que vale a pena fazer antes de votar
- Quantas atualizações, e qual é a divisão entre principais, secundárias e correções?
- Alguém já leu os registros de alterações das versões principais?
- Alguma dessas bibliotecas pertence à equipe, em vez de pertencer a fornecedores?
- Existe algum conflito de dependência transitiva que os obrigue a ocorrerem juntos?
- Qual seria o procedimento de reversão caso uma das atualizações prejudique a produção?
- A equipe de segurança tem um prazo, ou isso é uma dívida técnica?
Se a resposta à pergunta “alguém leu os registros de alterações?” for “não”, a estimativa não é realista. Preveja um pico limitado para cada grande atualização, identifique o que realmente está apresentando falhas e, em seguida, reavalie a implementação com base no que foi constatado.
Não faça uma estimativa das atualizações de dependências contando apenas os números das versões. Leia primeiro os registros de alterações e, depois, faça uma estimativa com base no que você descobriu.
Consulte como estimar uma atualização de framework para a variante de versão principal com uma única biblioteca e os outros exemplos práticos de estimativa. Inicie uma sessão gratuita de planning poker depois que os spikes tiverem esclarecido o que realmente vai mudar.