Capítulo 5: Día 1 - Primer pair programming
Capítulo 5: Día 1 — Primer pair programming
Lunes de la primera iteración real. Diego y Elena se sientan juntos frente a un monitor. Dos sillas, un teclado, un mouse. Carlos se sienta cerca, disponible pero sin interferir. Hoy construyen la primera story: crear un tablero.
Anterior: Setup y coding standards | Siguiente: Día 2: Feedback temprano
La incomodidad del principio
Diego nunca ha hecho pair programming de verdad. Ha compartido pantalla en videollamadas, pero sentarse al lado de alguien y programar juntos es diferente.
Diego (Dev): “Se siente raro tener a alguien mirando todo lo que escribo.”
Elena (Dev): “A mí también me incomoda. Pero Carlos dijo que la incomodidad dura tres días.”
Carlos (TL): “Máximo. Después se vuelve natural. El truco es recordar que el navigator no está juzgando: está pensando en lo que viene después.”
Carlos explica los roles:
- Driver (conductor): tiene el teclado, escribe código, piensa en la línea actual
- Navigator (navegante): observa, piensa en el diseño general, sugiere, detecta errores
Carlos (TL): “El driver se enfoca en el cómo. El navigator en el qué y el por qué. Rotan cada 25 minutos. Sin excepciones.”
TDD: test primero, siempre
Elena toma el teclado como driver. La primera story es “crear un tablero nuevo”.
Elena (Dev): “¿Por dónde empiezo?”
Carlos (TL): “Por el test. ¿Qué es lo más simple que quieres verificar?”
Elena (Dev): “Que puedo crear un tablero con un nombre y que el tablero tiene ese nombre.”
Carlos (TL): “Perfecto. Escribe ese test. El test va a fallar porque no existe nada todavía. Eso es Red.”
Diego (Dev): “¿Red?”
Carlos (TL): “Red-Green-Refactor. Es el ciclo del TDD. Red: escribes un test que falla. Green: escribes el mínimo código para que pase. Refactor: limpias sin cambiar el comportamiento. Y repites.”
Elena escribe el test. Lo ejecutan. Falla. Rojo.
Elena (Dev): “Ok, está rojo. Ahora escribo lo mínimo para que pase.”
Diego (Dev): “¿Lo mínimo? ¿No deberíamos pensar en la estructura completa?”
Carlos (TL): “No. Lo mínimo. Si el test dice que un tablero tiene nombre, crea algo que tenga nombre y nada más. El diseño emerge de los tests, no al revés.”
Elena escribe la implementación mínima. Ejecutan. Verde. El equipo respira.
Carlos (TL): “Ahora, ¿hay algo que limpiar?”
Elena (Dev): “No, es tan simple que no hay nada que refactorizar.”
Carlos (TL): “Entonces avanzamos al siguiente test.”
La rotación de roles
Suena el timer de 25 minutos. Diego toma el teclado.
Diego (Dev): “Me toca. ¿Cuál es el siguiente test?”
Elena (Dev): “El tablero necesita poder agregar columnas. Escribe un test que verifique que puedes agregar una columna a un tablero.”
Diego escribe el test. Sus dedos titubean. Elena resiste el impulso de dictar.
Elena (Dev): “Estás pensando en voz alta, que es bueno. Pero el nombre del test… ¿qué comportamiento describe?”
Diego (Dev): “Que un tablero puede tener columnas.”
Elena (Dev): “¿Y cómo lo nombrarías en lenguaje humano?”
Diego (Dev): “Un tablero nuevo puede agregar una columna.”
Elena (Dev): “Eso. Usa eso como nombre del test.”
Diego renombra el test. Lo ejecutan. Rojo. Escribe la implementación mínima. Verde. Sonríe.
Diego (Dev): “Ok, entiendo el ritmo. Es como un juego: rojo, verde, limpia. Rojo, verde, limpia.”
Carlos observa y da feedback
Carlos ha estado observando sin intervenir. Después de la segunda rotación, se acerca.
Carlos (TL): “Van bien. Noté algo: cuando Diego estaba conduciendo, Elena a veces quería tomar el teclado. Elena, ¿lo notaste?”
Elena (Dev): “Sí. Es difícil ver a alguien hacer algo distinto a como lo harías tú.”
Carlos (TL): “Eso es normal. El navigator sugiere, no dicta. Si Diego está yendo por un camino que funciona, déjalo. Si está yendo por un camino que va a romper algo, dilo. Pero hay una diferencia entre ‘eso va a fallar’ y ‘yo lo haría diferente’.”
Diego (Dev): “Agradezco que Elena me deje cometer errores pequeños. Aprendo más así.”
Carlos (TL): “Eso es Respect. Confiar en que tu pair es capaz.”
Avanzando con el dominio
Al final del día, el equipo ha completado los tests para las reglas básicas del dominio: un tablero tiene nombre, puede tener columnas, las columnas tienen nombre y orden. Todo vive en el centro del hexágono, sin saber nada de bases de datos ni pantallas.
Ana (PO): “¿Puedo ver algo?”
Carlos (TL): “Todavía no hay pantalla. Pero puedo mostrarte los tests: cada test describe un comportamiento que Ana pidió, en lenguaje legible.”
Carlos muestra los nombres de los tests en pantalla. Ana lee:
- Un tablero nuevo tiene el nombre que le dieron
- Un tablero puede agregar una columna
- Las columnas de un tablero mantienen su orden
- Un tablero sin columnas está vacío
Ana (PO): “Es como leer los requisitos. Puedo verificar que entendieron lo que pedí.”
Carlos (TL): “Esa es la idea. Los tests son la especificación viviente del sistema.”
El cierre del día
A las 5:45 pm, Carlos pide que paren.
Carlos (TL): “Empujen lo que tienen. Asegúrense de que CI está verde. Mañana seguimos.”
Diego (Dev): “Pero me falta un test más…”
Carlos (TL): “Mañana. Sustainable pace. Nos vamos a las 6.”
Diego quiere protestar pero ve que Elena ya está guardando sus cosas. Carlos tiene razón: si mañana llegan descansados, serán más productivos que si hoy se quedan media hora más.
Práctica XP del capítulo
Pair Programming: Dos programadores, una máquina. El driver escribe, el navigator piensa. Rotan frecuentemente. Kent Beck explica que el pair programming no es sobre productividad medida en líneas de código: es sobre calidad, transferencia de conocimiento y un diseño que dos cabezas acuerdan. El código que produce un pair es más simple y tiene menos defectos.
Test-Driven Development (TDD): Red-Green-Refactor. Escribir el test antes del código obliga al desarrollador a pensar en el comportamiento deseado antes de la implementación. Kent Beck lo describe como “programar por intención”: primero declaras lo que quieres, luego lo haces realidad.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Revisa que los tests reflejen sus requisitos |
| Carlos | Observa al pair, da feedback, enseña TDD |
| Diego | Driver y navigator alternando con Elena |
| Elena | Driver y navigator alternando con Diego |
Anterior: Setup y coding standards | Siguiente: Día 2: Feedback temprano