El pasado día 22 de diciembre celebramos el segundo aniversario del primer coding dojo que organizamos como AGILISMO.es. Luis Rivera, siempre disponible para echarnos una mano, nos prestó las instalaciones de Okuri, también conocidas como Tetuan Valley porque allí tiene la sede esta iniciativa de incubación y aceleración de startups en Madrid. Echamos de menos a Alejandro y Roberto, de Autentia, a los que tanto tenemos que agradecer durante estos dos años. Pero junto a los habituales también estuvo gente nueva. Eso es buena señal.

Hasta aquí no parece un artículo técnico, ¿verdad? Bueno, pues al grano. Durante el desarrollo del coding dojo, con la PomodoroKata como ejercicio, surgió un debate sobre si dejar el número 25 en los primeros pasos del desarrollo es aceptable o no. Xavi defendía la sustitución del 25 por una constante por tratarse de un número mágico mientras que @mikelodeon opinaba que era suficientemente expresivo y que el refactor era prematuro.

Como podeis comprobar en el video de la kata que grabé hace ya dos años, yo también prefiero sustituir el 25 por una constante (minuto 1:40 aprox) por las siguientes razones:

* el método minutesLeft devolviendo 25 es menos expresivo que minutesLeft devolviendo DEFAULT_DURATION
* en el test también hago este refactor aunque el título del test es incorrecto y debería decir "Un pomodoro tiene una duración por defecto", porque realmente me es indiferente cuál sea esa duración
* si realmente hubiera querido probar que la duración por defecto es 25 entonces debería haber tenido un test del tipo: assertEquals("La duración por defecto es 25", 25, Pomodoro.DEFAULT_DURATION), lo que nos habría llevado a pasar esa constante de privada a pública.

Como veis, mis argumentos están basados en la expresividad del código y en que se ajusten a lo que se quiere probar. El trabajo más difícil es siempre elegir bien los tests porque, dependiendo de ellos, nuestro diseño y posterior implementación tomarán un rumbo u otro.

Después de comer le dimos un empujón muy serio a la kata para la XGN porque, entre otras cosas, esa misma tarde habíamos quedado con Ricardo Borillo y otros más para practicar con ella. Cuando llegaron ya estaba suficientemente enfocada y todos accedieron amablemente a servirnos de conejillos de Indias. Xavi hizo una presentación muy clara de la kata. Era como si hiciera meses que estuviera escrita. Aún tenemos que trabajarla un poco más, pero si la XGN fuera esta tarde ya podríamos hacer este taller con perfectas garantías. Trabajar con Xavi da una gran seguridad. Tanta que a veces da miedo.

Poco a poco fue llegando todo el mundo. Emma y algunos compañeros de OpenFinance. Y poco a poco todos los demás. Hasta Ricardo Borillo, que venía de Castellón. Mientras llegaban todos, Emma me hizo una pregunta muy interesante y para cuya respuesta tendré que escribir un post entero: cómo desplegar Fitnesse en Integración Continua y con Control de Versiones. Como yo nunca he usado Fitnesse en Integración Continua sino Fit, no supe bien qué contestarle. Me sonaba pero nada concreto, así que acudimos a Google y, tras varias búsquedas, llegamos a estos dos videos de UncleBob (el autor de Fitnesse):

• http://vimeo.com/2498115 Cómo preparar Hudson para ejecutar la integración continua del proyecto Fitnesse (no entra en detalle sobre cómo se ejecutan los tests de Fitnesse, pero ya es un punto de entrada)
• http://vimeo.com/2765514 Enseña cómo usa él Git para controlar las versiones de sus especificaciones con Fitnesse, con lo que se aprende un poco sobre cómo guarda esta herramienta sus ficheros.

Ambos son videos de hace ya un par de años por lo menos, pero si, como Emma, te estás planteando darle una oportunidad a Fitnesse, quizás te merezca la pena echarles un vistazo.

Durante un par de horas estuvimos completamente absorbidos por la práctica de la codekata. Verdaderamente nos ha salido una kata bastante completa y, a la que nos despistemos, demasiado larga en su resolución. Tendremos que trabajarla bastante aún si queremos mostrar una solución limpia en la XGN. Otra opción es simplemente dejar el enunciado y que los que vengais trabajéis mucho, je, je. Veremos si podemos hacerlo todo porque también tenemos que preparar el taller de backlog y eso va a necesitar mucha más atención por nuestra parte.

