Capítulo 13: Segundo Small Release
Capítulo 13: Segundo Small Release
Viernes de la segunda semana. Esta vez Ana no viene sola a la demo. Trae a dos stakeholders: la directora de operaciones y un líder de equipo que será usuario final. Es la primera vez que personas externas ven el producto. El feedback real está a punto de cambiar la perspectiva del equipo.
Anterior: El cliente cambia de opinión | Siguiente: Whole Team en crisis
Preparando la demo
Carlos reúne al equipo quince minutos antes de la demo.
Carlos (TL): “No preparen una presentación. No hagan slides. Muestren el sistema funcionando. Si algo falla en vivo, no pasa nada. Es mejor que una demo ensayada que esconde los problemas.”
Diego (Dev): “¿Y si algo se rompe frente a los stakeholders?”
Carlos (TL): “Entonces sabremos qué arreglar primero. El feedback negativo es más valioso que el aplauso.”
Elena se encarga de manejar el sistema en la demo. Diego está listo para responder preguntas técnicas. Ana presenta el contexto.
La demo
Ana abre la sesión.
Ana (PO): “Llevamos dos semanas. El equipo ha construido las funcionalidades básicas del Kanban. Les voy a mostrar qué tenemos.”
Elena crea un tablero. Agrega tres columnas: Pendiente, En Progreso, Terminado. Crea varias tarjetas. Las mueve entre columnas con el botón. Asigna personas a las tarjetas. Filtra por equipo usando las etiquetas que agregaron ayer.
Directora de Operaciones: “¿Se puede mover hacia atrás? A veces algo que creíamos terminado vuelve a ‘En Progreso’.”
Elena (Dev): “Sí. Esta semana agregamos movimiento en cualquier dirección.”
La directora asiente con aprobación.
Líder de equipo: “¿Puedo crear mis propias columnas? Nosotros usamos ‘En Revisión’ antes de ‘Terminado’.”
Elena (Dev): “Sí. Los nombres de las columnas son libres. Puedes crear las que necesites.”
Líder de equipo: “Esto ya es más útil que nuestra hoja de cálculo.”
Feedback inesperado
Entonces llega el feedback que nadie anticipó.
Líder de equipo: “Solo una cosa. Cuando muevo una tarjeta, no hay confirmación. La moví sin querer hace un momento. ¿Hay forma de deshacer?”
Elena (Dev): “No. Actualmente el movimiento es inmediato.”
Líder de equipo: “Eso va a ser un problema. Mi equipo tiene 40 tarjetas en el tablero. Si alguien mueve algo por error y no se da cuenta…”
Carlos (TL): “Anotado. Es un feedback excelente que no habíamos considerado.”
Ana escribe inmediatamente una tarjeta nueva: “Como usuario, quiero confirmar antes de mover una tarjeta” y otra: “Como usuario, quiero deshacer un movimiento accidental”.
Bugs en vivo
Durante la demo, el líder de equipo encuentra un bug real.
Líder de equipo: “Creé una columna sin nombre y el sistema la aceptó. Ahora tengo una columna vacía que no sé qué es.”
Diego (Dev): “Eso es un bug. No validamos que el nombre de la columna no sea vacío.”
Carlos (TL): “Perfecto. Gracias por encontrarlo. Lo arreglamos la próxima semana.”
Ana escribe otra tarjeta: “Bug: validar que columnas tengan nombre”.
Ana (PO): “¿Ven por qué quería stakeholders en la demo? Nosotros cuatro llevamos dos semanas mirando el mismo sistema. Ojos frescos encuentran cosas que nosotros no vemos.”
Carlos (TL): “Eso es Feedback en su forma más pura. Kent Beck dice que cuanto más rápido llega el feedback, más barato es corregir el rumbo.”
Celebrando lo que funciona
Después de que los stakeholders se van, el equipo se queda un momento.
Ana (PO): “La directora de operaciones me dijo que está impresionada. Dos semanas y ya tienen algo que supera su hoja de cálculo.”
Diego (Dev): “¿En serio?”
Ana (PO): “En serio. El líder de equipo me pidió acceso para empezar a probarlo con su equipo la próxima semana.”
Carlos (TL): “Eso es mejor que cualquier métrica. Un usuario real queriendo usar algo que tiene dos semanas de vida.”
Elena sonríe. Diego choca los puños con Carlos.
Carlos (TL): “Pero no nos relajemos. También tenemos un bug y dos features nuevas del feedback. La próxima planificación va a ser interesante.”
Retrospectiva de la iteración 2
Breve retrospectiva antes de irse.
Lo que funcionó:
- La velocity de cinco puntos se mantuvo
- El cambio de prioridad a mitad de semana no descarriló la iteración
- Los stakeholders en la demo dieron feedback invaluable
Lo que no funcionó:
- El conflicto de ownership del miércoles se resolvió rápido, pero debieron comunicar antes
- No tuvieron tiempo para la mejora visual que Ana quería
Acciones:
- Comunicar cambios en interfaces compartidas antes de hacerlos
- Invitar stakeholders a cada demo a partir de ahora
- Priorizar el bug de validación como primer item de la siguiente iteración
Práctica XP del capítulo
Small Releases + Feedback: Kent Beck argumenta que los releases pequeños y frecuentes son la forma más efectiva de aprender qué quiere el usuario real. Este segundo release incluye a stakeholders y un usuario final. El feedback que generan (confirmación de movimiento, validación de columna) es imposible de obtener solo con stories escritas en tarjetas. El producto se moldea con las manos de quienes lo van a usar.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Invita stakeholders, documenta feedback como stories |
| Carlos | Asegura que la demo sea honesta, facilita retrospectiva |
| Diego | Responde preguntas técnicas, reconoce el bug |
| Elena | Maneja la demo en vivo, muestra funcionalidades |
Anterior: El cliente cambia de opinión | Siguiente: Whole Team en crisis