Estimación de una actualización del marco de trabajo
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 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 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? ¿Debería leer el registro de cambios y contarlos?
- ¿Las dependencias entre pares son compatibles con la versión de destino, o debemos aplicar la cascada?
- ¿Codemod o revisión manual? ¿Cuál es el alcance de Codemod?
- ¿Es adecuada la cobertura de las pruebas en las superficies modificadas, o debemos añadir pruebas primero?
- ¿Cuál sería la estrategia de retroceso 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; 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 «spike» 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.