DEFINICIÓN DE UNA HISTORIA DE USUARIO
Una historia de usuario es una descripción de funcionalidad o parte de funcional escrita en el lenguaje cotidiano o de negocio que captura lo que un usuario hace o necesita hacer.
Las historias de usuario proporcionan una forma rápida de manejar los requisitos del cliente en lugar de documentos formales de requisitos y sin realizar tareas administrativas relacionadas con su mantenimiento.
BENEFICIOS
Especialistas de nuestra empresa formularon beneficios del uso de historias de usuario para cada miembro del equipo de Agile:
PARA LOS GESTORES DE PROYECTOS:
- Ayuda a realizar la arquitectura de la aplicación correctamente;
- Reduce el tiempo de responder a las preguntas sobre la lógica de la aplicación a los desarrolladores, diseñadores, testers;
- Puede utilizarse como documentación y actualizarse fácilmente;
- Da una idea de la cantidad de mock ups necesarios para cubrir toda la aplicación de diseño;
- Avisa del exceso o la falta de ciertas pantallas / botones / características;
- Las características son la base para escribir pruebas de aceptación con el desarrollo dirigido por pruebas (TDD y BDD);
- Ayuda a evitar malentendidos de la documentación (especificaciones y requisitos del cliente), y errores en la lógica de la aplicación;
- Sirve de base para escribir casos de prueba y escenarios de prueba;
- Ayuda a comprender rápidamente la lógica de la aplicación;
- Da una buena comprensión de una aplicación y su funcionamiento;
- El cliente puede describir la nueva funcionalidad, utilizando nuestro formato de Historias de usuario que evita la mala interpretación de los requisitos;
PARA LOS DISEÑADORES:
PARA LOS DESARROLLADORES:
PARA EL QA:
PARA LOS CLIENTES:
FORMATOS DE HISTORIAS DE USUARIO
También puedes conocer los siguientes formatos de una historia de usuario:
Mike Cohn, un conocido autor de historias de usuario, respecto a la cláusula «so that» como opcional:
«Como <role>, Quiero <objetivo/deseo>»
Chris Matts sugirió que «cazar el valor» era el primer paso para entregar con éxito el software, y propuso esta alternativa como parte de Feature Injection:
«Para <recibir el beneficio> como < rol>, Quiero <objetivo/deseo>»
Otras opciones:
«Como < rol>, Quiero <objetivo/deseo> para que <se beneficie>»
«Como < rol>, Puedo <actuar con el sistema> para que <beneficio externo>»
En la empresa Steelkiwi utilizamos el lenguaje Gherkin para hacer una historia de usuario más legible y comprensible tanto para los desarrolladores como para los clientes.
DEFINICIÓN DEL LENGUAJE GHERKIN
Gherkin es un lenguaje legible por humanos para la descripción del comportamiento del sistema, que utiliza la sangría para definir la estructura del documento (espacios o tabulaciones). Cada línea comienza con una de las palabras clave y describe uno de los pasos.
La mayoría de las líneas en el Gherkin comienzan con una palabra clave especial y consisten en características y escenarios, por ejemplo:
Veamos el ejemplo anterior:
1. Característica: Una descripción corta pero completa de la funcionalidad requerida, que inicia una función y le da un nombre.
2. Las siguientes tres líneas describen el beneficio que vamos a obtener de esta funcional.
3. Escenario: Alguna situación de negocio específica inicia el script y contiene una descripción.
4. Las siguientes 7 líneas describen los pasos de la prueba, que corresponden a código específico, realizando la acción descrita. Se comparan las líneas que van seguidas de las palabras clave «Dado», «Y», «Entonces», etc.