Capítulo 18: Release Planning
Capítulo 18: Release Planning
Lunes de la séptima semana. Quedan dos iteraciones para el release. El equipo sabe exactamente cuánto puede hacer gracias a seis semanas de datos reales. Hoy transforman ese conocimiento en un plan de entrega que Ana pueda llevar a los stakeholders con confianza.
Anterior: Retrospectiva profunda | Siguiente: Release final
Lo que hay y lo que falta
Carlos dibuja dos listas en la pizarra. A la izquierda, lo que ya funciona. A la derecha, lo que falta.
Funciona:
- Crear y gestionar tableros
- Columnas personalizables
- Tarjetas con nombre y descripción
- Mover tarjetas en cualquier dirección
- Asignar personas a tarjetas
- Etiquetas de equipo con filtro
- Barra de deshacer movimiento
- Validaciones de datos
Falta (backlog):
- Límites WIP en columnas
- Swimlanes visuales reales
- Drag and drop para mover tarjetas
- Búsqueda de tarjetas
- Notificaciones de cambios
- Historial de movimientos
- Exportar tablero
- Permisos por usuario
Ana (PO): “Eso es mucho backlog para dos semanas.”
Carlos (TL): “Nuestra velocity promedio es siete puntos por semana. Tenemos dos semanas. Catorce puntos. Necesitamos elegir las stories que más valor den en catorce puntos.”
Ana prioriza para el MVP
Ana estudia la lista. Piensa en lo que los stakeholders necesitan para considerar el producto “lanzable”.
Ana (PO): “Los límites WIP son la esencia de un Kanban. Sin ellos, es un tablero de tareas genérico. Los necesito.”
Carlos (TL): “¿Cuánto estimamos?”
Elena (Dev): “Tres puntos. Necesitamos validar en el dominio, mostrar en la pantalla y manejar el caso donde alguien intenta exceder el límite.”
Ana (PO): “Drag and drop. El botón funciona, pero los usuarios esperan poder arrastrar tarjetas.”
Diego (Dev): “Cuatro puntos. La lógica ya existe, pero la interacción visual es compleja.”
Ana (PO): “¿Cuatro? Es mucho.”
Diego (Dev): “El drag and drop tiene casos de borde: qué pasa si sueltas fuera de una columna, qué pasa si sueltas en una columna con límite WIP lleno, qué pasa con la accesibilidad de teclado.”
Carlos (TL): “Confiemos en Diego. Lleva seis semanas estimando y su precisión es buena.”
Ana suma: tres más cuatro son siete. Le queda una semana de siete puntos.
Ana (PO): “Con los siete puntos restantes: búsqueda de tarjetas es tres puntos. Historial de movimientos es cuatro. Me alcanzan para ambos.”
Elena (Dev): “El historial podríamos hacerlo en tres si no incluimos la pantalla visual y solo registramos los datos.”
Ana (PO): “¿Y la pantalla visual después?”
Elena (Dev): “Exacto. Registrar datos ahora, mostrarlos bonito después.”
Ana (PO): “Me gusta. Simple Design aplicado al producto, no solo al código.”
Negociando con stakeholders
Ana tiene una reunión con la directora de operaciones a la tarde. Antes de ir, prepara su argumento con el equipo.
Ana (PO): “Voy a decirle que el release incluye: límites WIP, drag and drop, búsqueda y registro de historial. ¿Es una promesa segura?”
Carlos (TL): “Basándome en seis semanas de datos: sí. Nuestra velocity ha sido estable en siete-ocho puntos. Catorce puntos en dos semanas es alcanzable.”
Ana (PO): “¿Y las swimlanes y los permisos?”
Carlos (TL): “Post-release. No son necesarios para el MVP.”
Diego (Dev): “Podemos mencionarlos como mejoras futuras. Eso muestra que tenemos un roadmap, no que estamos improvisando.”
Ana sale a la reunión con datos. No con esperanzas, no con promesas infladas: con una velocity verificada y un scope negociado.
Vuelve una hora después.
Ana (PO): “La directora está de acuerdo. Límites WIP, drag and drop, búsqueda e historial. Las swimlanes y los permisos van en la siguiente fase. Felicitó al equipo por la transparencia.”
Carlos (TL): “Eso es lo que pasa cuando dices la verdad consistentemente durante seis semanas. La confianza se construye, no se declara.”
Criterios de release
El equipo define qué debe ser verdad para que el release suceda.
Carlos (TL): “Necesitamos criterios claros. ¿Cuándo consideramos que estamos listos para lanzar?”
El equipo acuerda:
- Todas las stories del release están completas y pasan la Definition of Done
- Cero bugs conocidos de severidad alta
- Los bugs de severidad baja están documentados como stories futuras
- Ana ha hecho una aceptación final del producto
- El equipo de Martín ha probado en un entorno de pre-producción durante al menos dos días
Elena (Dev): “¿Dos días de prueba por usuarios reales?”
Ana (PO): “Sí. Martín ya está usando el sistema. Le pido que sea nuestro beta tester oficial.”
Carlos (TL): “Feedback de usuarios reales antes del release. Eso es XP hasta el final.”
Práctica XP del capítulo
Release Planning: Kent Beck describe el Release Planning como el proceso de definir qué se incluye en un release basándose en la velocity real del equipo. No es adivinar: es extrapolar datos concretos. El negocio elige qué es importante, el equipo dice cuánto cuesta, y juntos encuentran el mejor release posible dentro del tiempo disponible. La clave es que la negociación es sobre scope (qué se incluye), no sobre calidad (cómo se construye) ni sobre tiempo (cuándo se entrega).
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Prioriza features para el MVP, negocia con stakeholders |
| Carlos | Presenta datos de velocity, define criterios de release |
| Diego | Estima drag and drop con precisión, defiende su estimación |
| Elena | Propone alternativa simple para historial, estima con rigor |
Anterior: Retrospectiva profunda | Siguiente: Release final