Al terminar ese coding dojo privado nos fuimos a cenar. Yo había propuesto pedir algo a un uruguayo muy majete que hace comidas para llevar, pero no hubo mucho éxito. Luego confesaron que ninguno quería dar la impresión de falta de compromiso haciendo una llamada durante el dojo. #FAIL. Terminamos comiendo muuuy tarde, pero no fue tampoco un #EPICFAIL, ni mucho menos. Pasé un rato muy interesante entrevistando a @borillo para @podgramando. Esta vez en video y, por supuesto, con mucho ruido de fondo.

Luego estuvimos hablando sobre la organización de la CAS2011, que este año, gracias a Ricardo, se hará en la Universidad Jaume I de Castellón. Estuvimos escuchando sus planes y, la verdad, ¡ésta no me la pierdo!

Ahora estoy esperando a Xavi para conocer algo de Valencia, que he venido y no he visto casi ná.

Después de comer tomando el sol en la plaza de la Catedral con @luislitze y @elmendalerenda, volvimos a @BeCodeMyFriend para tomar un cafelito y, mientras llegaba un cliente para preparar una visita a una feria de inversores en San Francisco, conseguí sacar la media hora mínima para empezar a trabajar el taller de backlog que también tenemos que preparar para la XGN. Surgieron conversaciones muy interesantes y creo que va a quedar muy bien. Este taller me lo voy a tener que preparar especialmente bien porque Xavi quiere sacarme de mi zona de confort y que lo lidere yo. Me gusta, porque es uno de esos empujones que necesito para saltar al vacío y porque tiene mucho que ver con un terreno en el que me siento especialmente cómodo: los criterios de aceptación (que idealmente deberían estar automatizados).

Y al final de la tarde ya nos fuimos yo con mi camiseta de agilismo.es y Miguel Angel con la de BeCode al Coding Dojo que se celebraba en la Escuela de Informática (la ETSINF). Xavi, por supuesto, iba con sus pintas de siempre. Las mismas que había llevado para visitar a un cliente y conseguir varios contratos, por cierto.

En la ETSINF me buenas instalaciones, aunque para ser la Universidad, muy poca audiencia. Eso sí, al final tuvimos conversaciones muy interesantes con algunos de los asistentes. Durante el ejercicio dimos varias recomendaciones de libros: “Refactoring“, “Implementation Patterns“, “TDD by example“, “Desarrollo Agil con TDD“, “Clean Code” y, por supuesto, “The Pragmatic Programmer“. A los que quedaron al final, charlando con nosotros sobre lo poco que se aprende en el trabajo, también les recomendé “Apprenticeship Patterns“.

La codekata que propusieron Miguel Angel y Xavi era FizzBuzz. No me deja de sorprender esta kata por la cantidad de cosas que se pueden practicar y cómo, siendo tan simple, te permite hablar de tantas cosas: naming, refactor (no sólo los refactors “hacia adelante”, sino también los “hacia atrás”), duplicación, código limpio, baby steps… Tanto es así, que me he empezado a reproducir la kata en el portátil usado git y poniendo un comentario en cada commit. Cuando lo tenga lo subiré a github.

Y bueno, cena con una agradable conversación con Miguel Angel y a la cama.

En el artículo de Robert C. Martin (@unclebobmartin) que hemos traducido en Agile Spain por “¿Qué es toda esta tontería de las katas?”, el maestro UncleBob lo dice bien claro:

(…) la ejecución no es el objetivo. Ni los expertos de artes marciales practican su arte para que puedan realizarlo en un escenario. Un artista de artes marciales practica para alcanzar la perfección personal en el arte de la defensa personal. El hecho de que la práctica se pueda realizar es un (agradable) efecto secundario.

Y ése es justamente el objetivo de agilismo.es (Xavi Gost y yo mismo) a la hora de plantear este coding dojo: conseguir ese (agradable) efecto secundario mientras practicamos por el mero placer de mejorar individual y colectivamente.

