Lanzamientos Pequeños
Entrega valor temprano y con frecuencia. Obtén retroalimentación antes de que sea demasiado tarde para cambiar de rumbo.
1Por Qué Lanzar en Pequeño
XP aboga por lanzamientos pequeños y frecuentes. Esto era radical en 1999 cuando los lanzamientos anuales eran normales. Sigue siendo radical en muchas organizaciones.
Beneficios de los lanzamientos pequeños:
Retroalimentación más rápida: Los clientes ven software real más pronto. Pueden decirte qué está mal antes de que hayas construido demasiado de lo incorrecto.
Riesgo reducido: Cada lanzamiento es una apuesta pequeña. Si falla, has perdido semanas, no meses. Puedes corregir el rumbo rápidamente.
Entrega de valor más rápida: Las funcionalidades que están terminadas se usan. Una funcionalidad lanzada hoy es mejor que una funcionalidad esperando un gran lanzamiento en seis meses.
Moral mejorada: El equipo ve su trabajo en uso. Lanzar es satisfactorio. Los ciclos de lanzamiento largos drenan la motivación.
Mejor calidad: Lanzamientos más pequeños significan cambios más pequeños. Los cambios más pequeños son más fáciles de probar, más fáciles de depurar y menos propensos a causar problemas.
Mínimo Viable en Todo
XP inventó el producto mínimo viable (MVP) antes de que existiera el término. Kent Beck lo llamó 'el lanzamiento más pequeño que tiene sentido.'
2Qué Tan Pequeño Es Pequeño
La frecuencia de lanzamiento correcta depende del contexto, pero impulsa lanzamientos más pequeños y frecuentes de lo que se siente cómodo.
Ejemplos de frecuencia:
- Diario (despliegue continuo): Cada commit va a producción
- Semanal: Lanzamiento al final de cada iteración
- Quincenal: Lanzamiento después de cada dos iteraciones
- Mensual: Ciclo de lanzamiento mensual
Cada paso más pequeño es mejor, hasta el punto donde la sobrecarga del lanzamiento domina. Si lanzar toma un día completo de trabajo manual, lanzar diariamente es impráctico. Arregla primero el proceso de lanzamiento.
Señales de que estás lanzando con poca frecuencia:
- Los lanzamientos dan miedo (cambió demasiado)
- Los problemas de integración son comunes (lotes grandes)
- Los clientes esperan meses por correcciones
- El equipo tiene "semanas de fusión"
3Requisitos Técnicos
Los lanzamientos pequeños requieren inversión técnica:
Pruebas automatizadas: No puedes lanzar frecuentemente si las pruebas toman semanas. Las pruebas automatizadas rápidas y completas son esenciales.
Integración continua: El código debe integrarse sin problemas. Las ramas de larga duración son incompatibles con lanzamientos frecuentes.
Automatización del despliegue: Los lanzamientos deben ser con un botón. Los pasos de despliegue manual te ralentizan e introducen errores.
Feature flags: Las funcionalidades incompletas pueden fusionarse pero ocultarse de los usuarios. Esto permite lanzamientos pequeños incluso cuando las funcionalidades abarcan múltiples iteraciones.
Estrategia de migración de base de datos: Los cambios de esquema deben ser desplegables sin romper el código existente. Usualmente esto significa migraciones compatibles hacia adelante.
Monitoreo y rollback: Cuando algo sale mal, necesitas saberlo inmediatamente. Y necesitas poder revertir rápidamente.
Estas no son prácticas de XP per se—son prácticas modernas de DevOps que habilitan la visión original de XP de entrega continua.
El equipo lanza a producción cada martes. El proceso está automatizado y toma 10 minutos. Los feature flags ocultan el trabajo incompleto. El rollback es de un clic.
Los lanzamientos ocurren trimestralmente. Cada lanzamiento es precedido por un 'congelamiento de código' y 2 semanas de pruebas manuales. El día de lanzamiento involucra a 10 personas y toma 8 horas. El rollback requiere restaurar respaldos de base de datos.
4De Lanzamientos a Despliegue Continuo
El extremo lógico de los lanzamientos pequeños es el despliegue continuo: cada commit que pasa las pruebas va directamente a producción.
Esto suena aterrador. Pero con las prácticas correctas, es en realidad más seguro que los lanzamientos grandes:
- Cada cambio es diminuto y fácil de entender
- Si algo se rompe, sabes exactamente qué lo causó
- El rollback es trivial (el último despliegue fue hace minutos)
- No hay estrés del "día de lanzamiento" ni despliegues fuera de horario
El despliegue continuo requiere:
- Cobertura de pruebas muy alta
- Builds muy rápidos (10 minutos máximo)
- Feature flags robustos
- Monitoreo excelente
- Una cultura de calidad (sin atajos)
No todos los equipos están listos para esto. Pero todos los equipos pueden moverse hacia lanzamientos más pequeños y frecuentes. Comienza lanzando el doble de frecuente. Luego el doble de frecuente otra vez. Ve qué tan lejos puedes llegar.
Si el despliegue continuo se siente imposible, pregunta por qué. Los obstáculos que identifiques son usualmente cosas que deberías arreglar de todos modos: pruebas lentas, procesos manuales, código frágil.
- Los lanzamientos pequeños entregan valor más rápido y reducen el riesgo
- Lanza tan frecuentemente como tu proceso lo permita—luego mejora el proceso
- Los lanzamientos pequeños requieren pruebas automatizadas, CI y automatización del despliegue
- Los feature flags permiten que el trabajo incompleto se fusione de forma segura
- El despliegue continuo es el extremo lógico—y a menudo más seguro que los lanzamientos grandes
- •Pensar que los lanzamientos pequeños requieren funcionalidades terminadas (usa feature flags)
- •Procesos de lanzamiento manuales que hacen los lanzamientos pequeños imprácticos
- •Esperar 'suficientes' cambios antes de lanzar
- •Tratar el día de lanzamiento como un esfuerzo heroico en lugar de automatización rutinaria