Una de Concordion

Con esto del Agile Open Spain 2009 estoy dejando de mano muchas cosas, pero no quiero abandonar el blog, así que aunque sean casi “microblogs” voy a intentar no dejar de escribir.

Dicho esto, voy a aprovechar que para el próximo miércoles en el grupo de Agile Spain en Madrid me he comprometido a hacer una presentación de 5 minutos para defender el tema “Pruebas de Aceptación Automatizadas con Concordion” y voy a dejar un par de apuntes aquí.

En el estupendo blog “Dos Ideas” he visto hace poquísimo un artículo con un par de screencasts en español sobre cómo usar Concordion + Selenium. Muy útil.

Para los que utiliceis .NET y queráis usar Concordion.NET, éste es vuestro blog (en inglés).

Lo siento, no hay tiempo para más. :(

El fin del verano


El fin del verano llegó. Ya estamos de vuelta en el cole, se acabaron las vacaciones, la playa, también se acaba el calorcito, las terracitas… Igual que con el principio de año, las listas de propósitos de enmienda proliferan. En mi caso, mi periodo sabático se ha acabado y comienza un periodo diferente: el de salir del desempleo. Para mi particular inicio de curso tenía algunas tareas e incluso asignaturas pendientes. Con vuestro permiso voy a hacer un recuento público del estado de las mismas.

Mi caja de herramientas

Hace algo más de un año me dije que tenía que mejorar mis conocimientos teóricos y prácticos en varios aspectos de la Ingeniería del Software (concretamente SOA y DDD), montarme un ecosistema software (con su control de versiones, su integración continua, su wiki y todo) y añadir a mi caja de herramientas algunos frameworks, herramientas y lenguajes a los que hacía tiempo que les tenía ganas (concretamente Wicket y Spring 2.5, con sus anotaciones y todo, un DVD con herramientas de IBM que sigue en la estantería aún sin abrir, y Ruby y Groovy).

Bueno, SOA salió de la ecuación bastante rápido. Demasiadas cosas y ya se sabe: “el que mucho abarca, poco aprieta”. Aunque pude asistir a una charla que dió Udi Dahan en Madrid gracias a iMeta y que, además de aclararme un montón de dudas, me enseñó cómo hacer “SOA de verdad”, con servicios realmente autónomos. En cuanto a DDD, sigo ahí peleándome con el calendario y mis obligaciones diarias, pero algún día conseguiré tener mi ejemplo “end-to-end” para poder explicar esto de los repositorios, la “ignorancia de la persitencia” y todo eso que cuando lo lees resulta tan elemental pero a la vez tan difícil de traducir en líneas de código. Incluso creé en su momento un googlegroup, pero me temo que no le estoy dedicando tiempo ninguno y pido disculpas por ello.

El ecosistema software está funcionando en mi portátil a pleno rendimiento: Hudson, Subversion, Dokuwiki, Maven, Eclipse. ¿Se me olvida algo? ¡Ah! ¡Sí! Sonar. Aunque éste lo tengo un poco aparcado… Me quedan en el tintero afinar cosas como tener una buena estructura para los builds con Maven y las pruebas de integración y funcionales, probar cómo va eso de Git, probar el Testability Explorer de Misko Hevery (que por cierto tiene un blog sobre testing muy recomendable).

En cuanto a Wicket, he hecho mis pinitos, pero tengo que explotarlo aún más. Desde luego, lo que tengo claro es que antes muerto que JSF. :) Spring 2.5 está más o menos dominado: no era tan complicado. Y mi relación con Ruby-Rails y Groovy-Grails es un poco rara. No termino de creer en ninguno de los dos, pero aun así este verano he estado insistiendo a mi sobrino Nico para que aprendiera, le instalé el Aptana y le ayudé a refactorizar alguno de sus ejemplos de Ruby (el pobre no había llegado al capítulo de las subrutinas y yo dándole caña, ¡es que no tengo corazón!). El día 3 voy al curso que Escuela de Groovy organiza junto a JavaHispano. Este verano he estado jugando (no me atrevo a decir más) con Eclipse y un plugin bastante apañado, pero sigo sin “pillarle el puntillo”. No sé, debe ser que me pilla un poco viejo o que he perdido el gusto por programar…

