Capítulo 19: Release final
Capítulo 19: Release final
Viernes de la octava semana. Ocho semanas desde que cuatro personas que no se conocían se sentaron en una sala de reuniones. Hoy despliegan a producción. No es un final: es un principio. Pero es un principio con un producto funcionando, probado y construido con disciplina.
Anterior: Release Planning | Siguiente: Lecciones aprendidas
Los últimos días
La semana fue intensa pero controlada. No hubo crunch. No hubo horas extra. Las stories planificadas se completaron en el ritmo habitual.
El equipo de Martín probó el sistema durante dos días en pre-producción. Encontraron tres bugs menores: un problema de visualización en pantallas pequeñas, un texto que no se traducía correctamente y un filtro que no se reseteaba al cambiar de tablero. Diego y Elena los arreglaron en pair en una mañana.
Carlos (TL): “Tres bugs menores en dos días de prueba con usuarios reales. Hace seis semanas nos habría dado pánico. Hoy es rutina.”
Ana (PO): “Todos los criterios de release están cumplidos. ¿Estamos listos?”
Carlos (TL): “CI está verde. Los tests pasan. Martín dio el visto bueno. Estamos listos.”
El deploy
A las 10 de la mañana, el equipo se reúne frente a la pantalla de Elena. No hay ceremonia: Elena ejecuta el deploy a producción como lo han hecho en cada iteración al entorno de pre-producción. La diferencia es que esta vez es real.
Elena (Dev): “Deploy ejecutado. Pipeline en progreso.”
El equipo mira la pantalla. Los tests corren. Los pasos del pipeline avanzan. Luz verde.
Diego (Dev): “¿Eso es todo?”
Carlos (TL): “Eso es todo. Si tu pipeline de CI es confiable y lo usas todos los días, el deploy a producción es solo otro paso.”
Elena (Dev): “En mi proyecto anterior, el deploy era un evento de todo el día. La gente traía café y se preparaba para una noche larga.”
Carlos (TL): “Porque integraban una vez al mes. Nosotros integramos varias veces al día. La distancia entre pre-producción y producción es casi cero.”
Primeros usuarios reales
Ana envía un correo a los tres equipos que van a empezar a usar el Kanban. A las 11 de la mañana, los primeros usuarios entran al sistema.
El equipo monitorea sin intervenir. Ven cómo se crean tableros, cómo las personas agregan columnas con nombres que no habían imaginado (“Ideas Locas”, “Esperando al Jefe”, “Hecho-Hecho de verdad”), cómo mueven tarjetas con drag and drop.
Diego (Dev): “Alguien puso un emoji en el nombre de una tarjeta.”
Elena (Dev): “Ana dijo que sí a los emojis, ¿recuerdas?”
Ana (PO): “Lo recuerdo. Me alegra haberlo permitido. La gente se apropia de la herramienta cuando puede personalizarla.”
A mediodía, un usuario intenta exceder el límite WIP de una columna. Aparece el mensaje que Elena diseñó: “Esta columna tiene un límite de 3 tarjetas. Mueve o completa una tarjeta antes de agregar otra.”
Ana (PO): “Funciona. Los límites WIP son reales. Esto es un Kanban de verdad.”
Un bug menor en vivo
A las 2 de la tarde, un usuario reporta que al buscar tarjetas, los acentos no funcionan correctamente. Buscar “diseño” no encuentra “diseño” si se escribe “diseno”.
Diego (Dev): “Es un bug de normalización de texto. No lo previmos.”
Elena (Dev): “¿Lo arreglamos ahora?”
Carlos (TL): “Es menor. ¿Bloquea a alguien?”
Ana (PO): “No bloquea, pero es molesto.”
Carlos (TL): “Lo arreglamos hoy en pair. Test primero, como siempre.”
Diego y Elena escriben un test que busca “diseño” usando “diseno”. Rojo. Agregan normalización de texto. Verde. Empujan. CI verde. Despliegan el arreglo a producción.
Diego (Dev): “Desde el reporte hasta el arreglo en producción: una hora.”
Carlos (TL): “Eso es posible porque nuestro pipeline es confiable, nuestros tests son completos y nuestro proceso de deploy es el mismo que usamos todos los días.”
Ana comunica el éxito
A las 4 de la tarde, Ana envía un mensaje a los stakeholders.
Ana (PO): “Equipo directivo: el Kanban está en producción. Tres equipos lo están usando. Las funcionalidades incluyen tableros personalizables, columnas con límites WIP, tarjetas con asignación, drag and drop, búsqueda y registro de historial. Un bug menor fue encontrado y arreglado en una hora.”
La directora de operaciones responde: “Impresionante. ¿Cuándo podemos hablar de la siguiente fase?”
Ana (PO): “Siguiente fase. Eso significa que quieren más. Es la mejor señal de éxito.”
El cierre del día
A las 5:30, el equipo está frente al tablero de la pizarra. Todas las stories están en “Hecho”. Ocho semanas de trabajo representadas en tarjetas de índice con marcador grueso.
Carlos (TL): “Nos vamos a las 6. Como siempre.”
Diego (Dev): “Hoy podríamos celebrar un poco…”
Carlos (TL): “Mañana es sábado. Celebren todo lo que quieran. Pero hoy, sustainable pace hasta el final.”
Elena (Dev): “Consistent hasta el final. Me gusta.”
Ana (PO): “El lunes hacemos la retrospectiva final. Hoy, gracias.”
Práctica XP del capítulo
Small Releases (llevado al extremo): El release final no fue un evento traumático sino la continuación natural de un proceso que el equipo ejecutaba todos los días. Kent Beck dice que el release debe ser lo más anticlimático posible: si cada integración es un mini-release verificado, el release real es solo cuestión de cambiar la URL de destino. El equipo lo logró porque invirtió en CI desde el día uno, escribió tests para cada comportamiento y desplegó frecuentemente durante ocho semanas.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Comunica el éxito a stakeholders, monitorea con el equipo |
| Carlos | Supervisa el deploy, mantiene la calma, refuerza sustainable pace |
| Diego | Arregla bug en pair con Elena, monitorea usuarios |
| Elena | Ejecuta el deploy, arregla bug en pair con Diego |
Anterior: Release Planning | Siguiente: Lecciones aprendidas