Contenidos recuperados

Tengo pendiente la segunda parte de la explicación de cómo conseguí importar mi viejo blog usando Groovy y la API de Google Reader. Esto es algo que requiere bastante esfuerzo pues, aunque tengo el código escrito, hay que explicarlo convenientemente (no es mi mejor pieza de código y no es suficientemente autoexplicativa) y además tengo que buscar un plugin de WordPress o algo que permita que el código fuente se vea decentemente. Se admiten sugerencias.

Claro, ahora que Google ha tenido a bien devolverme el viejo blog, algunas tareas de mejora sobre el proceso de recuperación pierden interés (me refiero a que hay anuncios que han quedado empotrados en los artículos importados y a que los enlaces han quedado apuntando al viejo blog) y aparecen necesidades nuevas. Lo primero que he hecho ha sido hacerme una copia de seguridad tanto de los contenidos -incluyendo los comentarios y la plantilla- y lo segundo poner un aviso de que me he mudado “para que conste”. Así que ahora he pensado que lo ideal sería importar esa copia de seguridad al nuevo blog, pero tengo que hacer una prueba en local y todo eso antes de hacer el cambio… y me está dando una pereza…

En cualquier caso, prometo escribir (pronto) la segunda parte del artículo sobre cómo importé el contenido del viejo blog. Aunque sólo sea porque lo prometido es deuda.

Reunión Agile Madrid

Tengo también pendiente el resumen de la última reunión del grupo local de Agile Spain en Madrid. Lo que pasa es que Alberto Peña (@plagelao) ha hecho tan buen resumen en su blog que casi que me voy a quedar en dejar constancia y poco más. Ya he subido las diapositivas que utilicé, pero no subiré las notas que escribí para ayudarme porque realmente no aportan nada a la presentación. Sólo para quede constancia: no es ni mucho menos mi mejor presentación; y me alegro mucho, mucho, de que se me olvidara comprobar el espacio en disco antes de empezar a grabar el video, y vuelvo a pedir disculpas públicamente a mis compañeros del grupo de Agile Spain por no haberme preparado bien la presentación. Podríamos haber aprovechado mucho más la reunión. Aunque son gente estupenda: no hicieron sangre conmigo y además me ayudaron a que el resultado final de la reunión fuera muy positivo.

Mi resumen de la discusión es el siguiente:

La confianza es el valor más difícil de alcanzar dentro de un equipo que se quiera autoproclamar ágil. Confianza en sí mismos, confianza entre ellos y confianza hacia el exterior (incluyendo a otros departamentos y, sobre todo, al cliente).

Yo siempre había pensado que la clave estaba en el coraje y la autoexigencia, pero después de esta reunión me di cuenta de que éstos son valores individuales, que requieren un esfuerzo individual. Pero el mayor obstáculo para ser ágil es un obstáculo colectivo: la confianza. Es relativamente fácil confiar en uno mismo, pero confiar en los demás… ay, ay, eso ya es otra cosa. Y que los demás confíen en nosotros… eso ya ni te cuento. ¿Verdad?

Agilismo.es

También estoy arrancando agilismo.es con el inefable Xavi Gost. Queremos hacer de agilismo.es un portal de referencia para el agilismo desde su perspectiva más de las trincheras. Hay ya muchos portales en español sobre Scrum y en general desde un punto de vista de la gestión de los proyectos. Por ejemplo, Proyectos Agiles (que dirige Xavier Albaladejo) es muy buen punto de referencia para esto. También Scrum Manager (iniciativa de Juan Palacio). Pero hemos visto que hay una gran carencia de contenidos de calidad cuando nos ponemos a buscar, desde el punto de vista de los desarrolladores, referencias en español sobre Extreme Programming, Integración Continua, TDD, Programación por Parejas, etc.

Ahora mismo es poco más que una “página güeb” donde este tipo y yo nos ofrecemos para dar coaching, pero no dudéis que va a ir creciendo rápidamente, con contenidos propios y de calidad.

iExpertos.com

