Retrospectiva de los coding dojos

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?

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • http://developerscookbook.blogspot.com/ Yeray Darias Camacho

    Muchas gracias por la aportación Carlos, como ya te dije en la propia actividad, creo que tienes mucha razón. En mi experiencia personal el viernes pasado, la cosa se descontroló un poco y al final ya no era un coding-dojo sino una discusión abierta sobre el problema y diversos aspectos de TDD en concreto o de programación en general.

    Para sucesivas actividades ten por seguro que utilizaremos estas conclusiones para mejorar.

  • http://jmbeas.iexpertos.com Jose M Beas

    Je, je. Gracias por la mención. 🙂

    Ahora en serio, Carlos, tienes toda la razón. En el codingdojo que hicimos en Madrid hace poco, también en formato randori, @ecomba también nos riñó (especialmente a mi, que soy claramente el más indisciplinado) porque mientras se está en rojo la pareja “al volante” debe ser respetada por el grupo. Me parece una regla muy interesante y que, además, se debería aplicar al mundo real. Si tus compañeros están en rojo lo mejor es esperar a que ellos te pidan ayuda para meter tu nariz en lo que están haciendo. Están concentrados TRABAJANDO.

    Pero respecto al formato randori me gustaría romper una lanza. En el DevOpenMadrid ( ¿quién le pondría el nombre? 😉 ), un openspace dedicado sólo a hablar y practicar programación, se nos ocurrió practicar las clojurekoans en este formato con timeboxes de 4 minutos (al principio usamos 3 pero resultaron muy cortos). La idea era que todos (una docena de pares de manos, más o menos) pudieramos pasar un par de veces por el teclado a la vez que avanzabamos. Como casi ninguno tenía ni idea de clojure no fue nada frustrante y sí un primer paso para quitarnos el reparo a probar un lenguaje con un paradigma y una sintaxis tan diferentes.

    Un abrazo
    JMB

  • Gregorio Mena

    Muy interesantes las conclusiones Carlos. Espero que por aquí al final sigamos con los ánimos y hagamos cosas así con frecuencia. Espero no perderme la próxima y que tú y Yeray estén ahí 😉

    Un abrazo