Capítulo 8: Primer Small Release
Capítulo 8: Primer Small Release
Viernes. Última día de la primera iteración. El equipo tiene algo funcionando: no es mucho, pero es real. Hoy hacen la demo a Ana, la primera retrospectiva, y aprenden que irse a casa a tiempo es parte del proceso.
Anterior: Día 3: Integración continua real | Siguiente: Planning Game iteración 2
La demo
A las 11 de la mañana, el equipo se reúne con Ana frente a una pantalla. Elena maneja el sistema en vivo.
Elena (Dev): “Esto es lo que tenemos. Puedes crear un tablero, agregarle columnas y crear tarjetas dentro de las columnas.”
Ana (PO): “¿Y mover tarjetas?”
Elena (Dev): “Sí. Hay un botón en cada tarjeta que dice ‘Mover a siguiente columna’. Mira.”
Elena hace clic en el botón. La tarjeta pasa de “Todo” a “En Progreso”. Ana asiente.
Ana (PO): “Funciona. Es básico, pero funciona. Me gusta que puedo crear columnas con los nombres que yo quiera.”
Diego (Dev): “¿Falta algo que esperabas?”
Ana (PO): “No se puede mover una tarjeta hacia atrás. Solo avanza.”
Diego (Dev): “Tienes razón. No consideramos ese caso.”
Carlos (TL): “Lo anotamos como story para la siguiente iteración. No vamos a arreglarlo hoy.”
Ana escribe una tarjeta nueva: “Como usuario, quiero mover una tarjeta en cualquier dirección”. La pone en el backlog.
Lo que NO se completó
De las tres stories planificadas, completaron dos y media. La story de crear tarjetas con asignación de persona quedó sin terminar.
Ana (PO): “¿Qué pasó con la asignación?”
Carlos (TL): “Subestimamos la complejidad. El dominio de asignación tocaba más piezas de las que pensábamos. Preferimos entregar las dos stories completas con calidad que tres a medias.”
Ana (PO): “¿Debería preocuparme?”
Carlos (TL): “Al contrario. Ahora sabemos nuestra velocity real: completamos cinco puntos de los ocho que planificamos. Para la próxima iteración, planificamos cinco puntos.”
Elena (Dev): “Es mejor prometer menos y cumplir que prometer más y fallar.”
Ana acepta. La transparencia le da confianza. En proyectos anteriores, el equipo decía “vamos bien” hasta la semana antes de la entrega, cuando de repente todo estaba atrasado.
La primera retrospectiva
Después del almuerzo, el equipo cierra la sala de reuniones. Carlos facilita la retrospectiva.
Carlos (TL): “Tres preguntas: ¿qué funcionó bien? ¿Qué no funcionó? ¿Qué queremos cambiar?”
Cada persona escribe en post-its. Los pegan en la pizarra y los agrupan.
Lo que funcionó bien:
Diego (Dev): “El pair programming. Al principio me incomodaba, pero aprendí más en una semana que en un mes trabajando solo.”
Elena (Dev): “TDD. Me daba confianza para cambiar cosas sin miedo a romperlas.”
Ana (PO): “Ver progreso cada día. Poder cambiar una prioridad el martes sin que nadie gritara.”
Lo que no funcionó:
Diego (Dev): “A veces no sabía si debía hablar más como navigator o callarme.”
Elena (Dev): “El conflicto de merge del miércoles fue estresante, aunque lo resolvimos rápido.”
Carlos (TL): “No rotamos suficientes parejas. Diego y Elena trabajaron juntos casi toda la semana.”
Lo que quieren cambiar:
Carlos (TL): “Propongo que rotemos parejas cada medio día, no cada día.”
Elena (Dev): “Propongo que integremos antes del almuerzo obligatoriamente, además de al final del día.”
Diego (Dev): “Quiero hacer pair con Carlos más seguido. Aprendí mucho ayer.”
Ana (PO): “Quiero ver la demo el jueves, no el viernes. Así tengo un día para dar feedback antes de la siguiente planificación.”
Carlos anota todas las acciones. No son muchas. No necesitan ser muchas: es la primera semana.
Sustainable pace
A las 5:30, Diego está revisando algo en su máquina.
Carlos (TL): “Diego, cierra eso.”
Diego (Dev): “Solo cinco minutos. Quiero dejar algo listo para el lunes.”
Carlos (TL): “No. Nos vamos a las 6. Sin excepciones. Es viernes.”
Diego (Dev): “¿Tan estrictos?”
Carlos (TL): “Kent Beck es muy claro con esto. Sustainable Pace significa que trabajamos a un ritmo que podemos mantener por meses. Si hoy te quedas media hora extra, mañana será una hora. En dos semanas estarás aquí hasta las 9 de la noche y tu código será peor, no mejor.”
Elena (Dev): “En mi proyecto anterior trabajábamos hasta las 10 las últimas tres semanas. Teníamos más bugs que features.”
Diego (Dev): “Ok. Me voy. Pero el lunes empiezo con eso primero.”
Carlos (TL): “Eso sí. Anota un post-it con lo que quieres hacer y pégalo en el tablero. El lunes lo retomas con mente fresca.”
El balance de la primera semana
El equipo sale a las 6. Ana se queda un momento mirando el tablero en la pizarra. Dos stories en “Hecho”. Una en “En Progreso”. Tres en “Por hacer”. No es un producto completo, pero es un producto real. Funciona. Tiene tests. Está en CI.
En una semana, cuatro personas que no se conocían han producido software funcionando con calidad profesional. No es magia: es disciplina, comunicación y respeto por el ritmo humano.
Práctica XP del capítulo
Small Releases: Kent Beck dice que el valor del software es cero hasta que alguien lo usa. Los Small Releases reducen el tiempo entre inversión y feedback. Esta primera release tiene solo dos funcionalidades completas, pero Ana puede verlas, tocarlas y dar feedback real. Eso vale más que un plan de proyecto con cien features estimadas.
Sustainable Pace: Un equipo XP trabaja máximo 40 horas semanales. Sin héroes. Sin crunch. Kent Beck argumenta que la productividad sostenida requiere descanso. Los estudios respaldan esto: después de ocho horas de trabajo cognitivo intenso, la calidad del código degrada significativamente.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Ve la demo, da feedback, propone ver demos los jueves |
| Carlos | Facilita retrospectiva, refuerza sustainable pace |
| Diego | Presenta lo que construyó, acepta irse a tiempo |
| Elena | Maneja la demo, propone integrar antes del almuerzo |
Anterior: Día 3: Integración continua real | Siguiente: Planning Game iteración 2