Pues sí. A principios de diciembre Carlos Ble anunció una gran iniciativa, se ofrecía a trabajar un par de días en distintas empresas que le pillaran a mano simplemente a cambio de los gastos de manutención y parte del viaje. Por aquel entonces ya estábamos en contacto con él por que en Frogtek teníamos la ilusión de que Walqa acogiera su curso de TDD, así que nos faltó tiempo para ofrecernos a ser la primera parada de un viaje que seguro va a ser muy provechoso para las empresas que visite y para él. Es un win-win claro (sin tecnología de Redmon de por medio). Para Carlos tiene que ser muy enriquecedor visitar distintas empresas, con distintos productos, distintas metodologías, problemas y personas. Para las empresas es una gran oportunidad de someterse al escrutinio de alguien externo con gran conocimiento de la tecnología y el eXtreme Programming. Fuimos los más rápidos, así que aunque el curso de TDD al final no se llevó a cabo en Walqa, sino en Zaragoza, al acabar Carlos tomó rumbo al norte y recaló en nuestras oficinas por un par de días que se nos hicieron realmente cortos.

El proceso empezó el mismo miércoles por la noche cenando en el Café del Arte una pizza que estaba muy buena pero que era muy difícil de cortar. Hablamos largo y tendido sobre Frogtek y MavenCharts, las fases por las que habíamos pasado, los logros y dificultades que había encontrado por el camino. Me temo que monopolicé un poco la conversación, el problema es que cuando me pongo a contar la historia de Frogtek puedo estar horas y horas y además quería aprovechar los dos días siguientes a tope y para ello tenía que ponerle al día de demasiadas cosas. Mucha información en muy poco tiempo, me temo. :)

El jueves empezó la movida. Primero ponte a explicar la tabla de Kanban y date, enseguida, cuenta de que hemos ido complicando las cosas poco a poco, hasta el punto de que explicar el funcionamiento de una simple tabla deja de ser algo trivial. El tiempo dirá si las sucesivas evoluciones de nuestra metodología han sido para bien o hemos complicado demasiado el proceso. De momento estamos bastante satisfechos. Después tuvimos nuestro stand-up (un poco tarde, me costó 1€ que pagué bien a gusto). Decidimos, en honor de nuestro invitado, que no íbamos a hacer nada especial por su visita así que le obsequiamos con nuestro habitual spanglish. Mr. Ble aguantó el tipo (y la risa) sin problemas así que al final del stand-up accedimos a rellenar un pequeño formulario de preguntas que pretendía chequear la "salud" de nuestro grupo y nuestras expectativas ante su visita.

Lo siguiente fue hablar sobre nuestro sistema de integración continua basado en HUDSON y que Carlos le echara un primer vistazo a la realidad de nuestras baterías de tests. Mucho test de integración pero poco unitario, también algunos funcionales pero todos mezclados y poco ágiles. Es difícil hacer TDD si los tests unitarios tardan varios minutos en pasar. Diagnóstico: grandes dosis de buena voluntad pero mucho por mejorar.

Carlos y Alberto peleándose con el GAE

El resto del jueves y viernes tocaba Pair Programming. Primero Javier Linares y nuestro proyecto para Android TiendaTek, luego Alberto Gualis y los tests de lado de servidor en Python y sobre Google App Engine. Tanto Javi como Alberto pueden dar su propia opinión pero sin duda fueron unas horas muy provechosas durante las que pudimos entender como evolucionar nuestra arquitectura y discriminar y organizar nuestros tests para hacer un TDD realmente útil y no "de postal".

También hubo tiempo para revisar el código de Linares y Carlos el viernes por la mañana.

Al filo de las 3 de la tarde del viernes acabamos la sesión con una retrospectiva que nos reveló distintas cosas:

• Que dos días escasos habían sido muy cortos para todo lo que nos hubiera gustado aprovechar.
• Que podríamos mejorar nuestro nivel de calidad pidiéndole a alguien externo pero cercano que usara nuestro producto (¿quizá la tienda de ultramarinos de Cuarte?, ¿la cafetería de Walqa ;)?...)
• Que nuestra manera de trabajar podría verse beneficiada del uso de repositorios de código distribuidos (nuestro objetivo de migrar a GIT o similar es como el arco iris, que por mucho que camines hacia él nunca lo alcanzas).
• Que Eclipse es lento para el TDD.
• Que deberíamos hacer alguna retrospectiva de código (algo parecido hacemos con nuestra reunión mensual de "Nuestros mejores bugs", pero no tenemos muchos reparos en ignorar la reunión a poco trabajo que tengamos).
• Que intentáramos desligar funcionalidad transversal para integrarlo en librerías (estamos en proceso ya que Android solo hace muy poco lo permite).
• Que el código que nunca falla es el que no existe (por eso yo nunca creo bugs).
• Y que habláramos y habláramos y habláramos... la (buena) comunicación es siempre la base para que algo funcione (bien).

Y de ahí disparados al Dojo... pero eso será otra historia.