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 pasa por alto las 200 ubicaciones que utilizan 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, 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 realmente 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 implantación (codemod o migración manual, calendario de obsolescencia, estrategia de regresión visual); de lo contrario, el trabajo simplemente se paralizará durante meses mientras los equipos de funciones se ocupan de ello cuando les resulte 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?»
Enfoque: «¿Vamos a llevar a cabo una actualización del código, o serán los equipos de funciones los que se encarguen de la migración por sí mismos?»
Pregunta de control de calidad: «¿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 y no estimaciones?
- ¿Codemod o migración manual? ¿Cuál es el alcance de Codemod?
- ¿Cuál será el calendario para la fase de retirada gradual (advertencia, error, eliminación)?
- ¿Se ha llevado a cabo una cobertura de regresión visual 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 superior del código es pequeño y la limpieza en la parte inferior supone el mayor esfuerzo, por lo 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.