Estimación de una actualización del marco de trabajo

Las actualizaciones de versión principales no son incidencias. Son proyectos.

Las versiones de parche son incidencias. Las versiones menores suelen ser incidencias. Las versiones mayores (aquellas que conllevan cambios que rompen la compatibilidad, ciclos de obsolescencia, cascadas de dependencias entre componentes y la indicación «recomendamos migrar a…» en el registro de cambios) son proyectos, y el «planning poker» no es la herramienta adecuada para estimar su volumen en su conjunto. La historia que dice «actualizar a React 19» o «Postgres 16» no es el trabajo en sí; es el envoltorio que rodea al trabajo.

Si se aborda la actualización como una única estimación, se produce un único modo de fallo: el equipo vota 13, se queda sin tiempo en la tercera semana y entrega un código a medio migrar que presenta los errores del nuevo marco y las convenciones del antiguo. Lo más sensato es dividir la actualización en una secuencia de historias más pequeñas, cada una de las cuales se pueda estimar de forma independiente, con la actualización en sí misma como proyecto global.

Lo que se dice en la sala

Ingeniero: «El codemod se encarga de casi todo».

Titular: «¿La mayor parte de qué? ¿Qué es lo que no gestiona?»

SRE: «¿Ya son compatibles todas nuestras dependencias con la nueva versión?»

Pregunta: «¿Cuál es nuestra estrategia de pruebas de regresión para el cambio?»

PM: «¿Vamos a entregar algo más en este sprint, o este es el sprint?»

Preguntas que conviene plantearse antes de votar

• ¿Cuántos cambios que afectan a la compatibilidad se aplican a nuestro código fuente (lea el registro de cambios y cuéntelos)?
• ¿Las dependencias de los componentes relacionados son compatibles con la versión de destino, o debemos aplicar la técnica de cascada?
• ¿Codemod o manualmente? ¿Cuál es el grado de cobertura de Codemod?
• ¿Es adecuada la cobertura de las pruebas en las superficies modificadas, o debemos añadir pruebas primero?
• ¿Qué estrategia de reversión se aplicaría si las cosas salieran mal a mitad del sprint?
• ¿Un PR o varios? Si son varios, ¿cuál es el orden de dependencia?

El resultado adecuado de esta conversación suele ser: «Esto no es una historia, es un proyecto, así que planifiquémoslo como tal», y a continuación dividirlo en partes que cada miembro del equipo pueda estimar en comparación con una historia de referencia.

No asigne un único número a una actualización importante. Divídala en historias y, a continuación, evalúe el alcance de cada una de ellas.

Consulte técnicas de estimación para trabajos más imprecisos o de mayor envergadura, y cómo estimar un pico de investigación para conocer la investigación que debe preceder a la estimación. Eche un vistazo a los demás ejemplos prácticos de estimación.