freeCodeCamp/guide/spanish/agile/user-stories/index.md

2.7 KiB

title localeTitle
User Stories Historias de usuarios

Las historias de usuarios son parte de un enfoque ágil que ayuda a cambiar el enfoque de escribir sobre requisitos a hablar sobre ellos. Todas las historias de usuarios ágiles incluyen una o dos oraciones escritas y, lo que es más importante, una serie de conversaciones sobre la funcionalidad deseada.

Las historias de usuario se escriben normalmente utilizando el siguiente patrón:

Como [tipo de usuario], quiero [algún objetivo] para que [alguna razón o necesidad]

Las historias de usuario deben escribirse en términos no técnicos desde la perspectiva del usuario. La historia debe enfatizar la necesidad del usuario, y no el cómo. No debe haber solución proporcionada en la historia del usuario.

Un error común que se comete al escribir historias de usuarios es escribir desde la perspectiva del desarrollador o la solución. Asegúrese de indicar el objetivo y la necesidad, y los requisitos funcionales vienen más adelante.

Tamaño de una historia de usuario: epopeyas y historias más pequeñas

Una epopeya es una gran historia de grano grueso. Por lo general, se divide en varias historias de usuarios a lo largo del tiempo, aprovechando los comentarios de los usuarios sobre los primeros prototipos e incrementos de productos. Puedes considerarlo como un titular y un marcador de posición para historias más detalladas.

Comenzar con épicas le permite esbozar la funcionalidad del producto sin comprometerse con los detalles. Esto es particularmente útil para describir nuevos productos y características: le permite capturar el alcance aproximado y le da tiempo para aprender más sobre cómo atender mejor las necesidades de los usuarios.

También reduce el tiempo y el esfuerzo necesarios para integrar nuevas perspectivas. Si tiene muchas historias detalladas en la cartera de pedidos del producto, a menudo es complicado y lleva mucho tiempo relacionar los comentarios con los elementos apropiados y conlleva el riesgo de introducir inconsistencias.

Al pensar en posibles historias, también es importante tener en cuenta los casos de "usuarios incorrectos" e "infelices". ¿Cómo serán manejadas las excepciones por el sistema? ¿Qué tipo de mensajería le devolverás al usuario? ¿Cómo podría un usuario malintencionado abusar de esta aplicación? Estas historias malintencionadas pueden ahorrar reprocesos y convertirse en casos de prueba útiles en control de calidad.

Más información: