Historias de usuario ( eng. User Story ): una forma de describir los requisitos para el sistema desarrollado, formulada como una o más oraciones en el lenguaje cotidiano o comercial del usuario. Las historias de usuarios son utilizadas por metodologías ágiles de desarrollo de software para especificar requisitos (junto con pruebas de aceptación ). Cada historia de usuario está limitada en tamaño y complejidad. A menudo, la historia se escribe en una pequeña tarjeta de papel. Esto asegura que no crezca demasiado. En Extreme Programming , las historias de usuario son escritas por usuarios (clientes) del sistema. En la metodología SCRUM , el usuario los verifica en el rol de "Propietario del producto" ( ing. Product Owner ). Para los clientes (usuarios), las historias de usuario son la herramienta principal para influir en el desarrollo de software.
Las historias de usuario son una forma rápida de documentar los requisitos de los clientes sin tener que desarrollar extensos documentos formalizados y, posteriormente, gastar recursos en mantenerlos. El objetivo de User Stories es poder responder de manera rápida y rentable a los requisitos del mundo real que cambian rápidamente.
La historia de usuario sigue siendo una definición informal de los requisitos hasta que haya un procedimiento de prueba de aceptación. Antes de implementar una historia de usuario, el cliente debe definir un procedimiento de aceptación adecuado para garantizar que se han alcanzado los objetivos de la historia de usuario.
En Extreme Programming (XP), los desarrolladores y un representante del cliente crean conjuntamente las historias de usuario. El cliente es responsable de la formulación de la historia. El desarrollador puede usar una serie de preguntas para empujar al cliente y averiguar si se necesita alguna funcionalidad específica. Pero al mismo tiempo, el desarrollador debe tener cuidado de no dominar el proceso de creación de una idea.
Una vez que el cliente crea una historia, se escribe en una pequeña tarjeta (por ejemplo, 8x13 cm) con el título y la descripción que proporcionó el cliente. Si el desarrollador y el cliente ven que la historia no les conviene (demasiado grande, compleja, inexacta), se reescribe hasta satisfacer a ambas partes. Sin embargo, Extreme Programming enfatiza que las historias de usuario no deben finalizarse en el momento de la redacción, ya que los requisitos tienden a cambiar con el tiempo durante el desarrollo.
En la metodología XP, las historias de usuario son el resultado de la planificación y definen lo que se debe implementar en un proyecto de software. Las historias de usuario son priorizadas por el cliente según su importancia para el sistema, divididas en una serie de tareas y evaluadas por los desarrolladores.
Inmediatamente antes de la implementación, los desarrolladores pueden discutir la historia con el cliente. Las historias pueden ser difíciles de entender, pueden requerir conocimientos específicos o los requisitos pueden haber cambiado desde que se escribieron.
Cada historia de usuario debe tener una o más pruebas de aceptación adjuntas en algún momento. Esto le permite al desarrollador saber cuándo está lista la historia de usuario y cómo el cliente puede verificarla. Sin una redacción precisa de los requisitos en el momento de la entrega del producto, pueden surgir desacuerdos no constructivos a largo plazo.
XP y otras metodologías ágiles favorecen la comunicación cara a cara sobre la documentación completa; rápida adaptación a los cambios en lugar de fijación en el problema. Esto se logra mediante:
Si bien las historias de usuario y los casos de uso tienen el mismo propósito de documentar los requisitos del usuario en términos de interacción entre el usuario y el sistema, existen diferencias entre los dos.
Las historias de usuario son una representación de información pequeña y fácil de usar. Están formulados en el lenguaje cotidiano del usuario y contienen pequeños detalles, por lo que quedan abiertos a la interpretación. Ayudan al lector a comprender lo que se supone que debe hacer el sistema.
Los casos de uso, a diferencia de las historias de usuarios, describen un proceso y sus pasos en detalle, y pueden formularse en términos de un modelo formal. El guión es autosuficiente. Proporciona toda la información y los detalles necesarios para comprender. Un escenario se describe como "una descripción generalizada de un conjunto de interacciones entre un sistema y uno o más agentes, donde el agente es un usuario u otro sistema".