¿Qué es una historia de usuario?

¿Qué es una historia de usuario?

Una historia de usuario es una nota que captura lo que un usuariohace o necesita hacer como parte de su trabajo. Cada historia de usuario consta de una breve descripción escrita desde el punto de vista del usuario, con lenguaje natural. A diferencia de la captura tradicional de requisitos, la historia de usuario se centra en lo que el usuario necesita en lugar de lo que el sistema debería entregar. Esto deja espacio para una discusión adicional sobre soluciones y el resultado de un sistema que realmente se adapte al flujo de trabajo del cliente, resolviendo sus problemas operativos y, lo más importante, aportando valor a la organización.

Concepto de las 3C

Las 3C se refieren a los tres aspectos críticos de las buenas historias de usuario. El concepto fue propuesto por Ron Jeffries, co-inventor de la práctica de las historias de usuario. Actualmente, cuando hablamos de historias de usuario, generalmente nos referimos al tipo de historias de usuario que están compuestas por estos tres aspectos.

1. Tarjeta – Las historias de usuario se escriben como tarjetas. Cada tarjeta de historia de usuario tiene una oración breve con solo el texto suficiente para recordar a todos de qué trata la historia.
2. Conversación – Los requisitos se encuentran y refinan a través de conversaciones continuas entre clientes y equipo de desarrollo durante todo el proyecto de software. Ideas e decisiones importantes se descubrirán y registrarán durante las reuniones con los interesados.
   
3. Confirmación – o también conocido como criterios de aceptación de la historia de usuario. Durante la discusión de requisitos, el cliente le dice al analista no solo lo que desea, sino también confirmar bajo qué condiciones y criterios el software funcional sería aceptado o rechazado. Los casos definidos se escriben como confirmación. Tenga en cuenta que la confirmación se centra en verificar la corrección del trabajo de la historia de usuario correspondiente. No es una prueba de integración.
   

¿Cómo identificar una historia de usuario?

Las historias de usuario deben identificarse junto con los interesados, preferiblemente a través de una reunión presencial. La historia de usuario es un proceso de descubrimiento de requisitos en lugar de un proceso de análisis de requisitos previos. En los enfoques tradicionales de captura de requisitos, el analista del sistema trata de comprender las necesidades de los clientes y luego prepara una especificación detallada de requisitos para el sistema. Esto no es cómo funciona el enfoque de la historia de usuario. En lugar de un proceso de documentación, la identificación de la historia de usuario es más parecida a un proceso de toma de notas. A través de las discusiones con los usuarios, escuchamos y comprendemos sus problemas y necesidades, y luego escribimos sus necesidades como historias de usuario al mismo tiempo. Estas historias de usuario se convertirán en la fuente de requisitos. Los detalles se pueden completar posteriormente justo a tiempo, proporcionando al equipo una referencia de requisitos ‘justo lo suficiente’ durante todo el proceso de desarrollo del proyecto.

Mapa del proceso de negocio con historias de usuario

BPMN es una de las herramientas más potentes para el análisis y modelado de negocios. No solo podemos usarlo para realizar mejoras en procesos, sino también para identificar historias de usuario a partir de esos procesos destinados a ser automatizados a través de los siguientes pasos:

1. Simplemente modele el flujo de trabajo del usuario con un diagrama de proceso de negocio BPMN.
2. Recorra el modelo de proceso con los usuarios.
3. Y, analice las actividades del negocio del problema, y luego identifique las historias de usuario relacionadas con el proceso que debe ser automatizado, lo cual también se conoce como mapeo de proceso de negocio a historia de usuario.

¿Cómo escribir una historia de usuario?

Al escribir una historia de usuario, intente escribir en voz del usuario según el formato siguiente (o al menos, asegúrese de que lo que ha escrito cumpla con la siguiente afirmación):

Como un <rol>, quiero <objetivo comercial> para que <valor comercial/razón>.

Por ejemplo, como un cliente, quiero recibir un SMS cuando el artículo llegue para que yo pueda ve a recogerlo.

dónde:

1. <rol> representa a la persona, sistema, subsistema o cualquier otra entidad que interactuará con el sistema a implementar para alcanzar un objetivo. Él o ella obtendrá valores al interactuar con el sistema.
2. <objetivo comercial> representa la expectativa de un usuario que puede lograrse mediante la interacción con el sistema.
3. <valor comercial> representa el valor detrás de la interacción con el sistema.

No es una regla, sino una guía que te ayuda a pensar en una historia de usuario considerando lo siguiente:

1. La historia de usuario aportará valor a alguien o a una parte determinada (por ejemplo, clientes).
2. La historia de usuario satisface una necesidad del usuario (por ejemplo, recibir un SMS cuando el artículo ha llegado)
3. Hay una razón para apoyar la implementación de esta historia de usuario (por ejemplo, el cliente puede ir a recoger el artículo que compró)

Cada historia de usuario debe aportar valor a alguien. Pero a veces, el valor es suficientemente evidente simplemente al leer el objetivo comercial. Es incómodo escribir el valor como parte de la declaración. En tales casos, simplemente lo omitiremos. Aquí tienes algunos ejemplos:

Como cliente, quiero realizar el pago utilizando tarjeta de créditopara que pueda usar mi tarjeta de crédito en compras en línea.

Como usuario, quiero realizar una búsqueda al introducir el nombre de mi amigopara que pueda encontrar a mi amigo con su nombre.

