Capítulo 6: Día 2 - Feedback temprano
Capítulo 6: Día 2 — Feedback temprano
Martes. Segundo día de la primera iteración. Ana llega temprano con noticias que cambian las prioridades. En un proyecto tradicional esto sería un drama. En XP, es martes normal.
Anterior: Día 1: Primer pair programming | Siguiente: Día 3: Integración continua real
Ana trae novedades
Ana habló ayer tarde con los stakeholders. Uno de ellos mencionó algo que Ana no había considerado.
Ana (PO): “Necesito cambiar una prioridad. Los stakeholders quieren ver tarjetas moviéndose entre columnas esta semana. Es más importante que crear tarjetas con descripción detallada.”
Elena (Dev): “Pero ayer planificamos otra cosa.”
Carlos (TL): “¿Cuál es el impacto real? Todavía no empezamos la story de descripción detallada. Si Ana dice que mover tarjetas es más importante, podemos ajustar.”
Diego (Dev): “¿Así de fácil?”
Carlos (TL): “Así de fácil. Es Simplicity: no nos aferramos al plan original si la realidad cambió. Y es Courage: Ana tuvo el coraje de decirnos el cambio temprano en lugar de esperar al final de la semana.”
Ana reordena las tarjetas en el tablero físico. La story de descripción detallada baja de prioridad. La story de mover tarjetas entre columnas sube.
Ana (PO): “Gracias por no hacer un escándalo. En mi equipo anterior, cambiar una prioridad era como declarar la guerra.”
Carlos (TL): “En XP, el cambio no es el enemigo. El enemigo es enterarse tarde del cambio.”
Nuevas parejas
Carlos propone rotar las parejas. Ayer Diego y Elena trabajaron juntos. Hoy hay dos streams de trabajo: backend y frontend.
Carlos (TL): “Diego, hoy haces pair conmigo en el backend. Elena, vas a arrancar la estructura del frontend. Te acompaño los primeros diez minutos para alinearnos y después sigues.”
Elena (Dev): “¿Sola? ¿No es contra las reglas de XP?”
Carlos (TL): “Kent Beck dice que el pair programming es una práctica, no una ley. Hay momentos donde trabajar solo tiene sentido: exploración, configuración inicial, tareas mecánicas. La clave es que no sea la norma. Mañana vuelves a hacer pair.”
Elena (Dev): “Ok. Pero si me atasco, pido ayuda.”
Carlos (TL): “Eso es Communication. Perfecto.”
Diego y Carlos: pair en backend
Diego conduce. Carlos navega. Trabajan en el caso de uso de mover una tarjeta entre columnas.
Diego (Dev): “Necesito crear el endpoint de la API, la lógica del servicio, el acceso a la base de datos…”
Carlos (TL): “Para. ¿Cuál es el test?”
Diego (Dev): “Ehm… ¿que una tarjeta se puede mover de una columna a otra?”
Carlos (TL): “Exacto. Escribe ese test. Solo eso. Nada de endpoints, nada de base de datos. El test vive en el dominio.”
Diego escribe el test. Rojo. Implementa la lógica mínima en el dominio: una tarjeta sabe en qué columna está y puede cambiar de columna. Verde.
Diego (Dev): “Fue rápido.”
Carlos (TL): “Porque no mezclaste infraestructura con dominio. Ahora pensemos: ¿qué pasa si la columna destino no existe?”
Diego (Dev): “El test debería fallar.”
Carlos (TL): “Escribimos otro test para ese caso.”
Diego escribe un test para el caso de error. Rojo. Agrega una validación simple. Verde. Refactoriza un nombre que no era claro. Los tests siguen verdes.
Diego (Dev): “Me gusta este ritmo. Es como tener un GPS: siempre sé dónde estoy.”
Carlos (TL): “Esa es la confianza que da TDD. Nunca estás perdido por más de cinco minutos.”
Elena arranca el frontend
Mientras tanto, Elena configura la estructura del frontend. Carlos pasa diez minutos con ella alineando la estrategia.
Carlos (TL): “El frontend consume la API. Pero la API todavía no existe como endpoint HTTP. ¿Qué hacemos?”
Elena (Dev): “Puedo crear la interfaz visual con datos falsos. Cuando la API esté lista, conecto.”
Carlos (TL): “Simple Design. Me gusta. Haz la pantalla más simple que muestre un tablero con columnas y tarjetas. Un botón para mover por ahora, nada de drag and drop.”
Elena (Dev): “¿Ana estará de acuerdo con un botón en vez de drag and drop?”
Carlos (TL): “Preguntémosle.”
Carlos camina hasta Ana.
Carlos (TL): “Ana, para mover tarjetas esta semana: ¿botón o drag and drop?”
Ana (PO): “Drag and drop sería ideal, pero… ¿cuánto cuesta?”
Carlos (TL): “El botón es medio punto. El drag and drop es tres puntos y puede complicarse.”
Ana (PO): “Botón. Quiero ver tarjetas moviéndose esta semana. Lo bonito puede esperar.”
Elena sonríe. Es la primera vez que un PO le da permiso explícito para hacer algo simple.
Stand-up informal de cierre
A las 5 pm, el equipo se reúne frente al tablero cinco minutos.
Diego (Dev): “La lógica de mover tarjetas está lista en el dominio con tests. Mañana conecto la API.”
Elena (Dev): “La pantalla muestra un tablero con columnas. Mañana agrego los botones de mover.”
Carlos (TL): “CI está verde. Buen día.”
Ana (PO): “Me gusta que puedo ver progreso real cada día. Esto no pasaba en mis proyectos anteriores.”
Práctica XP del capítulo
Feedback: Kent Beck dice que el feedback es el motor de XP. Ciclos de feedback cortos a todos los niveles: tests que dan feedback en segundos, pair programming que da feedback en minutos, iteraciones que dan feedback en días. Cuando Ana cambió la prioridad el martes por la mañana, el costo fue cercano a cero porque el equipo todavía no había invertido esfuerzo en la story que bajó de prioridad. Si el cambio hubiera llegado cuatro semanas después, el costo habría sido enorme.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Cambia prioridades con coraje, toma decisiones de scope |
| Carlos | Navega con Diego, alinea a Elena, facilita decisiones |
| Diego | Conduce el pair con Carlos, aprende TDD en dominio |
| Elena | Trabaja sola en frontend, aplica Simple Design |
Anterior: Día 1: Primer pair programming | Siguiente: Día 3: Integración continua real