User stories, en nuestro castellano Historias de Usuario

Una historia de usuario describe brevemente y en lenguaje natural la funcionalidad que será de valor para un cliente o un usuario de un sistema o software. Están compuestas de tres aspectos: una descripción de historia usada en la planificación y como un recordatorio, conversaciones sobre la historia que sirven como instrumento para recolectar detalles, y tests que transmiten y documentan detalles pueden ser usados para determinar cuando una historia esta completa.

Complementando un mejor entendimiento de las historias de usuario, se ve conveniente el reflexionar en “lo que las historias de usuario no son”, de ninguna manera una historia puede ser interpretada como una especificación de un requerimiento que cumpla con la norma de la IEEE 830, un caso de uso o un escenario.

A diferencia de la especificación de requerimientos y casos de uso, las historias de usuario no son un artefacto del análisis. Mejor aun, son una herramienta de soporte para el análisis.

Escenarios de interacción de diseño son mucho más detallados que las historias de usuario. Un escenario típico es mucho más largo que un caso de uso, el que a su vez, puede comprender varias historias de usuario.

Las historias de usuario son redactadas por el cliente, asistidos por los desarrolladores, una o dos oraciones en lenguaje natural para describir lo que el cliente quiere. En nuestro caso, debido a que el cliente es un profesional del área de ciencias de la computación, las palabras empleadas en la redacción de historias tienen sabor a lenguaje técnico. La principal dificultad que se presento en la redacción de historias fue que el cliente describía módulos en vez de pequeñas unidades de valor.

La mejor herramienta para administrar historias de usuario son tarjetas de papel que puedan caber en el bolsillo de la camisa. Útiles en la planificación al ponerse sobre una mesa pueden moverse de atrás hacia delante, de arriba abajo. Adicionalmente a las tarjetas, puede utilizarse herramientas informáticas como el Excel o Xplanner.

En Internet se pueden encontrar una variedad de planillas formato para las tarjetas de usuario, optamos por un formato sencillo que muestre los elementos que según nosotros deben estar presentes en la tarjeta de historia de usuario:
prioridad,
nombre,
descripcion,
complejidad,
usuario,
numero de iteracion,
numero de historia,
tiempo estimado,
tiemopo real.

Para representar la prioridad para el cliente de una historia de usuario se definió una escala numérica del 1 al 5; siendo 1 la prioridad más baja y 5 la más alta.

La complejidad representa el nivel de dificultad estimada que los desarrolladores asignan a la historia de usuario. La escala de complejidad va del dos al seis e inclusive imposible en el caso extremo de que la historia no puede ser desarrollada en todo el tiempo disponible en la iteración.

El reverso de la tarjeta es usado para explotar la historia de usuario en tareas, notas, descripción de los tests de aceptación. El test de aceptación es el proceso de verificación que la historia fue desarrollada tal que esta trabaje de la manera en que el cliente espera que funcione.

Muchos autores y entre ellos Mike Cohn autor de User Stories Applied: For Agile Software Development, recomiendan que las historias cumplan con las características del INVEST, palabra que proviene de:

Independent, evitar la dependencia entre historias.
Negotiable, unidad de negocio entre el cliente y el equipo de desarrollo.
Valuable, aportar valor al usuario o al cliente.
Estimable, calcular el esfuerzo necesario para la implementación de la historia.
Small, tamaño apropiado para desarrollar varias historias en una iteración, definido en función a las capacidades y tecnología en uso del equipo.
Testable, si no puede ser testeada como verificar que la historia esta terminada.

Es difícil cumplir todas las características de INVEST, a veces del dividir resultado de dividir una historia grande en historias más pequeñas, puede acarrear dependencias entre las historias resultado de la división.

Elaborar órdenes de trabajo para la programación de trabajos no contemplados en la programación quincenal, detención de trabajos, reanudación de trabajo detenido y redistribución de volúmenes de obra.

En el párrafo anterior, se observa la descripción de una historia de usuario bastante larga, no solo es una descripción larga, representa una historia de usuario grande y compleja, dadas las condiciones del momento, se decidió dividir la historia en cinco historias más pequeñas, listadas a continuación:

a. Una herramienta que permita elaborar ordenes de trabajo.
b. Programación de trabajos no contemplados en la programación quincenal.
c. Detención de actividades programadas.
d. Reanudación de actividades detenidas.
e. Redistribución de volúmenes de obra.

Las consecuencias de la división de la historia fue la dependencia entre historias de usuario. Donde b, c, d y e son dependientes de la implementación de a, y d es dependiente de c.