Cómo medir el avance de una migración

"Vamos más o menos por la mitad" es una sensación. La dirección necesita un número que salga del código y una tendencia que anticipe el final. Estas son las medidas que funcionan y el reporte que las lleva.

Cómo es una buena medida de avance

Una medida útil tiene tres propiedades. Se cuenta desde el código o desde producción, así nadie tiene que estimarla. Solo se mueve cuando algo está realmente terminado. Y llega a un valor final claro: cero legacy, o todas las pantallas.

Los porcentajes dichos de memoria, los story points y las líneas de código escritas fallan en al menos una de estas pruebas.

Las cuatro medidas centrales

1. Pantallas migradas

Es el número principal. Defínelo de forma estricta:

• La pantalla está publicada para todos los usuarios en el stack nuevo.
• La versión legacy está borrada.
• El feature flag está eliminado.

Una pantalla "lista pero sin publicar" cuenta como no migrada. Toma el denominador del inventario hecho en el diagnóstico y registra sus cambios de forma abierta: pantallas borradas por falta de uso y pantallas agregadas por funcionalidades nuevas.

Cómo obtenerla. Mantén el inventario como una tabla simple, con una fila por pantalla y un estado. Actualízala cuando se integre el pull request que borra el código legacy.

2. Huella legacy

Esta medida muestra al framework antiguo saliendo del producto. Es difícil de discutir. Formas útiles:

• El tamaño del bundle legacy, tomado del resultado del build.
• La cantidad de registros legacy en el código: controladores, directivas, componentes y servicios. Un script corto que busca en el código fuente lo entrega en segundos.

Elige una o dos y grafícalas en el tiempo. La línea debe bajar en cada fase y terminar en cero.

3. Defectos

La dirección quiere saber si la migración está perjudicando a los usuarios.

• Regresiones encontradas en pantallas migradas después de publicar, por fase.
• Rollbacks: cuántas veces se apagó un flag.
• Regresiones abiertas de severidad alta. La meta es ninguna en cada revisión de fase.

Cómo obtenerla. Agrega una etiqueta en el gestor de incidencias para los errores causados por la migración. Acuerda quién la aplica. Sin la etiqueta, a la migración se le atribuyen todos los errores del producto o ninguno.

4. Frecuencia de publicación

Uno de los propósitos de modernizar es entregar con más facilidad. Mide con qué frecuencia se publica el frontend y cuánto tarda un cambio desde que se integra hasta que llega a producción. Durante la migración, estos números muestran que la entrega no se detuvo. Después muestran si la inversión la mejoró. Registra los valores antes de empezar la migración, para tener tu propia línea base.

Medidas de apoyo

De las medidas a una proyección

Divide las pantallas restantes por el ritmo reciente de pantallas completadas. Presenta el resultado como un rango y actualízalo al cierre de cada fase. Una proyección construida sobre trabajo terminado genera confianza, porque la dirección puede ver cómo converge. El razonamiento está en cuánto tarda una migración de AngularJS.

El reporte mensual

Una página alcanza. Mantén el mismo formato todos los meses para que los lectores puedan comparar.

1. Titular. Pantallas migradas sobre el total, y el cambio desde el mes anterior.
2. Gráfico de burn-down. Pantallas legacy restantes en el tiempo, con el rango proyectado.
3. Huella legacy. El tamaño del bundle o la cantidad de registros, como una línea.
4. Calidad. Regresiones y rollbacks del mes. Casos abiertos de severidad alta.
5. Entregado. Los módulos o pantallas que se publicaron, en términos del negocio.
6. Lo que sigue. Lo que va a entregar el próximo mes.
7. Riesgos y decisiones. Temas que necesitan al sponsor, cada uno con una recomendación.

Qué evitar

• Porcentaje de avance a ojo. Se queda en "casi listo" durante meses.
• Contar pantallas construidas pero sin publicar. El trabajo sin publicar no ha entregado nada y todavía tiene riesgo.
• Esconder los cambios del denominador. Si el inventario creció, muéstralo. Los cambios sin explicación destruyen la confianza más rápido que un avance lento.
• Solo buenas noticias. Un reporte sin riesgos no resulta creíble.

Una audiencia fácil de olvidar

Los auditores y los clientes también leen este reporte. El mismo gráfico de burn-down que informa al sponsor es la evidencia que pide un auditor, como se describe en la guía de seguridad y cumplimiento.

Prepáralo temprano

Crea la tabla de inventario, la etiqueta del gestor de incidencias y el script de huella durante el piloto. La estructura de fases contra la que se reporta está en la plantilla de hoja de ruta. Las medidas que se agregan a mitad de camino no tienen línea base, y los primeros meses de avance quedan invisibles.

Más en esta sección

• Después de la migración: mantener el frontend al día
• Costo de una migración de AngularJS: qué lo determina y cómo estimarlo
• ¿Cuánto tarda una migración de AngularJS?
• Riesgo de seguridad y cumplimiento de AngularJS