Una historia dice más que mil palabras

Potenciando el desarrollo de software mediante el uso de historias de usuario.

Las historias de usuario son una técnica para representar una necesidad o requisito por parte de un usuario, y si es utilizado de manera ingeniosa puede servir también, para que el levantamiento de requerimientos sea de mayor provecho al arrojar detalles que durante una entrevista no tan fácil lograría satisfacer.

Antes de entrar en materia sobre sus posibles usos es conveniente conocer un poco más sobre las historias de usuario. Las historias de usuario como tal deben ser pequeñas y prácticas de tal manera que cuentan, de manera muy corta, una necesidad y su valor que aportan al negocio. Una historia de usuario debe permitirnos ser escrita en una pequeña tarjeta, nota o post-it de tal forma que evita la tediosa actividad de escribir una gran especificación de requisitos.

La sintaxis para escribir una historia de usuario puede ser la siguiente:

As a (User Role) Iwant to (Do this) so that (Achive that), que en español sería: Como (Rol de Usuario) Quiero (Hacer esto) Para (Alcanzar o lograr esto).

En términos más prácticos si nuestro proyecto estuviera orientado en el desarrollo de un sitio web para la venta de productos electrónicos, en lugar de hacer especificaciones completas como casos de uso tendríamos los siguientes ejemplos de historias de usuario.

1.-Busqueda por Nombre

Como Cliente quiero poder hacer una búsqueda de artículos por nombre para encontrar más rápidamente el producto que deseo comprar.

2.-Selección de varios artículos para agregarlos  al carrito de compra

Como Cliente quiero realizar una selección de diferentes artículos para agregarlos a mi carrito de compra.

3.-Realizar pago en línea de la compra

Como Cliente quiero realizar el pago en línea de mis artículos para concluir con mi compra.

Como nos damos cuenta, la forma de redactar una historia de usuario es completamente sencilla y especifica una necesidad usando el lenguaje de los usuarios, evitando la necesidad de especificar a gran detalle elementos de software.

Ahora para aquellos quienes tienen experiencia realizando análisis de sistemas mediante Casos de Uso o especificaciones de requerimientos, se preguntaran —¿Bueno y con esto puedo empezar a construir algo? —, la respuesta es que no del todo, con la especificación de la historia de usuario acotamos el alcance de una necesidad. El detalle lo especificamos con los llamados “Criterios de Aceptación”.

Los Criterios de Aceptación no son otra cosa que aquellas especificaciones mediante las cuales podemos determinar que un requerimiento está completamente terminado, aporta detalles para la programación del mismo, define las fronteras de lo que se va a construir y también ayuda a los testers a verificar que puntos de la implementación tiene que probar.

Tomemos uno de los ejemplos anteriores:

1.-Busqueda por Nombre

Como Cliente quiero poder hacer una búsqueda de artículos por nombre para encontrar más rápidamente el producto que deseo comprar.

Y sus criterios de aceptación podrían quedar de la siguiente manera:

•     Verificar que el texto introducido se pueda encontrar en cualquier parte del nombre del producto a buscar.
•       Verificar que la lista de artículos encontrados los ordene de menor al de mayor precio.
•          Verificar que los artículos presentados, por artículo, tengan los siguientes datos:

o   Imagen del artículo

o   Nombre Completo

o   Descripción

o   Precio

Como podemos observar los criterios de aceptación dan un poco más de luz al programador para que conozca exactamente que tiene que construir y también ayudan tanto a los usuarios, como al equipo de trabajo a delimitar el esfuerzo y complejidad del requerimiento.

Como se mencionó anteriormente la historia de usuario puede ser escrita en una pequeña tarjeta, nota o post-it, de acuerdo al tamaño de nuestra historia y sus criterios de aceptación, decidiremos el material que usaremos:

1.-Uso de post-it

2.-Uso de tarjetas

También para dar mayor soporte a las historias de usuario se puede reforzar con información adicional que los usuarios nos proporcionen para darle solides al requerimiento, como se muestra en el siguiente ejemplo:

Todo aquello de vaya relacionado con el requerimiento como prototipos en papel, información en archivos de Excel, reglas, cálculos, etc. puede ser entregado al programador como un paquete del requerimiento para su construcción.

Es conveniente que las historias de usuario sean escritas durante las entrevistas con los usuarios o durante un taller para la obtención de requerimientos e involucrar a los mismos sobre la importancia y el porqué de esta técnica, para apoyar en la mejor comprensión de la problemática ya que nos enfoca en conocer que parte del sistema aporta el mayor valor al negocio.