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.