Estimación de una actualización de una dependencia

Los parches y las actualizaciones menores son ruido. Las actualizaciones mayores en N bibliotecas suponen N picos: calcule el peor de ellos, no la media.

Las actualizaciones de dependencias se presentan en dos formas que parecen idénticas en la salida del gestor de paquetes. La primera: un conjunto de parches y actualizaciones menores que el equipo debería agrupar, someter a la suite de pruebas y fusionar en una única solicitud de incorporación de cambios (PR) bastante monótona. Esa solicitud tiene una prioridad de 1, a veces de 2, y la única razón para votar sobre ella es confirmar que el equipo está de acuerdo en que resulta tediosa. La segunda variante: una actualización mayor en una o más bibliotecas, en la que el registro de cambios incluye una sección de «cambios que rompen la compatibilidad» y el equipo debe leerla. Esa es la historia que se oculta a plena vista. El equipo le otorga una puntuación de 3 porque «solo es una actualización» y la implementa con una puntuación de 13 tres sprints más tarde.

Esto no es una actualización del marco de trabajo. Una actualización del marco de trabajo es una biblioteca en torno a la cual se ha planificado durante un trimestre; el equipo sabe que se trata de un proyecto. Una actualización de dependencias es esa solicitud de mantenimiento discreta que alguien presenta porque el análisis de seguridad ha detectado seis bibliotecas, y nadie ha leído los registros de cambios. La trampa está en la distribución: de las seis actualizaciones, cuatro son insignificantes, una es una exportación renombrada y otra supone un rediseño completo de la API. La estimación que las promedia es errónea en ambos sentidos.

Lo que se dice en la sala

Ingeniero A: «Son seis baches. Dos cada uno. Trece en total».

Titular: «¿Son todos menores de edad?»

Ingeniero A: «Tres menores, tres mayores».

Ingeniero B: «¿Alguien ha leído los registros de cambios más importantes?»

Ingeniero A: «…déjeme echar un vistazo».

Titular: «Aún no disponemos de una estimación. Se han registrado tres picos».

El titular es acertado. No hay una cifra concreta para esta historia porque no hay una sola historia. Los pequeños contratiempos se agrupan en su propio «paquete» menor; cada contratiempo importante supone su propio pico hasta que alguien haya leído el registro de cambios y sepa qué es lo que está fallando.

Preguntas que conviene plantearse antes de votar

¿Cuántas actualizaciones hay y cuál es el desglose por versiones principales, secundarias y parches?
¿Ha leído alguien los registros de cambios de las versiones principales?
¿Alguna de estas bibliotecas pertenece al equipo, en lugar de a los proveedores?
¿Existe algún conflicto de dependencia transitiva que obligue a que se produzcan simultáneamente?
¿Cuál sería la solución de reversión si una de las actualizaciones provocara una interrupción en la producción?
¿Tiene el equipo de seguridad un plazo límite, o se trata de una deuda técnica?

Si la respuesta a «¿alguien ha leído los registros de cambios?» es «no», la estimación no es realista. Asigne un pico limitado a cada cambio importante, identifique qué es lo que realmente falla y, a continuación, vuelva a estimar la implementación en función de lo que haya descubierto.

No calcule las actualizaciones de las dependencias basándose únicamente en el número de versiones. Lea primero los registros de cambios y, a continuación, evalúe lo que haya encontrado.

Consulte cómo estimar una actualización del marco de trabajo para la variante de versión principal con una sola biblioteca, así como los demás ejemplos prácticos de estimación. Organice una sesión gratuita de «planning poker» una vez que los «spikes» hayan aclarado qué es lo que realmente va a cambiar.