No importa cómo escribas una historia de usuario, hay dos cosas que debes tener en cuenta. Primero, una historia de usuario debe escribirse desde el punto de vista del usuario. Segundo, mantén la descripción ‘justo lo suficiente’. Evita agregar demasiados detalles al principio de un proyecto de software. Más adelante tendrás la oportunidad de refinar y detallar la historia de usuario para que se convierta en algo que los desarrolladores puedan usar en el diseño e implementación.

Ciclo de vida de una historia de usuario

En sentido amplio, existen seis estados principales para cada historia de usuario durante un proyecto de software:

1. Pendiente – A través de la comunicación entre el usuario y el equipo del proyecto, se identifican las historias de usuario. En este estado, las historias de usuario no tienen más que una breve descripción de la necesidad del usuario. Aún no hay discusión detallada sobre los requisitos, ni lógica del sistema ni diseño de pantallas. De hecho, el único propósito de la historia de usuario, por ahora, es recordar a todas las partes sobre una futura discusión sobre la solicitud del usuario escrita en esta historia (tarjeta). Es posible que la historia de usuario se descarte en el futuro.
2. Por hacer – A través de una discusión entre diferentes partes interesadas, se decide cuáles historias de usuario se abordarán en las próximas semanas, y se incluyen en un periodo limitado llamado sprint. Dichas historias de usuario se consideran en estado Por hacer. Aún no se ha llevado a cabo una discusión detallada en este estado.
3. En discusión – Cuando una historia de usuario está en estado de En discusión, el usuario final se comunicará con el equipo de desarrollo para confirmar los requisitos y definir los criterios de aceptación. El equipo de desarrollo anotará los requisitos o cualquier decisión como notas de conversación. El especialista en experiencia de usuario puede crear prototipos o guiones para que el usuario pueda previsualizar las características propuestas en prototipos visuales y experimentarlas. Este proceso se conoce como diseño de experiencia de usuario (UX design).
   
4. En desarrollo – Una vez que se aclaran los requisitos, el equipo de desarrollo diseñará e implementará las características para cumplir con las solicitudes del usuario.
5. Confirmación – Una vez que el equipo de desarrollo haya implementado una historia de usuario, esta será confirmada por el usuario final. Se le proporcionará acceso al entorno de pruebas o a un producto de software semi-completo (a veces conocido como versión alfa) para confirmar la característica. La confirmación se realizará basándose en los elementos de confirmación escritos al detallar la historia de usuario. Hasta que se complete la confirmación, se considera que la historia de usuario está en estado de Confirmación.
6. Finalizado – Finalmente, cuando se confirma que la característica está completa, la historia de usuario se considera en estado Finalizado. Normalmente, esto es el final de la historia de usuario. Si el usuario tiene una nueva solicitud, ya sea sobre una nueva característica o una mejora de la historia de usuario finalizada, el equipo crearía una nueva historia de usuario para la siguiente iteración.

Detallar la historia de usuario – ¿Cuándo y por qué?

Una característica clave que diferencia la historia de usuario de los enfoques tradicionales de captura de requisitos es que el enfoque de la historia de usuario divide la identificación del problema y la solución en dos pasos, realizados en etapas diferentes de un proyecto de software. Mientras que los problemas y una comprensión breve de las solicitudes del usuario se identifican al inicio del proyecto de software, los detalles de los requisitos del sistema solo se determinan antes del inicio del diseño y la implementación. A continuación se presentan algunas ventajas de este enfoque:

1. Capaz de responder a las necesidades más recientes del usuario porque los requisitos se detallan justo antes de la implementación, en lugar de tener todo concluido desde el principio.
2. Capaz de identificar los requisitos adecuados más fácilmente porque tanto los problemas como las soluciones serán objeto de discusiones detalladas. En los enfoques tradicionales, dado que se requiere encontrar los detalles de todos los requisitos desde el inicio del proyecto, los requisitos “iniciales” podrían haber cambiado con el tiempo, lo que genera una gran pérdida de esfuerzos de análisis.
3. – Por otro lado, las historias de usuario que resultan inválidas pueden descartarse fácilmente. No pierdes mucho tiempo en estudios y documentación previos

¿Cómo utilizar eficazmente la historia de usuario?

Al igual que muchas otras metodologías de desarrollo de software, si aplicas correctamente la historia de usuario en tu proyecto de software podrás producir un sistema de software de calidad y ganarte la confianza y satisfacción de los clientes. A continuación se presentan algunos puntos que debes tener en cuenta al utilizar la historia de usuario:

1. Mantén la descripción de la historia de usuario breve.
2. Piensa desde la perspectiva del usuario final al escribir una historia de usuario.
3. Un caso de uso (UML) representa un objetivo empresarial. La capacidad de agrupar historias de usuario bajo casos de uso te permite asegurarte de que una historia de usuario cumple con un objetivo empresarial, es decir, que comparten el mismo objetivo del sistema. Sirve como un marcador de posición para que puedas gestionar, programar y priorizar las historias de usuario de una manera más manejable.
4. Los elementos de confirmación deben definirse antes de comenzar el desarrollo
5. Estima la historia de usuario antes de la implementación para asegurarte de que la carga de trabajo de tu equipo esté bajo control.
6. Los requisitos se encuentran con los usuarios finales, no por el usuario final ni únicamente por el equipo de desarrollo. Mantener una buena relación con los usuarios finales será una situación de ganar-ganar para ambas partes.
7. La comunicación siempre es importante para comprender lo que el usuario final quiere.

Visual Paradigm proporciona todas las herramientas que necesitas en desarrollo ágil de software, que incluye herramienta de diagrama de casos de uso UML, (ágil) historia de usuario, sprint, guion gráfico y maquetas para el diseño de experiencia de usuario, herramienta de gestión de tareas, etc.