Historias de Usuario (User Stories) ​

El concepto de las Historias de Usuario tiene algo que ver con los famosos Casos de Uso. Pero este parecido se basa en que su cometido es el mismo, sirven para hacer las mismas cosas, pero no son lo mismo. Nos permiten sustituir unos largos requerimientos por una serie de Historias de Usuario y además nos permiten hacernos una estimación del tiempo para la reunión de lanzamientos de las futuras versiones de nuestro sistema.

Además de esto, las Historias de Usuario nos ayudan a crear pruebas de aceptación. Estos son pruebas que se aplicarán al sistema para ver si cumplen una determinada “Historia de Usuario” , lo cuál viene a ser lo mismo que cumplir un determinado requisito en otros modelos de desarrollo.

Las Historias de Usuario son la forma en la cuál el Dueño del Producto entrega los requerimientos del sistema al equipo de trabajo. Las historias las realiza el propio usuario en forma de 3 sentencias de texto, en las que describe necesidades del sistema con la propia terminología del negocio, sin hacer uso de vocabulario técnico.

A la hora de crearlas todo el equipo escribirá mientras dialogan acerca de las necesidades del sistema. Así, el proceso consiste en que el usuario enuncia una necesidad y se habla sobre ella, intentando que no quede ningún punto pendiente. Para ello, se irá anotando lo que cada uno cree que puede ser una buena definición informal del requerimiento. Una vez escritas, se evaluarán y refinarán entre todos. El objetivo es conseguir una lista de Historia de Usuario detallada, en 4 o 5 líneas, de forma que la carga de trabajo para desarrollarla sea de más o menos una semana.

Una Historia de Usuario es aquella que puede escribirse con la siguiente frase:

Como [un usuario], puedo [acción/funcionalidad] para [beneficio]

Muchas veces, puede resultar redundante o hasta incluso carecer de sentido, indicar el beneficio. Por ello, es frecuente describir las Historias de Usuario, sin incorporar este tercer elemento: Como administrador del sistema, puedo agregar productos al catálogo.

Vale aclarar, que es frecuente encontrar términos como “quiero” o “necesito” en reemplazo de “puedo” cuando se describen las Historias de Usuario.

Si se presenta una tarea complicada, que requiera un tiempo mayor, se procederá a dividir la tarea inicial en tareas más pequeñas. Para realizar esta división o partición en nuevas tareas, se contará con la ayuda del usuario, ya que todo este proceso se realiza conversando cara a cara (diálogo), en un periodo de análisis informal.

Las Historias de Usuario contendrán 3, 4 o 5 líneas, no más, pero durante las conversaciones con el usuario, se elaborarán una serie de documentos incluyendo toda la información acerca de la tarea en cuestión, que será anexada para ser utilizada en el diseño, creación de las pruebas, implementación, etc.

Las Historias de Usuario servirán como unidades básicas de planificación de nuestros proyectos. Para poder realizar una escala de tiempo para el proyecto en global, se debe tener la información del coste en tiempo para cada tarea, información que será ofrecida por los programadores, que son los que tienen el conocimiento técnico y la experiencia en este sentido. Evidentemente, el tamaño variará según el proyecto, por lo que la mejor técnica para conocer el tamaño adecuado para las Historias de Usuario, es el diseñar un par de ellas al principio del proyecto y analizar su tamaño con los programadores para que estimen el tiempo necesario para desarrollar la tarea.

El número de historias que tendremos en nuestro proyecto será de unas 60-120 para un periodo de 6 meses. Si tenemos menos de este número, convendrá particionar las existentes. Si tenemos más, tampoco hay problemas, lo único que tenemos que hacer es conseguir implementar el mayor número de tareas en el menor tiempo posible.

También hay que tener en cuenta que las cosas no son estáticas, todo varía. La solución para esto es muy fácil, simplemente se debe cambiar las Historias de Usuario al principio de una iteración y pasar a desarrollarla.