En este post hablamos de las historias de usuario que aportan valor al producto y que son entendibles por todo el equipo de desarrollo, generando un canal de comunicación entre negocio y los equipos técnicos. Profundizamos en qué son las historias de usuario y cómo escribir buenas historias de usuario a través de ejemplos.
¿Qué son las historias de usuario?
Las historias de usuario, dentro del marco ágil, son los requisitos del software que nos aportan los responsables del negocio o cliente con el que trabajamos. Estas historias de usuario deben de formar parte de la validación del producto o proyecto digital en desarrollo. Es decir, deberían ser las pruebas de aceptación que tiene que superar el software en su ciclo de desarrollo para al menos convertirse en el mínimo producto viable antes de salir al mercado.
Además, las historias de usuario son la documentación viva del proyecto, una guía funcional para entender cómo tiene que funcionar el software. El objetivo es conseguir que los responsables del negocio nos transmitan los requisitos de forma correcta para que sean entendidos por los diferentes equipos técnicos y además sean convertibles en casos de pruebas.
Si se trata de colaborar con el negocio y con el cliente, ¡vamos a trabajar juntos para que las historias de usuario aporten valor!
En resumidas cuentas, las historias de usuario son ejemplos de cómo tiene que funcionar el software, con el objetivo de entregar un software de calidad. Y, sería muy interesante si podemos automatizar dichas historias para que en cada sprint se cumplan los requisitos priorizados del cliente pasando las pruebas de aceptación.
Beneficios de trabajar con historias de usuario
Algunos de los beneficios de escribir historias de usuario con lenguaje natural son:
- La comunicación entre el equipo de negocio y el equipo técnico.
- Tener la documentación funcional del proyecto.
- La automatización de pruebas de aceptación.
Cómo escribir una historia de usuario
¿Qué es BDD (Behavior-driven development)? Es un proceso de desarrollo de software nacido desde el desarrollo guiado por comportamiento. El BDD y las historias de usuario son lo mismo. Por lo que se recomienda escribir las historias de usuario en lenguaje Gherkin con el famoso framework Cucumber. Os dejamos la guía de referencia de Gherkin donde los ejemplos de patrones deberían ser como en la siguiente imagen :
Como hemos comentado, estos escenarios/ historias de usuario sirven como documentación de la funcionalidad del proyecto. Además, pueden servir para automatizar las pruebas de aceptación. Pero, ¿debemos automatizar todo? En ocasiones puede llegar a ser más costoso hacer la implementación de la prueba que el propio desarrollo. Por ello, hay que automatizar lo que más aporte valor. Tengamos en cuenta que las pruebas automáticas consumen recursos, tiempo, servicios… Aunque no se implementen, siempre aportan valor para que el desarrollador entienda cómo debería funcionar el software.
Plantilla y ejemplos de historias de usuario
Siguiendo las referencias de la guía de Gherkin, los pasos a seguir para escribir una historia de usuario son:
- GIVEN: Son los pasos dados que se utilizan para describir el contexto inicial del escenario. Por lo general, debe ser algo que sucedió en el pasado.
- WHEN: Son los pasos que se utilizan para describir un evento o una acción. Se recomienda que solo se tenga un único paso por escenario. Si se considera agregar más, es claramente una señal de que se debe dividir el escenario en varios.
- THEN: Son los pasos que se utilizan para describir un resultado o resultado esperado.
Ahora vamos a poner dos ejemplos de cómo escribir una historia de usuario que representen un escenario de acceso a una plataforma siendo un usuario básico o usuario administrador:
- Escenario A: Acceso de usuario básico
Dado que soy un usuario de la plataforma
Cuando accedo a la aplicación con “usuario” y “contraseña”
entonces quiero ver mi posición global donde aparecen todos mis productos contratados
- Escenario B: Acceso de usuario administrador
Dado que soy un usuario administrador
Cuando accedo a la aplicación con “usuario” y “contraseña”
Entonces quiero ver el listados de usuarios registrados
Algunos consejos para escribir buenas historias de usuario
A la hora de enfrentarse a escribir una historia de usuario, se debería cumplir con lo siguiente:
- Utilizar lenguaje natural.
- Escribir las historias de usuario entendibles por todos los equipos.
- Dar datos de interés y reales para entender la finalidad del escenario.
- Poner varios ejemplos reales del negocio para que el equipo técnico entienda los requisitos.
- Si el escenario es complejo, es mejor dividir en varios escenarios.
- Seguir un orden lógico de ejecución de escenarios. Es decir, si se trata de una plataforma con área privada, escribir primero los escenarios de acceso antes que los escenarios de funcionalidades con necesidades de datos de usuarios.
Conclusión
Como conclusión, al escribir historias de usuario con lenguaje natural, se considera que todos los requisitos tendrán el mismo formato y será más fácil de entender para el equipo de desarrollo y así poder afrontar la implementación con mayor facilidad para mejorar en la velocidad de desarrollo.
Además, es realmente importante trabajar la comunicación entre los equipos de negocio y los equipos técnicos para conseguir los resultados esperados y no encontrarse con la sorpresa de un desarrollo no deseado o que no aporte valor.
Como resultado de escribir historias de usuario se va a obtener la documentación del proyecto, además de poder automatizar pruebas de aceptación.
Aprende más sobre metodologías ágiles en nuestro canal de YouTube. ¿Te gustaría desarrollar un proyecto de desarrollo de software ágil? ¡Contáctanos!
