HISTORIAS DE USUARIO

Las Historias de Usuario

Las Historias de Usuario son un enfoque de requerimientos ágil que se focaliza en establecer conversaciones acerca de las necesidades de los clientes. Son descripciones cortas y simples de las funcionalidades del sistema, narradas desde la perspectiva de la persona que desea dicha funcionalidad, usualmente un usuario (Cohn, Mountain Goat Software).

Poseen las siguientes características: una descripción escrita que será utilizada para planificar y posteriormente disgregar los detalles con el dueño del producto, las conversaciones propiamente dichas con el dueño del producto y las pruebas que han de determinar si las historias están finalizadas o no (Cohn, An Overview, 2009). 

Generalmente se las escribe en post-its (notas), y se las dispone en una pared o una mesa para facilitar de este modo la planificación y discusiones que se llevan a cabo durante la misma. La parte más importante de las historias de usuario es la conversación que se genera entorno a las mismas. Estas notas representan los requerimientos del cliente y típicamente se las escribe de la siguiente manera:

La estructura de una historia de usuario está formada por:

Nombre breve y descriptivo.

Descripción de la funcionalidad en forma de diálogo o monólogo del usuario describiendo la funcionalidad que desea realizar.

Criterio de validación y verificación que determinará para considerar terminado y aceptable por el cliente el desarrollo de la funcionalidad descrita.

Y adicionalmente por la información que resulte necesaria por el modelo de implementación: Prioridad, Riesgo, Tamaño, etc.

Atributos de las historias de usuario

Pero hay una serie de atributos mucho más concretos que las Historias de Usuario deberían cumplir.  Bill Wake en su libro Programming Explored and Refactoring las denomina con el acrónimo INVEST que se basa en las iniciales de los seis atributos recomendables para las Historias de Usuario.

Independent : se pueden hacer en cualquier orden (no dependen unas de otras). Facilitan la planificacion, priorizacion y estimacion.

Negotiable : no son contratos, sino promesas de comunicación. Los detalles se añaden mediante la conversacion.

Valuable : siempre debemos dar valor al cliente (no crear historias técnicas)

Estimable : si no podemos estimarlas es porque debemos conversar más

Small : pequeñas (pero no demasiado). Debe ser pequeña en esfuerzo.

Testable : si no puedes probarla, ¿cómo puedes saber que está acabada?

Malas prácticas

Escribir historias que dicen cómo se hará en vez de qué se debe hacer (p.ej. CRUD de Clientes)

Una Historia de usuario no es un Caso de uso porque no se centra en el cómo ni tampoco es una definición exhaustiva de los requisitos.

No escribir el criterio de aceptación o no ser suficientemente explícito.

No estimar una tarjeta puede crear falsas expectativas y dificulta la autodisciplina.

Fiar todo a lo escrito en la tarjeta: a veces es necesaria documentación externa. (Wiki)

Dar una historia por hecha cuando está “prácticamente hecha” en vez de “hecha-hecha”.

Las 3 C’s de la historia de usuario

Los elementos fundamentales de una historia de usuario son la Tarjeta(Card), la Conversación (Conversation) y Confirmación (Confirmation). 

Tarjeta (Card): La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. 

Conversación (Conversation): Después de escribir la historia de usuario en la tarjeta, es necesario tener una conversación al respecto de su contenido. Hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación. 

Confirmación (Confirmation): La confirmación es un acuerdo que refleja que todas las personas implicadas, Product Owner y Development Team, entienden cuales son los elementos, valor y resultado esperado de la historia de usuario. 

Beneficios

• Al ser muy corta, ésta representa requisitos del modelo de negocio que pueden implementarse rápidamente (días o semanas)
• Necesitan poco mantenimiento
• Mantienen una relación cercana con el cliente
• Permite dividir los proyectos en pequeñas entregas
• Permite estimar fácilmente el esfuerzo de desarrollo
• Es ideal para proyectos con requisitos volátiles o no muy claros

Limitaciones

• Sin pruebas de validación pueden quedar abiertas a distintas interpretaciones haciendo difícil utilizarlas como base para un contrato
• Se requiere un contacto permanente con el cliente durante el proyecto lo cual puede ser difícil o costoso
• Pueden resultar difíciles las pruebas de usuario, que sólo se ven en las metodologías SCRUM para escalar a proyectos grandes
• Requiere desarrolladores muy competentes

EJEMPLOS

Autogestión de T.V. por suscripción

Ejemplo 3: Como Cliente, quiero suscribirme a un nuevo plan de T.V. por cable por medio del sitio web.

Ejemplo 4: Como Cliente, quiero pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria o tarjeta de crédito.

Ejemplo 5: Como Cliente, quiero suscribirme a un canal de T.V Premium por períodos flexibles de tiempo por medio del sitio web.

Ejemplo 6: Como Cliente, consultar un listado de las suscripciones de Pay per View que se han realizado en mi cuenta.

Sistema de ventas y distribución

Ejemplo 7: Como Vendedor, quiero registrar los productos y cantidades que me solicita un cliente para crear un pedido de venta.

Ejemplo 8: Como Supervisor de ventas, quiero consultar un listado de los pedidos de venta que han sido registrados y aún no han sido procesados.

Ejemplo 9: Como Gerente de ventas, quiero consultar los pedidos de venta procesados clasificándolos por vendedor, región y líneas de producto.

Ejemplo 10: Como Analista de logística, quiero seleccionar un pedido de venta y enviarlo al almacén para que procedan con su preparación.

Ejemplo 11: Como Analista de almacén, quiero listar todos los pedidos de venta recibidos que debo preparar.

Ejemplo 12: Como Analista de logística, quiero poder consultar todos los pedidos preparados listos para ser despachados.

CONCLUSIONES

Son una manera de hacer que el Usuario y el programador traten de hablar el mismo lenguaje.
Las Historias de Usuarios son una invitacion a una conversacion.
Pueden ser creadas durante las concersaciones con los usuarios interesados, sobre nuevas funcionalidades del proyecto.

BIBLIOGRAFIA

http://www.institucional.frc.utn.edu.ar/sistemas/lidicalso/pub/file/Tesis/Anteproyecto_Requerimientos_en_Metodolog%C3%ADas_Agiles.pdf

http://www.scrummanager.net/bok/index.php/Historia_de_usuario

https://es.slideshare.net/MiquelMora/historias-de-usuario

http://fernandollopis.dlsi.ua.es/?p=39

http://jmbeas.es/guias/historias-de-usuario/

https://jeronimopalacios.com/2016/05/los-elementos-una-buena-historia-de-usuario/

https://es.wikipedia.org/wiki/Historias_de_usuario

http://www.pmoinformatica.com/2015/05/historias-de-usuario-ejemplos.html