Para no perder la práctica he estado entrenando un poco, pero claro, nada serio. Quizás lo más interesante fue el ejercicio del libro de Refactoring. Por cierto, me estoy haciendo (a ratos, porque no consigo tener la continuidad ni la serenidad de espíritu necesarios) un codekata que me está resultando bastante interesante.

De todos modos, hay temas que han salido de mi caja de herramientas (por lo menos por una buena temporada) como OSGi o JAX-WS.

Concordion

¡Ay! Mira que tengo ganas de poner lineas de código mías en Concordion. Incluso tengo un “issue” asignado desde hace la tira… pero de veras que no consigo sacar el tiempo necesario para programar. Ni pomodoros ni nada. Eso sí, conseguí mavenizarlo y que las “releases” se publiquen automáticamente en el Repositorio Central de Maven.

Tengo a medias un taller sobre especificaciones ejecutables que quiero armar usando Concordion, pero una vez más… “el que mucho abarca poco aprieta”.

Agile Spain

Realmente éste ha sido y es mi gran caballo de batalla. En principio mi interés consistía en formarme “formalmente” en esto del agilismo. Así que me apunté a un curso de Scrum de dos días que no tenía mala pinta y que no era “fu*ing expensive” como los CSM. Además lo daba un andaluz, como yo. Mala suerte. Me nació el pequeño en medio del curso. Por suerte, Ángel es un tipo muy amable y comprensivo y me dejó repetir el curso (desde el principio, je, je).

