Estimativa de uma alteração no sistema de design

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 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 é dito 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 concretos e não em suposições?
• 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 se o novo componente apresentar um bug que só seja detectado em produção?

A alteração na parte inicial é pequena e a limpeza na parte final dá mais 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 real, não por um palpite.

Estime a migração para jusante. O novo token é uma linha; os 200 locais de chamada são 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 escopo do downstream estiver definido.