Estimación de un cambio en el sistema de diseño
Cómo evaluar un cambio en el sistema de diseño: implementaciones de tokens, rutas de obsolescencia, cobertura de Codemod y los 200 puntos de llamada que utilizan el componente antiguo. Evalúe el impacto en las fases posteriores.
El artículo calcula el nuevo componente y omite los 200 lugares en los que se utiliza el antiguo.
Un cambio en el sistema de diseño tiene dos ámbitos. El primero es el propio sistema: el nuevo componente, el nuevo token y la documentación actualizada. El segundo son los puntos de llamada: todas las funcionalidades del producto que utilizaban la versión anterior y que deben migrarse a la nueva. El primer ámbito es reducido y conocido. El segundo es el que hace que el trabajo lleve, de hecho, un trimestre.
Los equipos que implementan el cambio en el lado del sistema sin un plan de obsolescencia implementan dos sistemas: el nuevo y todos los lugares en los que todavía se utiliza el antiguo. La estimación debe incluir la implementación —ya sea mediante Codemod o una migración manual, el calendario de obsolescencia y la estrategia de regresión visual—; de lo contrario, el trabajo simplemente se paralizará durante meses mientras los equipos de desarrollo se ocupan de ello cuando les sea posible.
Lo que se dice en la sala
Diseñador: «El nuevo token supone un cambio de una sola línea».
Frontend: «¿Cuántos componentes lo utilizan actualmente?»
Pregunta principal: «¿Vamos a realizar una actualización del código, o son los equipos de funciones los que se encargan de la migración por su cuenta?»
QA: «¿Regresión visual? ¿Percy? ¿Manual? ¿Ambos?»
PM: «¿Cuál es el plazo de obsolescencia de la versión anterior?»
Preguntas que conviene plantearse antes de votar
- ¿Cuántos puntos de llamada se ven afectados —según datos medidos, no estimaciones—?
- ¿Codemod o migración manual? ¿Cuál es el alcance de Codemod?
- Proceso de obsolescencia: advertencia, error, eliminación — ¿en qué plazo?
- ¿Se ha realizado una revisión visual de la regresión en las pantallas afectadas?
- Comunicación entre equipos: ¿a quién se lo comunicamos, cuándo y cómo?
- ¿Se debe revertir el cambio si el nuevo componente presenta un error que solo se detecta en producción?
El cambio en la parte inicial es pequeño y la limpieza posterior es lo que realmente supone trabajo, así que separémoslos: el nuevo componente constituye una historia, la migración de los puntos de llamada es otra, y el tamaño de esta última se determina en función del recuento medido, no de una estimación.
Calcule la migración hacia abajo. El nuevo token es una línea; los 200 sitios de llamada son el trimestre.
Al igual que la estimación de una actualización del marco de trabajo, el cambio en la fase inicial es mínimo y el trabajo real reside en la limpieza posterior. Consulte los demás ejemplos de estimaciones ya realizadas, o organice una sesión gratuita de Planning Poker cuando se haya determinado el alcance de la fase posterior.