Estimación de un cambio en el sistema de diseño
Cómo evaluar un cambio en un 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 no tiene en cuenta 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, de hecho, un trimestre.
Los equipos que implementan el cambio a nivel 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 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 un codemod o son los equipos de funciones los que se encargan de la migración por su cuenta?»
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 obsolescencia (advertencia, error, eliminación)?
- ¿Se ha llevado a cabo 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 sepárelos: el nuevo componente constituye una historia, la migración de los puntos de llamada constituye 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 al estimar una actualización del marco, el cambio en la fase inicial es pequeño y el trabajo real reside en la limpieza posterior. Consulte los demás ejemplos prácticos de estimación o inicie una sesión gratuita de «planning poker» cuando se haya determinado el volumen de trabajo de la fase posterior.