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.

Planning de iteración en XP

XP se caracteriza por ser un proceso iterativo con ciclos o iteraciones que varían desde una a tres semanas, los ciclos cortos proveen una mejor adaptación al cambio y retroalimentación frecuente. La planificación es una tarea donde participan el/los clientes y desarrolladores, inicia con la redacción de historias de usuario por parte del cliente en colaboración con los desarrolladores, se necesita de la colaboración de los mismos para evitar la dependencia entre historias y asegurarse un tamaño correcto de la historia de usuario. Las historias son redactadas en lenguaje natural de forma breve sobre una tarjeta de papel que pueda caber en el bolisllo de la camisa.

El cliente asigna una prioridad a cada historia de usuario, para esto se pueden utilizar diferentes escalas de prioridad, se empleo una escala basada en los números del uno al cinco, donde uno representaba el valor más bajo de prioridad y cinco el valor más alto.

Los desarrolladores ordenan las historias de usuario en función a la complejidad de desarrollo, el orden va de la menos compleja a la más compleja. Seguido a esto los desarrolladores definen los puntos de complejidad a cada historia de usuario, a la menos compleja se le asignan dos puntos de complejidad. A las siguientes se les asigna el punto de complejidad en función a cuantas veces más compleja es la historia de usuario en relación con la historia de usuario menos compleja de la lista.

El siguiente paso, es calcular el numero de puntos de complejidad, que representa la máxima cantidad de trabajo que puede realizarse durante la iteración, para calcular los puntos de complejidad, es necesario estimar el tiempo necesario para implementar la historia de usuario más sencilla en unidades de días de trabajo por par de programación.

Pc= (2 * Dt * Np) / Te
Donde
Pc: Puntos de complejidad,
Dt: total de dias habiles de trabajo durante la iteración,
Np: numero de pares de programadores que trabajan en la iteración,
Te: Tiempo estimado de la h.u. menos compleja. (en días - par de programación)

El siguiente paso es negociar con el cliente el plan de iteración, de tal manera que el cliente pueda obtener el mayor valor posible sin sobrepasar el número de puntos de complejidad posibles durante la iteración. Aquí se ve la utilidad de tener las historias en tarjetas, son manipulables por varias personas del equipo, pueden ser movidas de atrás adelante para la asignación de prioridades o complejidades.

El resultado de la planificación es el plan de iteración que consiste en una lista ordenada de historias de usuario a implementar durante la iteración. Al cumplir el orden, se asegura que el cliente recibirá aproximadamente el valor prometido en el plan de iteración.

La iteración finaliza con una reunión entre el cliente y el equipo de desarrollo, la misma, se lleva a cabo el último día de la iteración. En la reunión se informan los avances de la iteración y se corren los tests de aceptación de las historias de usuario, en el caso nuestro los test fueron automatizados empleando como herramienta base el JUnit, las historias de usuario que satisfacen sus tests de aceptación cambian de estado a “aceptada”. El futuro de las historias que no satisfacen los tests es definido en la planificación de la siguiente iteración.

A veces el tiempo entre iteraciones, tiempo entre la reunión de finalización de una iteración y la reunión de planificación de la próxima iteración, es largo, generalmente por indisponibilidad de tiempo por parte del cliente, como equipo de desarrollo nos preguntamos ¿Qué hacer durante este tiempo? Se trato de utilizar el tiempo disponible para alguna de las siguientes tareas:

• Codificar la implementación de una historia de usuario que se considere importante para el cliente,


• Hacer cambios necesarios para pasar los tests de aceptación que fallaron,


• Investigar el uso de algún API, framework o herramienta,


• Hacer pequeñas mejoras en el proyecto.