Este viernes en la reunión del grupo Agile-Canarias hicimos un pequeño coding dojo. En este caso el facilitador fue Yeray Darias. Eligió el estilo RandoriKata, que básicamente consiste en que sólo 2 personas programan mientras los demás miran y se van cambiando por turnos. Con este dojo creo que ya he estado en 3 o 4, aunque sólo estuve en 1 como facilitador (en Autentia, Madrid). En los dojos me he encontrado en ocasiones incómodo y esta última vez he intentado ir analizando cuales han podido ser las causas. Aprovecho para hacer una pequeña retrospectiva de mis experiencias para que en los próximos dojos mi experiencia y la de los demás sea mejor.

  • No debe haber prisas en el dojo. Creo que un dojo de menos de 4 horas es difícil que salga bien.
  • Es bueno que todo el mundo programe en pareja. La RandoriKata esta bien si hay 4 o como mucho 6 personas, pero si hay más, es imposible que todo el mundo preste atención al proyector, con lo cual no se producen buenas discusiones de grupo sobre el código.
  • Si se usan pomodoros para dividir el tiempo en fracciones, estas no deberian ser inferiores a 15 minutos, porque es difícil hacer algo bien en menos de 15 minutos. Creo además que sería bueno no mostrar la cuenta atrás del tiempo ni siquiera decir cuánto dura cada pomodoro. Así el factor tiempo corriendo no influye y la gente puede centrarse en hacerlo bien. No se puede escribir buen software con agobio. Al menos yo no puedo.
  • Si varias personas van a trabajar en la misma máquina, es recomendable que cada uno lleve de casa su propio teclado. Así no pierde tiempo con los malditos teclados de los portatiles. Conectas tu teclado USB y te quitas otro problema de encima.
  • Siempre que se haga TDD debe estar  presente el bloc de notas con las próximas especificaciones a cumplir. Si no lo tenemos, no habrá rumbo. Esto nos pasó en la RandoriKata que cada pareja que se sentaba cambiaba el diseño y tardaba mucho tiempo en saber qué hacer.
  • Hacer más incapié en el refactoring. No se trata de terminar un problema sino de escribir buen código.
  • Cuando una persona está programando con el proyector conectado y todos los demás miran, se deben aplicar las mismas reglas que en la programación por pareja, donde el que tiene el teclado es uno, y el resto de la audiencia es el otro. Aquí hay una lista de 21 razones para odiar pair programming, más alguna otra que se comenta.
    Con esto quiere decir que no te deberían interrumpir hasta que estes en verde y puedas discutir decisiones o aplicar refactoring. Que estés en rojo y JM Beas te repita “¡borra ese código! ¡borralo!” es algo que no favorece que hagas lo que querias hacer. Cuando estas haciendo la kata tienes que hacerla a tu manera, si te vas dejando guiar por lo que algunos harían, entonces no eres tu quien programa.
  • Como los demás han mirado y pueden no estar de acuerdo con tus decisiones, lo ideal es dejar tiempo para que despues de la kata en el proyector, otro valiente se siente y lo haga a su manera también en el proyector. Será la mejor manera de ver ambos diseños.
  • El juego de la vida de Conway está genial para un code retreat porque tienes todo el día, pero para un dojo no me parece apropiado. La gente que nunca ha jugado se hace preguntas como… “que clase de juego es ese?” ya que al hablar de juego piensan que sera algo interactivo. Cuando entienden las posibilidades que ofrece el juego de la vida a la hora de expresar diseños de software, el dojo se ha acabado. En el dojo de Madrid la mitad del tiempo se fué y la gente no habia entendido lo que tenía que hacer (aunque no era el juego de la vida). Creo que es bueno exponer el problema a resolver antes del dojo para que la gente pueda leer sobre ello. Lo haremos así para el dojo del próximo viernes en Huesca.

Un dojo no es un curso y cuando he visto gente que no tenía ni idea de TDD, o que ni siquiera había visto nunca JUnit, su paso por el dojo a veces es negativo. Piensa que estamos todos chalados. Creo que cuando llevas a un amigo a un dojo es bueno que le cuentes un poco de qué va la movida.

Cuales han sido tus experiencias? Qué esperas de un coding dojo?