fbpx

Para hablar del lenguaje Gherkin entremos un poco en contexto.

Uno de los mayores retos a los que se enfrentan los Product Owner es crear historias de usuario que comprendan todas las partes involucradas.

Para esta tarea, el desarrollo guiado por el comportamiento (BDD, en inglés) puede resultar muy útil. La historia de usuario es el punto de referencia por antonomasia del Product Owner.

Este elemento, que se redacta, prioriza, detalla, evalúa, desarrolla, prueba y valida, pasa por todo un ciclo de vida antes de guardarse en un cajón una vez que ya ha cumplido su cometido. El Product Owner se encarga de toda la fase de «preparación» de la historia de usuario.

Para dar forma a tu historia de usuario, se recomienda recurrir a los mockups o maquetas. Los mockups no siempre son tan útiles, sobre todo si trabajas con APIs, así que una buena alternativa para enriquecer las historias está en el proceso BDD y, en particular, en el lenguaje Gherkin.

El BDD y el Gherkin

El BDD (desarrollo guiado por el comportamiento) es una metodología ágil propuesta por Dan North que va un paso más allá del TDD (desarrollo guiado por pruebas de software).

El propósito de esta metodología es que se comprenda más a los Product Owner, desarrolladores, testers y cualquier otra parte involucrada, colaborando entre ellos mientras los reúnes en torno a un lenguaje común: el Gherkin.

Para cada historia de usuario, un conjunto de escenarios (de 1 a un máximo de 4) describe el comportamiento esperado en Gherkin:

Dado que ‘contexto inicial’
Cuando ‘un acontecimiento’
Entonces ‘un resultado determinado’

gherkin-historias-usuario-product-owner
Plantilla de una historia de usuario

Los escenarios —que son tan completos como los mockups— ilustran, por ejemplo, lo que se espera de un software tras desarrollar una historia de usuario. Estos escenarios los recoge el equipo de desarrollo, quien los codifica tomando como referencia la historia de usuario a modo de prueba. Una vez pasada la prueba, la historia queda finiquitada.

«Los tres amigos» y la redacción de escenarios

Entre las buenas prácticas del BDD están los talleres de trabajo «Los tres amigos», que pueden resultar muy beneficiosos. El número de participantes no es tan importante como la multidisciplinalidad de los perfiles que se sientan a la mesa.

Lo ideal es que en este taller participen un representante de la tarea (Product Owner), un tester, un desarrollador y una persona del equipo de ventas (según el contexto del producto) para que juntos escriban los escenarios, una vez que el representante de la tarea haya presentado la historia.

Estas sesiones permiten crear una visión común y garantizan que todos los participantes comprenden bien los distintos elementos. Además, permiten ahondar en las historias de usuario y anticipar como grupo los comportamientos esperados (es decir, el conjunto de criterios de aceptación).

A las sesiones hay que dedicarles bastante tiempo, pero son muy importantes cuando el producto comienza a desarrollarse. Con el tiempo, el equipo se acostumbra a hablar el mismo lenguaje de forma natural y el Product Owner (o el tester) puede escribir los escenarios por su cuenta.

Más contenido interesante:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Recibe A Lean Letter

Reflexionemos y debatamos sobre producto el primer martes de cada mes.

¡Apúntate a nuestra newsletter📩!