01
Primer plan
Qué se queda, qué cambia
Reconstruir, encapsular o retirar, decidido por componente. Lo que debe quedar idéntico queda por escrito. También cada cambio intencionado.
Modernización
Un núcleo nuevo bajo las pantallas que sus clientes ya usan.
El negocio no puede parar. El sistema, aun así, tiene que cambiar. Un enjambre reconstruye el núcleo en paralelo mientras un ingeniero responsable se asegura de que no se rompa nada de lo que sus clientes necesitan.
Por qué las reescrituras se atascan.
El equipo crece, la fecha se mueve y el sistema antiguo sigue, porque nadie se fía del nuevo.
Producción
El sistema genera dinero cada día. Un programa clásico le pide que espere dieciocho meses.
Regresión
Nadie puede listar lo que no puede romperse. Así que se prueba todo a mano, o no se prueba.
Deriva
La reescritura se convierte en un segundo producto con su propio backlog. El antiguo sigue siendo el que usan los clientes.
Mientras corre
Qué puede ver en cualquier momento.
Dónde vive
Su nube. Su repositorio.
- 01 Aplicación Web, móvil e informes corren en sus cuentas.
- 02 Repositorio El primer commit ya es suyo.
- 03 Alojamiento Nunca lo alojamos. No hay nada que deshacer cuando nos vamos.
El trabajo
Cómo se ejecuta, en orden.
02
Contratos
Fijar las interfaces
Las API, los eventos y los informes se fijan primero. El enjambre construye contra ellos. El núcleo nuevo no puede inventarlos después.
03
Reconstrucción en paralelo
El mayor riesgo primero
Los recorridos cuyo fallo más lamentaría se reconstruyen primero, cada uno con pruebas que demuestran que el comportamiento antiguo se mantiene.
04
Cambio
Apagar el núcleo antiguo
El tráfico se mueve componente a componente. El camino antiguo se apaga solo cuando su equipo ha aceptado los archivos.
01
Comprobaciones
Lo que no puede romperse es una prueba, no una esperanza.
Cada recorrido de cliente designado tiene una prueba antes de que el enjambre toque el núcleo. Las pruebas corren en cada cambio. Un fallo detiene la publicación, diga lo que diga la fecha.
Comprobaciones
Qué bloquea una comprobación fallida
- 01 Publicación Una compilación fallida no se publica. Ni siquiera en preproducción.
- 02 Producción Una comprobación de seguridad o de rendimiento fallida no pasa a producción.
- 03 Corte No hay corte sin un rollback escrito y ensayado.
02
Riesgo
Usted no dirige la reescritura para luego cargar con cada fallo.
Un ingeniero responsable responde del resultado hasta que su equipo acepta. No un proyecto que usted gestiona, ni un proveedor al que persigue.
Quién lo sostiene
El riesgo de entrega tiene un único responsable
- 01 Horas Muchos proveedores, muchas manos. Cada fallo es suyo.
- 02 UNIT01 Un ingeniero responsable responde del resultado hasta que usted acepta.
- 03 Producción Usted decide cuándo se mueve el tráfico. Nosotros hacemos que pueda hacerlo.
03
Aceptación
El núcleo antiguo se queda hasta que su equipo acepta.
Un despliegue no es una entrega. Manuales de operación, monitorización y riesgos abiertos están primero en su repositorio. Entonces se apaga el núcleo antiguo.
Aceptación
Qué hay en su repositorio antes de firmar
- 01 Pruebas Escritas con el código. Se ejecutan en su pipeline.
- 02 Manuales de operación Cómo operarlo. A quién llamar. Cómo hacer rollback.
- 03 Riesgos Cada punto abierto tiene un responsable. Nada se descubre después.
En el primer plan
Qué queda escrito antes de empezar.
El primer plan nombra cada uno de estos puntos. Es un documento: puede aceptarlo, editarlo o rechazarlo.
Mapa
Reconstruir / encapsular / retirar
Decidido por componente en el primer plan. No se descubre en el sexto mes.
Comprobaciones
Qué tiene que seguir funcionando
Los recorridos designados tienen criterios de superación antes de tocar el núcleo. Son pruebas, no una lista.
Cambios
Lista de cambios intencionados
La aceptación nombra lo que es nuevo. Un cambio no listado es un defecto.
Ingeniero responsable
Una persona designada
El ingeniero que manda consta en el contrato. Conoce a esta persona antes de firmar.
Archivos
En su repositorio
Código, pruebas, manuales de operación, monitorización y riesgos abiertos. Ahí antes de la aceptación.
PI
Código y marca se quedan con usted
Cedidos en el contrato. Nunca alojamos el producto ni nos lo quedamos.
Preguntas que nos hacen
Preguntas habituales.
01
¿Por qué es más rápido que si lo hace su propio equipo?
Su equipo tiene el día a día. Un enjambre no. Reconstruye componentes y escribe sus pruebas en paralelo, y el ingeniero responsable lo mantiene dentro de las interfaces que usted fijó.
02
¿Es un rediseño de interfaz?
Solo si el riesgo está en la interfaz. Lo habitual es que esté en servicios y datos. El primer plan dice cuál.
03
¿Se conserva cada comportamiento?
Conservamos lo que usted nombra, y lo demostramos con pruebas. El resto es un cambio listado que usted acepta.
04
¿Se pueden conservar partes del sistema antiguo?
Sí. Encapsular y retirar son opciones de pleno derecho, no un fracaso.
05
¿Y si el proveedor actual se queda?
Bien, si el resultado sigue teniendo un único responsable. En la primera semana diremos si el reparto es inseguro.
06
¿Cuándo lo toma operaciones?
Cuando acepta los archivos en su repositorio. No cuando hay un despliegue.
Otro trabajo
La misma forma de trabajar, en otro sistema.
Siguiente paso
Díganos qué tiene que pasar a producción, y cuándo.
Le enviamos un primer plan: qué significa hecho, con sus palabras, cuánto cuesta y cuándo. La decisión es suya.