En este artículo pretendemos responder a 5 preguntas sobre los US.
- ¿QUÉ es una HISTORIA DE USUARIO?
- ¿POR QUÉ necesitamos una HISTORIA DE USUARIO?
- ¿CÓMO se escribe una HISTORIA DE USUARIO?
- ¿QUIÉN escribiría una HISTORIA DE USUARIO?
- ¿CUÁNDO necesitamos una HISTORIA DE USUARIO?
¿QUÉ ES UNA HISTORIA DE USUARIO?
La Historia de Usuario es una descripción, en un lenguaje común, de comportamientos específicos en un sistema de software que pone al usuario final en el centro de la conversación. Representa la pieza más pequeña de un valor real para el cliente que debe entregarse.
El objetivo de la Historia de Usuario, que es articular cómo una pieza de trabajo entregará un valor particular al usuario final, también representa el anillo de conjunción entre los beneficios del usuario, la gente técnica y el negocio en términos de resultados esperados en el mercado. Por lo tanto, es crucial para entender cómo una historia de usuario puede ser escrito para ser claro para todas las personas involucradas.
Una buena Historia de Usuario está escrita en un lenguaje no técnico y proporciona:
- contexto para los equipos
- permite al equipo definir los beneficios que el producto aportará al objetivo
- impulsa la colaboración y la creatividad
| Cómo proporcionarla | |
|---|---|
|
POR QUÉ se pide construir una funcionalidad (cuál es el valor que aportan al usuario final) |
Hoy en día la Historia de Usuario es una forma realmente estándar de representar las oportunidades de negocio, traducidas luego en solución técnica construyendo un producto válido y sólido.
La razón por la que es una forma tan común en el entorno de desarrollo de software se explica por sus propios beneficios.
Le ayuda a planificar, seguir y entregar el valor del negocio constantemente sin perder el foco en el usuario final; ya que la mayoría de las veces la identificación de los usuarios junto con sus problemas le llevan a un desarrollo de Producto tangible.
Además, trabajar en elementos pequeños y entregables es la única manera de mantenerse flexible y adaptarse a los cambios de negocio y de prioridades. |
|
Cuál es el resultado exacto que se espera. |
El entregable más pequeño de valor para el usuario real [Normalmente una Historia de Usuario contiene Título, Descripción, Criterios de Aceptación y enlaces útiles].
Una plantilla común es:
TÍTULO
Como <ROLE>
Quiero <Objetivo>
Para que <MOTIVACIÓN>
Básicamente esta plantilla define a un Persona que realiza una acción para conseguir una necesidad concreta
Ej: COMO PERSONA DE COMIDA QUIERO VER TODOS LOS RESTAURANTES DISPONIBLES EN MI ZONA PARA PODER PEDIR LA COMIDA QUE MÁS ME GUSTA
DESCRIPCIÓN
Esta sección es crucial porque tenemos que dar el contexto de una manera clara. Explicar cómo se va a impactar en el Customer Journey, describir algunos casos de uso para perfilar el comportamiento y el contexto del usuario.
Teniendo un cliente foody que introduce su propia dirección, entonces la aplicación debe ser capaz de listar todos los restaurantes disponibles en su área para el servicio de entrega. Las opciones para filtrar los restaurantes por puntuación y tipo de cocina ayudarán a nuestros usuarios a encontrar la combinación perfecta para sus propios deseos de comida :shallow_pan_of_food: :pizza::hamburguesa: :spaghetti: :sushi: :burrito: .
Las fuentes externas, como el diseño, los archivos adjuntos o las métricas que deben seguirse, forman parte de los requisitos para lograr el objetivo de esta sección.
CRITERIOS DE ACEPTACIÓN
Los criterios de aceptación representan las condiciones que hay que pasar antes de llegar a la validación completa del desarrollo.
Refiérase a: «COMO COMEDOR QUIERO VER TODOS LOS RESTAURANTES DISPONIBLES EN MI ZONA PARA PEDIR LA COMIDA QUE MÁS ME GUSTA».
Aquí un ejemplo:
Comprobar la calidad de los restaurantes por puntuación
Puede filtrar por zona (km)
Escoger el restaurante por la cocina
Cuando se escriben los criterios de aceptación junto con el equipo, es el momento perfecto para entender la funcionalidad completa de la característica facilitando la fase de desarrollo. |
¿POR QUÉ necesitamos una historia de usuario?
Hoy en día la Historia de Usuario es una forma realmente estándar de representar las oportunidades de negocio, traducidas luego en solución técnica construyendo un producto válido y sólido.
La razón por la que es una forma tan común en el entorno del software se explica por sus propios beneficios.
Le ayuda a planificar, seguir y entregar el valor del negocio constantemente sin perder el foco en el usuario final; ya que la mayoría de las veces la identificación de los usuarios junto con sus problemas le llevan a un desarrollo tangible del producto.
Además, trabajar en elementos pequeños y entregables es la única manera de mantenerse flexible y adaptarse a los cambios de negocio y de prioridades.
¿CÓMO se escriben las historias de usuario?
La historia de usuario representa una cuestión de usuario y un problema a resolver. Una vez identificado el tipo de usuario, hay que explicar qué problema va a resolver nuestro desarrollo para ellos. Es importante que cada historia de usuario describa una única acción (más detalles sobre cómo dividir una historia de usuario aquí) para garantizar el motivo y el valor a conseguir.
Si quieres saber más sobre las mejores prácticas y el patrón a utilizar cuando estás escribiendo una determinada historia, por favor remite aquí.
¿QUIÉN la escribe?
El Product Owner es el que lo escribe, pero no es raro que haya un grupo de personas que contribuyan a la misma Historia de Usuario.
¿CUÁNDO la necesitamos?
Dado que la historia de usuario es un fragmento del plan de producto, puede escribirla en cada momento del desarrollo del ciclo de vida del producto.
Conclusiones
Cuando todo está dicho y hecho, si quieres que tu historia de usuario sea entendida por cualquier persona involucrada, asegúrate de que te estás centrando en un problema real y valioso del usuario final y en la forma de solucionarlo. Presta atención al lenguaje utilizado para asegurarte de que el mensaje se transmite de forma adecuada.
