Ya sabes qué es un kata: un ejercicio pequeño de código que repites para entrenar la técnica, no para entregar. El problema es que muchas sesiones de kata terminan siendo solo «resolver el ejercicio otra vez» y, por eso, enseñan poco. La diferencia entre un kata que aporta y uno que solo mata el tiempo casi nunca está en el ejercicio. Está en cómo conduces la sesión.
Define un límite de tiempo y borra todo al final
Define el tiempo antes de empezar: 45 minutos, 1 hora, lo que sea. Cuando suene el temporizador, se acabó, aunque el código no esté «listo». El objetivo no es terminar, sino practicar.
Y al final, borra todo. Elimina el código y cierra la branch sin hacer commit. Parece un desperdicio, pero ese es precisamente el punto: si sabes que vas a desecharlo, dejas de apegarte a la solución y empiezas a prestar atención al camino.
Varía las restricciones: ahí está el aprendizaje
Repetir el mismo kata de la misma manera te enseña a memorizar la respuesta. Repetirlo con una restricción nueva te obliga a pensar de nuevo. Algunas que funcionan bien:
- Solo TDD, sin excepciones: ninguna línea de producción sin un test rojo antes.
- Sin
if: nada de condicionales; te empuja hacia el polimorfismo, las tablas de lookup y el null object. - Funciones de un máximo de 3 líneas: te obliga a extraer y nombrar cada paso.
- Sin mouse / solo teclado: entrena la navegación y el refactoring asistido por el IDE.
- Silencio total en pareja: solo el código y los tests se comunican.
Una restricción por sesión. Dos al mismo tiempo convierten el ejercicio en un rompecabezas, no en entrenamiento.
Ping-pong: pairing que obliga a concentrarse
El formato ping-pong es la mejor manera de hacer un kata en pareja. La persona A escribe un test que falla. La persona B hace que el test pase y escribe el siguiente test que falla. La persona A hace que este pase, y así sucesivamente.
El efecto es que nadie se queda mirando desde fuera. Quien no está escribiendo está pensando en el próximo test. Y como el test lo escribe quien no va a implementarlo, dejas de escribir tests hechos a medida para tu propia solución mental.
Dojo en grupo: rotación y una audiencia que participa
En el coding dojo (formato Randori), una pareja trabaja delante de todo el grupo y proyecta la pantalla. Cada 5–7 minutos se rota: quien estaba en el teclado vuelve a la audiencia, quien estaba como copiloto toma el teclado y alguien de la audiencia entra.
Dos reglas que salvan el dojo:
- La audiencia solo comenta cuando los tests están verdes. Debatir sobre el diseño con un test rojo en pantalla se convierte en un caos.
- Quien entra asume el código tal como está, sin quejarse. El objetivo es continuar el razonamiento del grupo, no imponer el propio.
Una persona facilitadora se encarga del temporizador y de las reglas, sin tocar el código.
Elige el kata adecuado para el objetivo
El ejercicio no es neutro: cada uno entrena algo distinto. Elige según lo que quieras practicar hoy:
- FizzBuzz / Roman Numerals: ritmo de TDD y pasos pequeños. Excelente para calentar o para quienes están empezando.
- Bowling / Gilded Rose: refactoring de lógica desordenada y cobertura antes de modificarla.
- Mars Rover / Bank Account: diseño, separación de responsabilidades y modelado.
Hacer Gilded Rose para entrenar «pasos pequeños» o FizzBuzz para practicar arquitectura es desperdiciar la sesión. Combina el kata con la intención.
Reserva los últimos 10 minutos para reflexionar
Sin una retrospectiva, el kata se convierte en gimnasia sin propósito. Detente antes del final y pregunta, en grupo o a ti mismo: ¿qué nos obligó a hacer de manera diferente la restricción de hoy? ¿Dónde nos atascamos? ¿Qué paso repetiríamos y cuál eliminaríamos?
Es en esa conversación donde la práctica se convierte en aprendizaje transferible: lo que llevas al código real mañana.
Un buen kata no es el que resuelves más rápido. Es el que te deja lo suficientemente incómodo, con una restricción clara, un formato que mantiene a todos pensando y cinco minutos al final para entender qué cambió en tu cabeza. Elige una restricción para la próxima sesión y borra el código al final. El aprendizaje permanece.
