Historias de Usuarios

¿Que son las Historias de Usuarios?

Las historias de usuario son utilizadas en los métodos agiles para la especificación de requisitos, son una descripción breve de una funcionalidad software tal y como la percibe el usuario (Mike Cohn, 2004).

Describen funcionalidades que dan solución a necesidades o problemas del cliente o del usuario, representan los “qués” a construir y se escriben en forma de historia con una o dos frases utilizando el lenguaje común del usuario, a mi me gusta usar Gherkin como lenguaje.

Estas son una forma ágil de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales los cuales sabemos que pocas personas lo llegan a leer completos y sin requerir de mucho tiempo para administrarlos debido ya que el mundo cambia muy rápido que por allí escribimos la necesidad y cuando se va a comenzar a desarrollar la misma cambio.

Las historias de usuario forman parte de la formula de captura de funcionalidades definida en 2001 por Ron Jeffries de las tres C’s:

Información en una historia de usuario

Para decidir qué información incluir en una historia de usuario es preferible no adoptar formatos rígidos. Los resultados de scrum y agilidad no dependen de las formas, sino de la institucionalización de sus principios y la implementación adecuada a las características de la empresa y del proyecto.

Los campos que se consideran más necesarios para describir de una manera adecuada las historias de usuario son:

Descripción: descripción sintetizada de la historia de usuario. El estilo puede ser libre, según mejor nos funcione, debe responder a tres preguntas: ¿Quien se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Mike Cohn recomienda seguir el siguiente patrón que garantiza que la funcionalidad está descrita a un alto nivel y de una manera no demasiado extensa:

Como [rol del usuario], quiero [objetivo], para poder [beneficio]

Yo me he acostumbrado a escribirla de la siguiente manera

Para poder [beneficio], como [rol del usuario], quiero [objetivo]

Esto por que un día estaba hablando con Gustavo Verón un compañero de laburo me dijo, “El valor de cada historia esta en el beneficio por lo cual debería ser lo mas importante, por eso lo colocamos al inicio”, desde allí comencé a escribirlas de esta manera, pero cada uno de nosotros las puede escribir como quiera.

Estimación: estimación del esfuerzo necesario en tiempo ideal de implementación de la historia de usuario. Según convenga al equipo también se puede utilizar unidades de desarrollo, conocidas como puntos de historia (estas unidades representan el tiempo teórico de desarrollo/persona que se estipule al comienzo del proyecto).

Este es un punto que se puede profundizar un poco mas, por ahora no vamos a hablar mucho de la estimación.

Prioridad: sistema de priorización que nos permite determinar el orden en el que las historias de usuario deben de ser implementadas.

Esos son los campos mínimos que debe incluir una historia de usuario, también pueden incluir ID, Titulo, Criterios de Aceptación, Valor, Dependencias, Persona Asignada, Sprint, Riesgo, Modulo y observaciones entre otros.

Mike Cohn comenta que, si bien las historias de usuario son lo suficientemente flexibles como para describir la funcionalidad de la mayoría de los sistemas, no son apropiadas para todo. Si por cualquier razón, se necesita expresar alguna necesidad de una manera diferente a una historia de usuario, recomienda que se haga o muchas veces consideramos que por usarlas vamos a trabajar mejor y rendiremos de una manera inimaginable, pero lo cierto es que no siempre es así.

Tuve la oportunidad de entrar en un equipo que las estaba implementando y cometí un error de alentar al equipo a seguirlas usando, mi error fue no ver que el contexto del desarrollo era complicado, pero todos sabían lo que se tenia que hacer con lo cual se escribieron muchas y no daban ningún valor, pero en otro equipo que las implementamos logramos obtener resultados impresionantes debido a que estas potenciaron la creatividad para desarrollar la solución.

Cuando se implementaba la solución procedíamos a realizar una documentación técnica por pedido del cliente, la misma la estructuramos:

Historia de Usuario

Capturas de pantalla

Criterios de Aceptación

Servicios (Aquí se indicaban los servicios que interactúan, los que utiliza e inclusive los que desarrollamos para llevar a cabo la historia).

Ventajas que aportan las historias de usuario:

Al ser muy cortas, estas representan 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.

Permiten dividir los proyectos en pequeñas entregas.

Permiten estimar fácilmente el esfuerzo de desarrollo.

Son ideales para proyectos con requisitos volátiles o no muy claros.

¿Debemos usarlas?

Como todo en la vida se debe evaluar si en verdad es necesario o da valor, usarlas porque es una moda no tiene mucho sentido, ya que puede traer mas problemas que soluciones.

Luego de haber cometido algunos errores usándolas decidí probarlas siempre y evaluar si daban valor o no, para esto inspecciono frecuentemente las siguientes cosas:

Existe una persona dedicada a escribirlas y esta persona se sienta a conversar con el usuario para conseguir mas detalle.

Cumple con el INVEST

Propician la creatividad de los desarrolladores.

Si no se llegan a cumplir las condiciones lo que hacemos es sentarnos todos para evaluar si las seguimos usando por un tiempo determinado o si cambiamos a otra forma de documentar los requerimientos.

Un mismo requerimiento dos formas de escribirlo

Hace un tiempo lei un articulo Mateo Tojeiro titulado las 4 “C” en este dice

“Hay confianza en que ese equipo hará algo superador, tomará las decisiones correctas y se equivocará donde menos nos duela (o no). La creencia de fondo es que un equipo multidisciplinario puede y sabe, tiene la potencia de co-crear una solución más adecuada, más acertada, más creativa, más holística.”

y al terminar de leerlo, recordé un requerimiento escrito de dos maneras completamente diferentes uno como historia de usuario y otro como requerimiento funcional.

Requerimiento Funcional

Dibuja una bonita pradera verde con:

· 10 flores azules de 5 pétalos cada una

· 5 flores azules de 6 pétalos cada una

· 13 flores rojas de 6 pétalos cada una

· 2 vacas con 3 manchas negras

· 1 vaca con 5 manchas negras

· 2 vacas con 4 manchas negras

· 2 pájaros en la esquina superior izquierda

· 3 pájaros en medio de la imagen

· Un sol en la esquina superior derecha con 5 rayos de sol

Historia de Usuario

Dibuja una bonita pradera según la siguiente historia de usuario:

Para poder disfrutar de mi estancia y desconectar me del día a día

Como huésped de un hotel rural

Quiero vistas a una bonita pradera verde salpicada de flores rojas y azules, algunas vacas y pájaros y bajo un sol radiante

Usen el requerimiento en el equipo y algunos que hagan el funcional y otros que hagan el historia de usuarios, luego ven los resultas y luego pregunten ¿cómo se sintieron?, ¿tuvieron la oportunidad de ser creativos?