Historias de Usuario ¿cómo aprovechar sus beneficios de manera eficiente?
Por Vanessa Amaya
En los casi 9 años que llevo dentro del mundo de la agilidad, he visto a muchos usar las Historias de Usuario, pero muchos las ven como “un cambio de formato” y es mucho más que eso, la transición a usar las historias cambia hábitos muy arraigados de las metodologías tradicionales y es importante entender esa transición para poder usar las Historias de manera eficiente y no terminar diciendo “Las historias de usuario no funcionan”.
El poder de una historia
“Contamos historias para aprender, para imaginar, para protegernos, para ser parte de una narrativa más humana” - Regina Freyman
Puse esta frase porque el poder de una historia considero que es muy grande, los relatos nos facilitan la comprensión y con ello se influye en el comportamiento y en como concebimos las soluciones una vez que entendemos el problema u oportunidad y somos capaces de abstraer la información y las lecciones que contienen los datos que recibimos todos los días.
Lo que menciono anteriormente considero que es parte importante del origen de la práctica de Historias de Usuario ya que son un cambio de enfoque, que si bien es fácil de entender, lo difícil es la transición del enfoque al que tenemos años acostumbrados por el uso de metodologías tradicionales.
El hábito clave es que cuando aterrizamos de manera escrita los requisitos para nuestros proyectos, lo hacemos típicamente en un solo bloque que incluye de todo a alto nivel, desde objetivos, alcances, requisitos específicos, listas, consideraciones y tiempos estimados. La cuestión es que cuando hacemos algo realidad a partir de una especificación, no lo hacemos pasando de ese bloque único de información a alto nivel a la realidad, porque la realidad está hecha de detalles y se constituye de partes que hay que entender en su individualidad y es justo por eso, salen tantas sorpresas que se convierten en retrasos en los proyectos, porque avanzamos (con prisa) sobre algo que para empezar no entendemos con claridad.
El marco eXtreme Programming nos trajo las Historias de Usuario, las historias tienen la intención de ser “descripciones breves y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente, un usuario o cliente del sistema”.
Cuando, en general, organizamos la información en una historia, con un protagonista, con razones, con necesidades, nos lleva a comprometer a la acción a quienes conocen esa historia, y con las historias de usuario, la intención es que pase justo eso: recordar que lo que hacemos lo necesita ALGUIEN, que va más allá de quién pidió o quien escribió un requisito, es recordar que vamos a cambiar y mejorar la vida de alguien a través de nuestro caso y si lo que hacemos es software es para tener presente de que el software es de humanos para humanos y con ello orientarnos al cliente, usuario o consumidor final.
Desafíos detrás de la creación de Historias de usuario
Simpleza y complejidad
La estructura de una Historia es simple, de cada característica del producto o cada parte de lo que estamos creando se especifica el QUÉ, el PARA QUIÉN y el PARA QUÉ de la siguiente forma:
Como <tipo de usuario>
Quiero <característica o funcionalidad>
Para <beneficio esperado>
Y le agregamos criterios de aceptación, que son condiciones que nos permiten crear la característica o funcionalidad correcta y validar que así sea. Son las condiciones que nos permiten crear con la calidad esperada.
Lo anterior no es complejo de entender, lo complejo es que es más fácil pensar en bloques grandes y especificar de esa manera pero al momento de entender y crear, será difícil. Las historias de usuario FACILITAN:
El entendimiento de quienes van a hacer realidad el producto o entregable.
Abstraer la información necesaria para construir con la claridad que nos lleva a la calidad.
Entender las partes de la solución.
Pero dificultan la redacción de especificaciones, porque es más fácil pensar a alto nivel que a bajo nivel, sin embargo, quienes crean los productos o entregables para hacerlo necesitan entender las partes a bajo nivel, entender los detalles más importantes y críticos para el éxito del producto. No necesariamente es tener todos los detalles antes de comenzar, esto es muy difícil, el análisis en la agilidad también es iterativo e incremental, pero eso no es pretexto para no analizar lo suficiente al inicio para poder comprender estos detalles críticos.
Pero como quienes crean las especificaciones y quienes crean los productos o entregables son personas distintas con perspectivas diferentes, las especificaciones típicamente son hechas bajo el enfoque de quienes levantan la información y con frecuencia no se piensa en quienes van a hacer realidad los proyectos.
Y te invito a reflexionar ¿de qué sirve que algo sea fácil de especificar si va a ser difícil de entender por las personas que van a hacer realidad los entregables?
Yo considero que dimensionar con Historias de Usuario es más difícil para quien especifica, no es difícil entender cómo hacer las Historias de Usuario, lo difícil es cambiar los hábitos de especificación para lograr hacer especificaciones más claras y mejor dimensionadas. pero este esfuerzo evita o mitiga el mayor problema que hace que nos retrasemos: la falta de claridad y malos entendidos en las especificaciones y solo por ello, vale enormemente la pena el cambio de hábitos y el esfuerzo temporal adicional que implica cambiar la forma de especificar.
Tamaño
Cuando creamos historias de usuario, dependiendo el momento, contexto e información que tengamos en ese momento, se puede crear con distintos niveles de detalle. Podemos respetar la estructura de una historia pero crearla con mezclando funcionalidades y terminan siendo muy grandes.
Creo que es parte del proceso normal de levantar requisitos y aterrizarlos, pero una vez que los aterrizamos es importante buscar la división clara y la individualidad de cada característica.
Por eso, damos por hecho que una Historia puede crearse muy grande y a esta historia se le llama ÉPICA, pero, no porque aceptemos que pueden existir épicas es que podemos trabajar con ellas. La épica es una invitación a dividir la historia para facilitar el entendimiento de los que van a crear los entregables.
Esto del tamaño es un desafío, porque al trabajar con intangibles que no podemos pesar o medir con facilidad, el tamaño es algo que se dimensiona al estimar. Es decir, cuando el equipo que va a crear el entregable estima cuánto se puede tardar, nos damos cuenta de:
Qué tan clara está la especificación, si se les dificulta estimarla o si se les dificulta establecer argumentos sobre el tiempo que están estimando, puede ser por falta de claridad.
Qué tan individualizada está, por que si en una característica estimamos que nos tardamos más de 2 o 3 días puede indicar que no está lo suficientemente independizada.
Integración
No solo de Scrum vive la agilidad y no solo de Historias de usuario viven las especificaciones. Las Historias de usuario son un punto de partida muy importante pero desprenden otro tipo de especificaciones y otros tipos de análisis ¿cuáles? los que se necesiten para entender y dimensionar mejor.
Entonces, las historias de usuario derivan y se integran con otras prácticas de especificación redactada y especificación visual.
También, las historias de usuario se integran en eventos de planificación y revisión.
La integración y desafío más importante que encuentro en el uso de Historias de Usuario es el mover la balanza de la especificación y conversación, es decir, conversar y entendernos más de lo que documentamos, no se trata de dejar de documentar, se trata de documentar lo suficiente para entendernos y conversar más para tener contexto claro y no depender solo de especificaciones escritas o diagramadas.
Mapeando las historias de usuario para lograr planeación colaborativa
Una de las técnicas a las que se integran las Historias de Usuario es la de User Story Mapping, ésta técnica nos ayuda a organizar los elementos de trabajo o requisitos, si usas Scrum, te ayudará a organizar el Product Backlog, si usas Kanban, te ayudará a organizar las tarjetas.
Esta organización se hacen dos dimensiones:
Vertical: Entregas, liberaciones o releases.
Horizontal: Funcionalidades o características.
Visualmente se vería así:
Mapear de esta manera ayuda a grandes grupos a construir un entendimiento compartido sobre:
Orientación al usuario o consumidor final.
La columna vertebral (Backbone) que lleva la narrativa de lo que vamos a crear, las esencias de lo que necesitamos construir.
Objetivos de cada periodo de trabajo (sprint, liberación, entrega o release).
El foco que debemos mantener en usuarios y su experiencia.
“El mapeo de historias nos mantiene enfocados en los usuarios y su experiencia, y el resultado es una mejor conversación y, en última instancia, un mejor producto” - Referencia Libro User Story Mapping de Jeff Patton.
Conclusiones
Las Historias de usuario son más que una práctica de especificación, es un cambio de hábitos y costumbres para señalar las características o funcionalidades de manera clara e independizada.
Toda práctica que hagamos alrededor de las historias de usuario debe de promover la planeación colaborativa y el entendimiento compartido para evitar los retrasos y retrabajos por malos entendidos.
No se trata de especificar distinto, es modificar hábitos de entendimiento orientándonos a quienes van a hacer realidad los productos y entregables que nos traigan mejores resultados.
Por Vanessa Amaya
Vanessa es Ingeniera en Sistemas Computacionales por la UAG. Cuenta con 18 años de experiencia en proyectos de desarrollo de software como consultora para la implementación de prácticas de mejora en equipos, Business Analyst, Instructora, etc. Ha participado en proyectos de implementación y capacitación de marcos ágiles desde el 2012. Es Docente del cuerpo Académico del Diplomado de Ingeniería de Software Ágil en la UNAM. Representante del nodo México de la Comunidad de Agile Women.
