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 apresenta uma estimativa do novo componente e não leva em conta os 200 locais que 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 pontos 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 implantação (codemod ou migração manual, cronograma de descontinuação, estratégia de regressão visual); caso contrário, 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?”
Líder: “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?
- Qual será o cronograma para o processo de descontinuação (aviso, erro, remoção)?
- 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; portanto, separe-as: o novo componente é uma história, a migração dos pontos de chamada é outra, e o tamanho da segunda é determinado pela contagem real, não por uma estimativa.
Estime a migração a jusante. O novo token é uma linha; os 200 pontos de chamada são o trimestre.
Assim como na estimativa de uma atualização de framework, a alteração no upstream é pequena e o trabalho de limpeza no downstream é que dá trabalho. Consulte os outros exemplos práticos de estimativa ou inicie uma sessão gratuita de Planning Poker quando o volume de trabalho no downstream for definido.