El 7 de junio de 2008 creé la lista de correo “heredando” el nombre de una comunidad que había ido languideciendo en los últimos años, pero no hubo nadie más hasta el 21 de julio que se añadió Juan Gutiérrez desde Finlandia. Pasaron algunos meses hasta que Jorge Uriarte y Xavier Quesada propuesieron la refundación y ahora somos 230 en la lista (aunque seguro que hay más gente que la lee y no está suscrito, pero los Googlegroups no dejan poner Google Analytics :( ) e incluso vamos a organizar el primer Agile Open en España, con 150 asistentes y una lista de espera que nos lleva hasta los 233 que hay ahora mismo. Pero es que además, para primavera queremos organizar algo aún más grande, como ensayo para una conferencia a nivel internacional. El día 2 nos han invitado a una reunión en red.es para ver de qué manera podemos colaborar. !A mi se me ocurren muchas ideas! Y también estoy en contacto con Agoranews (los que están haciendo la cobertura audiovisual del SIMO). Ojalá de unos o de otros podamos conseguir que se graben algunas o todas las sesiones del Agile Open, pero queda poco tiempo así que no sé. ¡Pero apretaré para el evento que haremos en primavera!

Buff, pero éste no era mi objetivo cuando empecé con esto de Agile Spain. Yo sólo quería hacer que los que hacían agilismo en España “salieran del armario”, de esa manera, pícaro yo, sabría a quién enviar mi CV. Pero la cosa se ha salido un poco de madre y me han invitado a grabar un par de podcasts (uno para JavaHispano y otro para 32minutos). Pero el colmo ha resultado cuando desde la Tenerife LanParty 2009 me han invitado a dar una charla sobre esto del agilismo. Y encima han quedado muy contentos y todo. Total, que resulta que cuando escribes en Google “agilismo” salgo en casi todos los primeros resultados. Vamos, que casi sin haberlo querido estoy bien posicionado.

Viendo que esto parecía que me abría una oportunidad profesional interesante, decidí explorarla este verano. Para ello he empezado a trabajar en un estudio de mercado sobre “agile coaching” en España. Quiero aprovechar el Agile Open para pasar una encuesta a los asistentes y así poder sacar conclusiones un poco más científicas que simplemente una sensación. Luego dejaré el estudio a dominio público porque para mi ya será suficiente y, quién sabe, quizás ayude a otros a decidirse por un camino similar.

He hablado con varios emprendedores y freelancers (con Ángel, con Abel, con Leo, con Xavi) y todos me dicen que adelante, sin miedo. Pero yo soy un “cagao” y tengo muchas reticencias. ¿De verdad se vive mejor como autónomo? Mi madre, hace muchos, muchos años, era propietaria de una tienda de ultramarinos (que antiguo suena eso) y estaba esclavizada por su trabajo. Por cuenta ajena, al menos tienes un horario (que tienes derecho a respetar). Pero claro, conociéndome, ese argumento suena a “excusa barata”.

Así que, claro, ahora me surge una pregunta: ¿Y ahora qué? ¡Ah! ¡Sí! Pues decidir si preparo el CV y lo subo a Jobsket o, por el contrario, preparo un porfolio de servicios y me hago freelance “porlagloriademimadre”.

Salvando las distancias

Voy en metro, ilusionado, camino del segundo día del curso de Scrum de Medinilla. Y me he pillado el libro de Gojko Adzic “Bridging the Communication Gap” porque ayer surgió el tema de las especificaciones ejecutables y los roles dentro del equipo. Pero estoy un poco desentrenado porque hace mucho que no voy en metro con tiempo para leer, y el iPod lo tengo vacío de podcasts por escuchar, así que me he puesto la “música aleatoria” y mientras escucho de lo más variado (desde la deliciosa Joy Denalane hasta M-Clan, que no veas cómo me animan) he pensado en tomar notas para cumplir con una “cierta obligación”: explicar lo que me ha parecido el libro.

Gojko Adzic es un tipo que habla en inglés con un acento balcánico realmente difícil de seguir (al menos para mi), así que pensé que era buena idea comprar el libro para entender a qué se refiere cuando habla de talleres de especificaciones y de pruebas de aceptación ejecutables en entornos ágiles. Además, Gojko Adzic también imparte cursos sobre Domain-Driven Design y esa relación entre DDD y pruebas de aceptación es algo que me interesa bastante.

Voy a ser sincero, también compré el libro porque es el primero en el que se habla de Concordion, la herramienta open source en la que modestamente colaboro. Pero son apenas unas páginas y el valor del libro es mucho más que eso.

Adzic explica la importancia de que “la gente del negocio” hable el mismo idioma que “la gente técnica”. Esto muchos lo entienden como obligar a clientes y usuarios a que hablen en términos tecnológicos como “altas, bajas, modificaciones y listados (CRUD en inglés)”, o peor aún, de tablas, campos y relaciones.

En DDD hablamos de un lenguaje ubícuo, o único en todo el proyecto, y que es el que usan tanto técnicos como usuarios. Esto permite reducir los defectos producidos por malentendidos y tiende puentes entre ambos mundos, abriendo la posibilidad a una verdadera colaboración.

Un inciso melancólico. Voy ahora mismo montado (mientras escribo estas notas en mi moleskine) en el metro ligero y me he acordado de ese par de meses intensos que viví y trabajé (sobre todo lo primero) en Melbourne (Australia). Allí fui usuario del “tram” y he de decir que me parece un medio de transporte público de lo más interesante porque es a la vez rápido, cómodo y silencioso.

Pero sigamos con el libro. El grueso del mismo se basa en hablar del “agile acceptance testing” y de cómo buscamos ponernos de acuerdo en qué es lo que hay y lo que no hay que desarrollar. Para esto usamos ejemplos realistas en vez de requisitos abstractos. “Los ejemplos demuestran cómo debería actuar el sistema y cómo debería ayudar a los usuarios a hacer su trabajo”. Adzic propone que estos ejemplos sean creados por todo el equipo de implementación, no sólo por un “experto del dominio” (también conocido como “analista de negocio”) como en modelos de desarrollo más tradicionales. “Usamos los ejemplos para discutir el dominio y asegurarnos de que no hay malentendidos”.

Según Adzic, el uso de ejemplos realistas obliga a pensar más acerca de los problemas. De hecho, comenta cómo se producen muchas discusiones entre los expertos cuando se plantean ejemplos para casos extremos; discusiones que incluso les hacen a veces revisar sus propios procesos de negocio. ¡Vaya! Si resulta que podemos ayudar a nuestros clientes en vez de simplemente observar su comportamiento “desde fuera”, como si fueramos “supernanis con corbata”.

Damned! ¡Me he saltado una parada! Estaba tan concentrado… Menos mal que la frecuencia del metro ligero éste es alta y he podido llegar sólo un par de minutos tarde. Buff…

De vuelta del estupendo curso de Ángel Medinilla, sigo con el resumen del libro y me fijo en que no he explicado esto de los ejemplos. Vamos, que no he puesto ejemplos de ejemplos. :-) Adzic pone un ejemplo en la página 45 de una regla de negocio relacionada con el descuento que le podemos ofrecer a un cliente, pero a mi me gusta más el que explica David Peterson en la web de Concordion. Es bastante más completo porque nos lleva desde la historia de usuario (el requisito) hasta la prueba de aceptación automatizada (en forma de ejemplos). Es interesante cómo David hace mucho hincapié siempre en que debemos especificar con ejemplos que expliquen comportamientos muy elementales y dejar para otras especificaciones todo aquello que quedaría fuera. Son los “Further details” en el ejemplo. También Adzic habla de esto en su libro, pero menos; y yo creo que es importante esta anotación al margen para aquellos que queráis “tomar este camino” para hacer pruebas de aceptación.

