Cómo seguir entregando funcionalidades durante una migración
Una migración incremental solo tiene sentido si el producto sigue avanzando. Eso exige un reparto claro de capacidad, reglas simples sobre quién puede cambiar qué y unas pocas reuniones regulares.
La promesa y la trampa
La razón principal para migrar de forma incremental es que el desarrollo de funcionalidades no se detiene. La trampa es que ahora dos flujos de trabajo tocan el mismo código. Sin reglas, una funcionalidad cae en una pantalla legacy la misma semana en que se está migrando, y alguien la construye dos veces.
Hay tres cosas que mantienen sanos ambos flujos: un reparto deliberado de capacidad, reglas de congelamiento por módulo y una coordinación liviana.
Repartir la capacidad
Hay tres modelos que funcionan. Elige uno a propósito y déjalo por escrito.
| Modelo | Cómo funciona | Fortaleza | Debilidad |
|---|---|---|---|
| Grupo dedicado a la migración | Unas pocas personas, internas o externas, trabajan solo en la migración | Avance constante, patrones consistentes | El conocimiento puede quedarse en el grupo pequeño |
| Cuota por equipo | Cada equipo reserva una parte de cada sprint para migrar sus propios módulos | Los equipos aprenden el stack nuevo y son dueños del resultado | La cuota reservada es lo primero que se recorta cuando hay presión de fechas |
| Rotación | Un grupo central se mantiene, y desarrolladores de los equipos de producto se suman por una fase | Reparte el conocimiento y mantiene el impulso | Requiere inducción en cada rotación |
Sea cual sea el modelo, protege la asignación. Una migración que solo recibe el tiempo sobrante se detiene en el primer trimestre exigente. Acuerda el reparto con el sponsor y revísalo en cada punto de control de la hoja de ruta.
Reglas de congelamiento por módulo
Un congelamiento debe ser acotado y corto. Congelar todo el producto anula el propósito. Congelar un módulo durante las semanas que toma migrarlo es fácil de sobrellevar.
Regla 1: Las pantallas nuevas se construyen en el stack nuevo. Desde el día en que el piloto está en producción, nadie agrega una pantalla al código legacy. Así la parte legacy deja de crecer.
Regla 2: Un módulo en migración queda congelado para funcionalidades. Mientras un módulo está en la fase actual, a su versión legacy solo entran correcciones críticas. Las solicitudes de funcionalidades para ese módulo esperan hasta que sus pantallas estén publicadas en el stack nuevo.
Regla 3: Las correcciones críticas van a las dos versiones. Si hay que corregir un error durante el congelamiento, la corrección se aplica a la pantalla legacy y a la migrada. Quien la hace avisa al líder de migración el mismo día.
Regla 4: Los módulos fuera de la fase actual están abiertos. Ahí las funcionalidades siguen como siempre.
Regla 5: Los congelamientos tienen fechas. Anuncia el inicio y el fin planificado del congelamiento de cada módulo. Si el fin se corre, dilo temprano.
El error caro es construir una funcionalidad grande en un módulo legacy poco antes de migrar ese módulo. La funcionalidad se construye una vez en el framework antiguo y otra vez en el nuevo. Planifica el orden para que esto no ocurra.
Alinea los dos roadmaps
- Migra antes de las funcionalidades grandes. Si un módulo tiene una funcionalidad importante planificada para el próximo trimestre, mígralo en este. La funcionalidad se construye una sola vez, sobre código nuevo.
- Deja los módulos tranquilos para después. Un módulo sin cambios planificados puede esperar sin costo.
- Respeta los calendarios del negocio. No programes la migración de un módulo en su período de mayor uso, como el cierre de mes para facturación.
Rituales de coordinación
- Reunión semanal de migración. Líder de migración, líder técnico y product owner. Qué pantallas se movieron, cuáles siguen, qué preguntas están abiertas y qué congelamientos empiezan o terminan.
- Inicio de fase. Antes de cada fase, una sesión breve con los equipos afectados: alcance, fechas de congelamiento y quién responde las preguntas sobre reglas de negocio.
- Demo de fase. Al cierre de cada fase, muestra las pantallas migradas a los interesados. Mantiene el apoyo al programa y saca a la luz comportamientos que se pasaron por alto.
- Un tablero visible. Una página que muestre cada módulo como legacy, en migración o migrado, con las fechas de congelamiento. Quien planifique trabajo la revisa primero.
Cómo manejar lo urgente
Las solicitudes urgentes van a llegar. Decide de antemano cómo se manejan:
- Los incidentes de producción tienen prioridad sobre el trabajo de migración, siempre.
- Las funcionalidades urgentes en un módulo abierto avanzan de forma normal.
- Las funcionalidades urgentes en un módulo congelado van al sponsor, que elige entre esperar la pantalla migrada y pausar la migración de ese módulo. Las dos opciones son aceptables. Hacer ambas cosas a la vez es la opción que hay que evitar.
Señales de que el equilibrio se perdió
- La cuota de capacidad para la migración se saltó dos sprints seguidos.
- Las funcionalidades se implementan dos veces con frecuencia.
- La cantidad de pantallas legacy está subiendo.
Sigue estas señales junto con las métricas de medir el avance de la migración. Cuando aparezca una, llévala al próximo punto de control. La lista más amplia de riesgos está en riesgos de migración y cómo reducirlos.
Más en esta sección
- Cómo medir el avance de una migració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?
¿Planeas una migración o una plataforma de microfrontends?
En una llamada de 20 minutos me cuentas tu situación y te digo cómo la abordaría. Si todavía no vale la pena, también te lo digo.
Escríbeme por LinkedIn