¿Cuál es la diferencia entre las historias de usuario y los requisitos?

Aunque la mayoría de las nuevas funciones deberían definirse desde la perspectiva del usuario, en la práctica, al definir los requisitos que los equipos de desarrollo necesitan construir, a menudo pasamos por alto el «por qué» desde el punto de vista del usuario. El enfoque de una historia de usuario está en la experiencia: lo que la persona que utiliza el producto desea lograr. Los requisitos tradicionales se centran en la funcionalidad: lo que el producto debería hacer. Las diferencias restantes radican en las listas sutiles pero cruciales de «quién», «cómo» y «cuándo».

How to write good User Stories in software development | TSH.io

Las historias de usuario deben escribirse en una o dos oraciones, capturando quién es el usuario, qué quiere y por qué. Una estructura sencilla para definir funciones o historias de usuario es la siguiente:

Como ______, quiero ______, para que pueda ______.

Ejemplo:

Como usuario, quiero restablecer mi contraseña para poder recuperar el acceso al sistema si la olvido.

A pesar de tener objetivos diferentes, tanto las historias de usuario como los requisitos tienen como objetivo final crear un producto que los clientes amen.

¿Qué es una historia de usuario?

Historias de usuarioson requisitos expresados desde la perspectiva del usuario final. Las historias de usuario también pueden denominarse épicas, temas o características, pero todas siguen el mismo formato.

Esencialmente, una historia de usuario es un requisito claramente expresado. Por múltiples razones, el formato de historia de usuario se ha convertido en la forma más popular de expresar requisitos en Agile:

  • Se centra en la perspectiva de la persona que utiliza o se ve afectada por la solución.
  • Define los requisitos en un lenguaje significativo para ese rol.
  • Ayuda a aclarar el propósito real detrás del requisito.
  • Ayuda a definir requisitos de alto nivel sin profundizar demasiado pronto en detalles de bajo nivel.

Identifique los objetivos del usuario y considere de inmediato el valor empresarial de cada requisito dentro de la historia de usuario.

Las historias de usuario suelen considerarse que contienen tres elementos — el3C:

User Stories | Scrum Talks

  • CARD – Debe escribirse en una tarjeta de índice o una nota adhesiva.
  • CConversación – Obtenga información detallada del propietario del producto (Propietario del producto).
  • CConfirmación – Asegúrese de que se implemente correctamente. Debe cumplir con los criterios de aceptación del usuario.

Formato de historia de usuario

El formato para una historia de usuario es el siguiente:

Como <rol>, Quiero <objetivo>, para que <beneficio>

Estos dos ejemplos demuestran historias de usuario a diferentes niveles, pero utilizando el mismo formato:

A nivel de proyecto:

Como <Director de Marketing>, Quiero <mejorar el servicio al cliente>, para que <retengamos a nuestros clientes>.

Dejar una contestacion