En “Bridging the communication gap” también se explica cómo conducir estas reuniones (talleres de especificación) e incluso aconseja sobre algunas herramientas. Pero creo que es interesante explicar cómo pueden encajar estos talleres en nuestro calendario semanal (ágil).

Adzic sugiere lo siguiente:

Release es todo aquello que hacemos después de la demo para dejar bien cerrado el sprint. Etiquetamos en subversion, hacemos copias de seguridad, ponemos las versiones del nuevo sprint en los pom.xml (si usamos Maven y si es que tenemos que cambiar de versión), limpiamos las pizarras… y mientras esto lo pueden ir haciendo algunos desarrolladores (típicamente los becarios, je, je) pues el resto puede estar preparando el sprint primero revisando el backlog y luego, ya con los becarios incorporados, estimando las historias y decidiendo lo que se podrá hacer razonablemente en el sprint (las próximas dos semanas).

Ojo, es una manera de organizar el trabajo durante un sprint, pero lo importante de esto es que el dueño del producto (también conocido como jefe de proyecto, analista de negocio, o incluso tester, según vuestro “mapeo” preferido) se encarga de trabajar las historias de usuario (redacción y priorización) y de los ejemplos (criterios de aceptación) antes de los talleres de especificación, pero realmente es el equipo en su totalidad quien acuerda lo esencial de los criterios de aceptación mediante la discusión que se ofrece en esta reunión. Para los que ya estéis algo picados con esto del agilismo, me permito recordar “las tres Ces” (card, conversation, confirmation). Éste es el momento ideal para la conversación, aunque ya se haya tenido una conversación previa cuando se han estimado las historias de usuario en el Sprint Planning Meeting (usando terminología Scrum).

Bueno, y hasta aquí hemos llegado. Espero que os resulte útil. Y si alguien más se ha leido este libro y quiere contrastar aquí su opinión, estaré encantado de poder charlar con vosotros porque mi intención es preparar una presentación (o un taller, ya veré) sobre este tema y exponerla bajo el “paraguas” de Agile Spain.