Capítulo 14: Whole Team en crisis
Capítulo 14: Whole Team en crisis
Martes de la tercera semana. El líder de equipo que vio la demo el viernes empezó a usar el Kanban con su equipo. A media mañana llama a Ana: las tarjetas desaparecen cuando mueves dos al mismo tiempo. Es el primer bug en producción. Lo que suceda en las próximas horas definirá la madurez del equipo.
Anterior: Segundo Small Release | Siguiente: Sustainable Pace
La llamada
Ana se acerca al equipo con el teléfono todavía en la mano.
Ana (PO): “Tenemos un problema. El equipo de Martín está usando el Kanban y les desaparecen tarjetas cuando dos personas mueven cosas al mismo tiempo.”
Diego (Dev): “¿Desaparecen? ¿Cómo que desaparecen?”
Ana (PO): “Se van del tablero. No están en ninguna columna. Martín dice que perdió tres tarjetas esta mañana.”
El silencio en la sala es denso. Diego mira a Elena. Elena mira a Carlos. Todos saben que esto es grave: un usuario real perdiendo datos.
Sin culpables
Carlos toma la iniciativa.
Carlos (TL): “Ok. Primero: nadie tiene la culpa. Esto es un bug, no un fracaso personal. Segundo: lo resolvemos juntos. Whole Team. Tercero: después de arreglarlo, hacemos root cause analysis para que no vuelva a pasar.”
Diego (Dev): “Yo escribí la lógica de mover tarjetas. Es mi respon…”
Carlos (TL): “No. En XP no hay ‘mi código’. Es código del equipo. Elena lo revisó, yo navegué partes de él, todos contribuimos. Y todos vamos a arreglarlo.”
Elena asiente. No hay acusaciones. No hay “¿quién revisó esto?”. Hay cuatro personas enfocadas en el mismo problema.
Diagnosticando juntos
Carlos organiza al equipo.
Carlos (TL): “Diego y Elena: reproduzcan el bug. Necesito que lo vean pasar. Ana: dile a Martín que estamos trabajando en ello y que en unas horas tendremos una solución.”
Ana (PO): “¿Unas horas? ¿No pueden arreglarlo más rápido?”
Carlos (TL): “Primero necesitamos entender el problema. Después arreglarlo. Después verificar que el arreglo funciona. Si me apresuro, puedo empeorar las cosas.”
Ana llama a Martín. Le pide que su equipo deje de usar el Kanban por un par de horas.
Diego y Elena se sientan juntos. Abren dos ventanas del navegador y simulan que dos personas mueven tarjetas al mismo tiempo.
Elena (Dev): “Ahí está. Si los dos movimientos llegan al servidor al mismo tiempo, uno sobrescribe al otro. La tarjeta termina en un estado inconsistente.”
Diego (Dev): “Es un problema de concurrencia. No tenemos ninguna protección contra operaciones simultáneas.”
Carlos (TL): “¿Nuestros tests cubren ese caso?”
Diego (Dev): “No. Todos nuestros tests son secuenciales. Nunca probamos dos operaciones al mismo tiempo.”
Carlos (TL): “Ahí está el root cause. No es que el código sea malo: es que no previmos el escenario. Y nuestros tests no lo cubrían.”
La solución: test primero
Carlos insiste en la disciplina del TDD, incluso bajo presión.
Carlos (TL): “Antes de arreglar nada, escribimos el test que reproduce el bug. Ese test tiene que fallar.”
Diego (Dev): “¿Ahora? Estamos bajo presión.”
Carlos (TL): “Especialmente ahora. Si arreglamos sin test, ¿cómo sabemos que realmente lo arreglamos? ¿Y cómo nos aseguramos de que no vuelve a pasar?”
Elena escribe un test que simula dos movimientos simultáneos sobre la misma tarjeta. Lo ejecuta. Rojo: la tarjeta desaparece, exactamente como reportó Martín.
Elena (Dev): “El test reproduce el bug perfectamente.”
Carlos (TL): “Ahora sí. Arreglen.”
Diego y Elena trabajan en pair. Carlos navega. Agregan una protección contra operaciones concurrentes en el dominio. Ejecutan el test. Verde. Ejecutan todos los tests. Verde.
Carlos (TL): “Empujen. CI. Y después desplegamos.”
CI verde. Despliegan. Carlos le avisa a Ana.
Comunicación transparente
Ana llama a Martín.
Ana (PO): “Martín, encontramos el problema y lo arreglamos. Era un tema de operaciones simultáneas. Ya está desplegado. ¿Puedes verificar que las tarjetas que perdiste se recuperaron?”
Quince minutos después, Martín responde: las tarjetas están de vuelta.
Ana (PO): “Gracias, equipo. Martín está contento.”
Carlos (TL): “No hemos terminado. Ahora hacemos el root cause analysis.”
Root cause analysis
El equipo se reúne alrededor de la pizarra. Carlos dibuja una línea de tiempo.
Carlos (TL): “¿Por qué desaparecían las tarjetas?”
Elena (Dev): “Porque dos operaciones simultáneas no estaban protegidas.”
Carlos (TL): “¿Por qué no estaban protegidas?”
Diego (Dev): “Porque no consideramos la concurrencia.”
Carlos (TL): “¿Por qué no la consideramos?”
Elena (Dev): “Porque nuestros tests solo cubrían operaciones secuenciales.”
Carlos (TL): “¿Por qué solo operaciones secuenciales?”
Diego (Dev): “Porque cuando diseñamos los tests, asumimos un solo usuario.”
Carlos (TL): “Ahí está la raíz. Nuestra metáfora del tablero físico nos jugó en contra: en un tablero físico, dos personas no pueden mover el mismo post-it al mismo tiempo porque es un objeto físico. En digital, sí pueden.”
El equipo agrega a sus coding standards una nueva regla: cuando una story involucre datos compartidos, incluir tests de concurrencia.
Carlos (TL): “No vamos a prevenir todos los bugs. Pero cada bug nos enseña algo. Y cada lección se convierte en un test que nos protege para siempre.”
Práctica XP del capítulo
Whole Team: Kent Beck describe Whole Team como la práctica de incluir a todas las personas necesarias para el éxito del proyecto, trabajando juntas como una unidad. En este capítulo, Whole Team se manifiesta en crisis: cuando hay un bug en producción, no hay un “equipo de soporte” separado ni un “responsable” individual. Todo el equipo se alinea, diagnostica y resuelve. Ana comunica con el usuario. Diego y Elena reproducen y arreglan. Carlos guía el proceso. Nadie señala culpables porque el código es de todos.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Comunica con el usuario, transmite urgencia sin pánico |
| Carlos | Organiza la respuesta, insiste en TDD bajo presión, guía root cause analysis |
| Diego | Reproduce el bug, participa en la solución |
| Elena | Escribe el test que reproduce el bug, implementa el arreglo |
Anterior: Segundo Small Release | Siguiente: Sustainable Pace