Estimativa de uma alteração no sistema de design
Como estimar o impacto de uma mudança no sistema de design: implementações de tokens, caminhos de descontinuação, cobertura do Codemod e os 200 pontos de chamada que utilizam o componente antigo. Avalie o impacto nas camadas posteriores.
A matéria estima o número de novos componentes e não leva em conta os 200 locais que ainda utilizam o antigo.
Uma mudança no sistema de design abrange dois escopos. O primeiro é o próprio sistema — o novo componente, o novo token, a documentação atualizada. O segundo são os locais de chamada — todos os recursos do produto que utilizavam a versão antiga e precisam ser migrados para a nova. O primeiro escopo é pequeno e conhecido. O segundo é o que faz com que o trabalho realmente leve um trimestre.
As equipes que implementam a mudança no lado do sistema sem um plano de descontinuação acabam lançando dois sistemas: o novo e todos os locais que ainda utilizam o antigo. A estimativa precisa incluir a implementação — modificação de código ou migração manual, cronograma de descontinuação, estratégia de regressão visual — ou o trabalho simplesmente fica parado por meses enquanto as equipes de funcionalidade se dedicam a ele quando tiverem tempo.
O que se fala na sala
Designer: “A nova ficha é uma alteração de apenas uma linha.”
Front-end: “Quantos componentes o utilizam atualmente?”
Título: “Vamos fazer um codemod ou as equipes de funcionalidade estão migrando por conta própria?”
QA: “Regressão visual — Percy? Manual? Ambos?”
PM: “Qual é o prazo para a descontinuação da versão antiga?”
Perguntas que vale a pena fazer antes de votar
- Quantos locais de chamada estão afetados — com base em dados medidos, e não em estimativas?
- Codemod ou migração manual? Qual é a cobertura do Codemod?
- Cronograma de descontinuação: aviso, erro, remoção — em que prazo?
- Há cobertura de regressão visual nas telas afetadas?
- Comunicação entre equipes: a quem informamos, quando e como?
- Deve-se reverter a mudança caso o novo componente apresente um bug que só seja detectado em produção?
A alteração na parte inicial é pequena e a limpeza na parte final é que dá trabalho, então separem-nas: o novo componente é uma história, a migração dos pontos de chamada é outra, e o tamanho da segunda é determinado pela contagem medida — não por um palpite.
Estime a migração a jusante. O novo token é uma linha; os 200 pontos de chamada representam o trimestre.
Assim como estimar uma atualização de framework, a alteração no upstream é pequena e o trabalho está na limpeza do downstream. Consulte os outros exemplos de estimativas já realizadas, ou inicie uma sessão gratuita de Planning Poker quando o volume de trabalho do downstream for definido.