Capítulo 17: Retrospectiva profunda
Capítulo 17: Retrospectiva profunda
Viernes de la sexta semana. El equipo lleva seis iteraciones completadas. No es una retrospectiva más: es el momento de mirar hacia atrás con perspectiva y evaluar no solo qué construyeron, sino cómo cambiaron como equipo.
Anterior: On-site Customer | Siguiente: Release Planning
Los números
Carlos llega con un gráfico dibujado a mano en un papel grande. Lo pega en la pizarra.
Carlos (TL): “Seis semanas. Veamos los datos.”
Velocity por iteración:
| Iteración | Planificado | Completado |
|---|---|---|
| 1 | 8 | 5 |
| 2 | 5 | 5 |
| 3 | 6 | 6 |
| 4 | 7 | 7 |
| 5 | 7 | 8 |
| 6 | 8 | 8 |
Elena (Dev): “La velocity subió de 5 a 8 sin trabajar horas extra.”
Carlos (TL): “Porque nos conocemos mejor, las herramientas fluyen y el código base es limpio. Eso es lo que pasa cuando inviertes en calidad: la velocidad crece sola.”
Diego (Dev): “La primera semana me parecía que 5 puntos era poco. Ahora 8 se siente natural.”
Bugs encontrados:
| Fuente | Cantidad |
|---|---|
| Encontrados por tests antes de llegar a producción | 23 |
| Encontrados en demos por Ana o stakeholders | 7 |
| Encontrados en producción por usuarios | 2 |
Ana (PO): “Solo dos bugs llegaron a producción en seis semanas. En mi proyecto anterior eran dos por día.”
Carlos (TL): “23 bugs atrapados por tests. Cada uno de esos habría sido un bug en producción sin TDD.”
Reflexión por persona
Carlos pide que cada uno comparta su reflexión personal sobre el viaje.
Elena reflexiona:
Elena (Dev): “Llegué escéptica. Venía de Scrum y pensaba que XP era demasiado estricto. Pero las prácticas técnicas son lo que faltaba en mis equipos anteriores. Scrum me decía cuándo entregar. XP me dice cómo construir con calidad.”
Carlos (TL): “¿Qué práctica te impactó más?”
Elena (Dev): “TDD. Cambió cómo pienso. Antes escribía código y después buscaba bugs. Ahora defino qué quiero y después lo construyo. Es un cambio de mentalidad completo.”
Diego reflexiona:
Diego (Dev): “El pair programming fue lo que más me costó al principio. No me gustaba que alguien viera mis errores. Pero ahora no puedo imaginar programar solo. Cuando estoy solo, me siento incompleto.”
Carlos (TL): “¿Y Sustainable Pace?”
Diego (Dev): “Lo admito: tenías razón. Duermo mejor. Mi código es mejor. Mi vida fuera del trabajo es mejor. No sabía lo cansado que estaba hasta que dejé de estar cansado.”
Ana reflexiona:
Ana (PO): “Para mí, lo más valioso es la transparencia. Sé exactamente dónde estamos. No hay sorpresas. La velocity me dice qué puedo prometer y qué no. Los stakeholders confían en mí porque les doy datos, no esperanzas.”
Elena (Dev): “¿Y estar sentada con nosotros todo el día?”
Ana (PO): “Al principio pensé que era ineficiente. Ahora sé que es lo más eficiente que he hecho en mi carrera. Cada decisión que tomo en treinta segundos habría sido un correo, una reunión y tres días de espera.”
Carlos reflexiona:
Carlos (TL): “Para mí, lo más difícil fue no imponer. Quería dictar el diseño, las convenciones, las decisiones. Pero en XP el conocimiento es del equipo. Mi rol es facilitar, no mandar. Los mejores momentos fueron cuando Diego o Elena propusieron algo mejor que lo que yo tenía en mente.”
Las prácticas: qué adoptaron y qué les costó
Carlos dibuja una tabla en la pizarra.
Prácticas que fluyeron naturalmente:
- Integración continua: después del conflicto de la semana 1, nunca más fue un problema
- Small Releases: los demos semanales se volvieron el momento favorito de todos
- Coding Standards: una vez configurado el formateador, nadie pensó en ello otra vez
- Planning Game: se volvió más rápido y preciso con cada iteración
Prácticas que costaron:
- Pair Programming: tres días de incomodidad al inicio, pero ahora es natural
- TDD: la disciplina de escribir el test primero requiere práctica constante
- Refactoring: el miedo a romper cosas persiste, aunque los tests ayudan
- Collective Code Ownership: el conflicto de la semana 2 fue necesario para internalizarlo
Prácticas que todavía ajustan:
- Sustainable Pace: Diego todavía siente impulso de quedarse tarde a veces
- Metaphor: funciona bien internamente, pero a veces usan jerga con los stakeholders
Ajustes al proceso
El equipo decide tres ajustes para las iteraciones restantes:
Elena (Dev): “Propongo que hagamos demos los jueves en vez de los viernes. Así tenemos el viernes para incorporar feedback rápido.”
Diego (Dev): “Propongo que la rotación de pairs sea por story, no por hora. A veces rotamos a mitad de un pensamiento.”
Ana (PO): “Propongo que los stakeholders vengan cada dos semanas, no cada semana. Les damos más para ver y les quitamos menos tiempo.”
Carlos (TL): “Todos de acuerdo. Lo que me gusta es que estos ajustes vienen de ustedes, no de mí. El equipo se auto-regula. Eso es madurez XP.”
Práctica XP del capítulo
Retrospectiva (y mejora continua): Aunque Kent Beck no la nombra como una de las 12 prácticas originales, la mejora continua es el meta-principio que las sostiene. Un equipo XP no aplica las prácticas ciegamente: las evalúa, las ajusta y las evoluciona. Las retrospectivas son el mecanismo formal para esta evolución. Cada retrospectiva es una oportunidad para hacer el proceso más adecuado al equipo, no para seguir un manual al pie de la letra.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Comparte su perspectiva de PO, propone ajuste de demos |
| Carlos | Presenta métricas, facilita reflexión, acepta feedback |
| Diego | Reflexiona sobre su crecimiento, propone ajuste de rotación |
| Elena | Reconoce su cambio de escepticismo a convicción |
Anterior: On-site Customer | Siguiente: Release Planning