Estimación de una actualización del marco
Cómo estimar una actualización del marco de trabajo: por qué un cambio de versión importante es un proyecto, no una incidencia, y cómo dividirlo en historias que se puedan cuantificar de forma realista.
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 tamaño 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 ellas estimable de forma independiente, con la propia actualización como proyecto marco.
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 lanzar 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 entre pares son compatibles con la versión de destino o debemos aplicar la cascada?
- ¿Codemod o manualmente? ¿Cuál es el nivel 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», para luego 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 las técnicas de estimación para trabajos más imprecisos o de mayor envergadura, así como la estimación de una fase de investigación intensiva que debe preceder a la estimación. Eche un vistazo a los demás ejemplos de estimación resueltos.