Con Carlos Blé y su iExpertos.com tengo una relación muy curiosa. Además de proporcionarme “por la cara” el wordpress donde tengo mi nuevo blog, Carlos se ha empeñado en que yo puedo dar cursos. Bueno, a mi también me ha parecido buena idea, claro. Yo le había propuesto dar un taller sobre Integración Continua, pero no cuajó. Ahora parece que hay posibilidades de uno sobre Refactoring. Éste es más complicado porque requiere preparar muy bien el material. Pero me parece un taller muy, muy bonito. Ya veremos si sale y si lo puedo hacer yo o lo hace el propio Carlos, que de eso también sabe.

Por otro lado, hace tiempo le comenté que podríamos hacer un podcast “agilismo.es powered by iExpertos.com” y el tío ya tiene casi todo montado. Hasta hemos tenido que decir que no a Jorge Rubira para grabar un podcast de JavaHispano sobre el Agile Open Spain 2009, porque queríamos sacar el primer podcast antes de Navidades y Jorge ya no tenía hueco. Carlos es un tipo muy emprendedor e incluso se ha buscado un amigo que nos ha hecho una sintonía para no tener que pagarle a Ramoncín. Je, je.

También estamos pendientes, junto con Gregorio Mena, de arrancar una serie de webinars. Esto último es mucho más complicado incluso que el podcast, que ya tiene miga. Pero si conseguimos darle forma va a ser un bombazo.

¡Ah! Y el ya casi famoso libro de TDD de Carlos… adivinad quién ha escrito el prólogo… y no es el típico prólogo. Pero para saber de qué va lo tendréis que descargar. ¡Que será gratis!

Trabajo

Y la noticia de la semana es que ya tengo trabajo. La verdad es que ya casi tenía trabajo. Estaba a punto de cerrar un acuerdo para teletrabajar de “freelance” programando un par de aplicaciones JSF en un equipo scrum de tres personas (una jefa de proyecto, un junior y un servidor). Iba a ser mi primera experiencia como trabajador por cuenta propia. Pero hablo en pretérito imperfecto porque ayer por la mañana fui a una entrevista a la que había llegado convocado a través del INEM. (Sí, ya sé que es un poco extraño, pero ha sido así). Y resulta que he aceptado trabajar en un proyecto de 6 meses para el Ayuntamiento de Alcobendas. Bueno, y ellos también han aceptado trabajar conmigo, claro.

Estoy seguro de que va a ser un proyecto muy bonito en el que voy a poder aprender mucho. Creo que será muy bueno también para el Ayuntamiento, para los empleados a los que voy a ayudar y en última instancia para los ciudadanos. Durante la entrevista les expliqué por encima esto del agilismo y “alucinaron”. Claro. Les gusta mucho eso de ir teniendo “software que funciona”. Pero a continuación les cambia el gesto cuando se acuerdan de “las cosas de palacio van despacio”. Je, je. Dentro de un par de meses ya veremos quién ha sido más testarudo: si yo y mi “agilismo de guerrilla dentro de la recalcitrante administración pública” (parece el título de una peli de miedo) o ellos con su “no, no nos moverán”. Sospecho que ganaré yo. Mis armas son mucho más poderosas. Estoy dotado de un optimismo a prueba de bomba y ellos no. Todavía.

Coding Dojo

¡Pero esto NO es todo, amigos! El día 22 (el día de la Lotería) estamos montando un “coding dojo” en las intalaciones que Okuri Spaces tiene en el barrio de Tetuán (en Madrid). El maestro Xavi Gost vendrá a darnos una clase de su kung-fú programando en Java una aplicación para hacer un “pomodoro”. Y eso en un “pomodoro” de duración: 25 minutos. La sala es pequeña (apenas cabrán sentados unas 20 personas), pero lo grabaremos, tranquilos. Será gratis y la idea es que nos sirva para promocionar “agilismo.es powered by autentia“, que si todo va bien será una iniciativa muy interesante relacionada con la formación de calidad y de la que por el momento no os puedo comentar más porque tampoco hay mucho más y porque, ¡qué caramba!, hay que crear un poco de expectación.

En fin, esperemos a ver qué tal nos lo pasamos en el Dojo y si alguno de vosotros se decide a venir, no olvidéis saludarme, que a todo bloguero le hace ilusión conocer a sus lectores.