Comunicación ágil, pero comunicación

Uno de los principios fundamentales del manifiesto para el desarrollo ágil explicita que “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Ciertamente, es imprescindible que responsables de negocio y desarrolladores tengan una vía de comunicación lo más ágil y efectiva posible (“Para comunicarnos efectivamente, debemos darnos cuenta de que todos somos diferentes en la forma en que percibimos el mundo y usar ese conocimiento como guía para comunicarnos con otros.”-Tony Robbins). De hecho, este es un reto relevante en muchos proyectos. El objetivo de fondo es la búsqueda continua del alineamiento entre las expectativas y la realidad del sistema desarrollado en cada momento, teniendo en cuenta la necesidad de buscar una forma de comunicación adaptada a ambos perfiles (“Piensa como un hombre sabio pero comunícate en el lenguaje de la gente.”- William Butler Yeats). Para validar y asegurar dicho alineamiento es imprescindible diseñar, realizar pruebas y reaccionar ante posibles defectos funcionales detectados. Disponer de un rol experto en el diseño y la ejecución de pruebas, integrado también en esta estrategia de comunicación, es también esencial para maximizar la utilidad de las pruebas.

En los entornos ágiles, la comunicación debe ser fluida, de acuerdo. Pero a la vez debemos intentar asegurar que sea efectiva y adaptada a cada contexto (“El problema más grande de la comunicación es la ilusión de que ha tenido lugar.” -George Bernard Shaw.). Por ello, en determinados proyectos, no es suficiente el principio del manifiesto ágil: “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.”. Hacer esta consideración es especialmente importante en equipos distribuidos, con distintas disponibilidades para ser agentes continuos de la comunicación oral, etc. Es importante, por tanto, que en los proyectos ágiles no se simplifique la estrategia de comunicación y que se defina al inicio del proyecto teniendo en cuenta las características particulares del mismo. Y ello incluye tanto comunicación cara a cara, como artefactos de especificación por escrito (“El arte de escribir es el arte de descubrir qué crees.” –Gustave Flaubert). Por ello, las user stories se han convertido en artefactos de especificación ágil comúnmente aceptados. Aun así, depende del grado de calidad de las user stories, las posibilidades de comunicación efectiva variaran (“La comunicación funciona para aquellos que la trabajan.”-John Powell).  En este sentido, en los proyectos ágiles cabe preguntarse también:

• Las user stories se definen usando patrones que restringen la sintaxis para que sean menos ambiguas, más especificas y más estandarizadas? Un patrón de sintaxis comúnmente recomendado es: As a <type of user>, I want <some goal> so that <some reason>.
• Las user stories evolucionan a lo largo del proyecto y se descomponen en otras más específicas que se puedan abordar una sola iteración ágil? Por ejemplo, podemos tener la historia de usuario Realizar una compra, pero deberá tener historias más específicas para poder implementarla, como por ejemplo Realizar el login, Añadir un ítem a la cesta de la compra, Confirmar la compra, Realizar el pago, etc.
• Las user stories tienen acceptance criteria para definir las condiciones de validación/aceptación de las mismas? La definición de criterios de aceptación es esencial para inducir la factibilidad de las historias y suponen conocimiento explícito necesario para concretizar las historias e, incluso, disponer de una base más sólida para diseñar y realizar pruebas con una base de especificación. Si, además, las user stories se escriben en un lenguaje semiformal como Gherkin (un lenguaje de Business-Driven Development), entonces determinadas tareas de pruebas (generación de casos de prueba o automatización) pueden realizarse de forma más eficiente o incluso de forma automática.

Con user stories que cumplan estas características, los perfiles de negocio, de desarrollo y de testing, pueden disponer de una base de conocimiento útil para todos ellos. Aun así, cabe observar que esta información, por sí sola, no sirve aún para definir casos de prueba end-to-end a partir del conocimiento descrito en las historias. El motivo es que la descomposición de historias no es suficiente si no se describen los posibles flujos de aplicación de estas historias para realizar funcionalidades descritas en historias más generales (por ejemplo, saber si para realizar una compra, puedo añadir más de un ítem, si debo hacer login antes o no, etc.). Por ello, con el fin de reutilizar las user stories al máximo para las actividades de testing, una buena práctica es enriquecer dicha descomposición de historias de usuario con esbozos de posibles flujos. Teniendo en cuenta todo esto, la derivación automática de casos de prueba a partir de user stories y su evolución automática a cada iteración ágil no es un objetivo inalcanzable.

Albert Tort

Especialista de Software Control & Testing en Sogeti España