Ya conocemos el backlog de historias de las metodologías ágiles. Pero este backlog "plano" no siempre es el mejor enfoque; podemos construir backlogs más ricos que nos ayuden a explicar el sistema, priorizar y planificar entregas de manera más efectiva,
Les presento el mapa de historias de usuario: una versión mejorada del backlog del producto. Los mapas de historias de usuario nos permiten visualizar todo el sistema: representan el producto como un "todo", en vez de quedar miopes observando historias individuales.
Así, cuando se tiene que priorizar historias, se hace teniendo en vista el contexto entero del sistema.
Los backlogs planos no siempre funcionan
Una de las cosas más molestas de las prácticas de desarrollo ágil es la idea del backlog plano de historias de usuario. Realmente suena como una idea que puede mejorarse. Por un lado, el backlog plano nos ayuda a construir un sistema de manera incremental, de a pequeñas partes, y nos indica con qué parte seguir. El backlog ubica todas estas partes en el orden de construcción (de mayor valor a menor valor), lo cual sirve mucho si sos un Gerente de Proyectos. Pero nosotros no lo somos.
El concepto de mapas de historia apareció en el artículo How You Slice it, en enero de 2005. Años después, este enfoque se sigue aplicando con distintas variantes.
Veamos cuales son los problemas del backlog tradicional, y luego el concepto general del mapa de historias (y porqué ayudan a resolver estos desafios).
El backlog plano brinda una pobre explicación de qué hace el sistema
Ubicar las historias de usuario en el orden en el que serán construidas no ayuda a explicarle a otros qué hace el sistema. Imaginen entregarle las historias del backlog a los usuarios y preguntarles: "¿qué hace el sistema que están construyendo?".
La parte más dificil de desarrollar software es comprender al sistema, de manera completa y total. Uno de los principales problemas que tienen la mayoría de los equipos ágiles es que pierden de vista el cuadro general (si es que alguna vez lo tuvieron).
Una forma visual de entender el problema del backlog plano es con la siguiente serie de imágenes:
 |
 |
 |
Pasamos mucho tiempo trabajando junto a nuestros clientes. Trabajamos duro para comprender sus metas, a sus clientes, y a las partes más importantes del sistema a construir. Luego llegamos a los detalles: las partes de funcionalidad que se necesitarían construir. Podemos visualizarlo como un árbol donde el tronco está compuesto de metas y los beneficios que se quieren del sistema; las ramas grandes son los usuarios; las ramas más pequeñas son las funcionalidades que necesitan; y por último las hojas son las historias de usuario lo suficientemente pequeñas para desarrollarlas en una iteración.
Después de todo este trabajo, luego de establecer todo este conocimiento compartido, es como si recogieramos todas las hojas y las amontonáramos en una bolsa. Y después, cortamos el árbol.
Esto es un backlog plano. Una bolsa de historias sin contexto.
El contexto es importante para poder ubicar a la historia en el total del sistema.
Para los sistemas nuevos, el backlog plano no ayuda a determinar si se identificaron todas las historias
Podemos discutir por horas en un grupo de historias de usuario, las podemos mirar y analizar, pero es común irnos con la sensación de que se nos olvida algo. Por supuesto que no se puede conocer todo, pero hay formas de poder salir más cómodos de estas situaciones. ¿Cuántas veces nos encasillamos en una historia y, de pronto, perdemos de vista el contexto, y nos olvidamos quizás de otras partes más importantes del sistema?
Es dificil planificar las entregas con un backlog plano
En general, el número de historias en el backlog del producto es de una docena mínimo, y muchas veces llegan a ser cientos. Por más que se intente mantener historias de alto nivel, es común terminar con 120 historias (o más) en una primera revisión del producto. Depurar este backlog es una tarea tediosa. Muchas de las horas mas miserables del desarrollo se gastan en reuniones eternas intentando priorizar el backlog...
El mapa de historias
Una alternativa para solucionar estos problemas es organizar las historias de usuario con una forma útil: un mapa.
En realidad es un concepto simple. Un mapa de historias pequeño podría verse así:
Arriba de todo (azul) se ubican las "grandes historias", llamadas actividades de usuario. Una actividad es una de esas "grandes cosas" que las personas hacen: a veces involucra a varios pasos, y no siempre tiene un flujo preciso. Por ejemplo, en un sistema de emails podría existir una actividad llamada "administrar email", "configurar los servidores de email", y "definir las respuesta de fuera de oficina".
La historia para una actividad podría quedar: "Como consultor quiero administrar mis emails para estar en contacto con mis clientes, colegas y amigos".
Pero esta historia es demasiado grande para ubicarla dentro de una iteración o sprint.
Entonces, la historia se divide en otras historias como "enviar mensaje", "leer mensaje", "borrar mensaje", "marcar un mensaje como spam", y cosas similares. Estos elementos son las tareas de usuario. Una tarea de usuario es lo que hacen los usuarios para lograr un objetivo.
Así, se organizan estas "pequeñas historias" debajo de las "grandes historias" para ir armando una grilla.
Imaginemos al tiempo moverse de izquierda a derecha. Entonces, al ordenar las historias en el mapa, si la persona que usa el sistema en general hace una cosa antes de otra, ubicamos la primer historia a la izquierda, y la otra a su derecha. Esto se puede realizar con las actividades y con las tareas.
¿Qué pasa si los usuarios dicen que hacen todo en cualquier orden? Lo mejor es entonces pedirles que ellos mismos cuenten, a gran nivel, las actividades. Ese mismo orden en el que las recitan es el orden que se puede usar. De hecho, el orden correcto es aquel que permite explicar el compartamiento del sistema. Estamos construyendo un mapa que permita contar la gran historia del sistema. El mapa se tiene que construir de manera que ayuda a contar esta historia.
Mantener las historias épicas (y cambiarle el nombre...)
Las historias realmente grandes suelen llamarse "épicas". Son historias demasiados grandes para estimarlas y construirlas. Cuando aparece una épica en el backlog, es momento de tomarse el tiempo de discutirla en más detalle. Es común entonces que varias personas quiten la historia épica, la descompongan y reemplacen con las partes que identificaron. Aquí es donde metemos la pata. Y es que deshacernos de la historia épica es tomar la sierra eléctrica y cortamos el árbol, dejando las hojas en una bolsa.
La historia grande tiene un contexto. Era una forma simple de representar toda una actividad que las personas están haciendo. Es una forma rápida de explicarle a otros lo que hace el sistema.
Y de paso, la palabra "épica" es odiosa. No estamos hablando del Señor de los Anillos. No hay un heroe, ni armas mágicas, ni dragones. Es tan sólo la historia "administrar email": algo bastante básico desde el punto de vista del usuario.
Caminar el mapa
Con un mapa terminado, tenemos algo que podemos colgar en la pared, o desplegar en una mesa, y con esto podemos generar debates. Se puede caminar el mapa de principio a fin junto al usuario, dueño del producto o desarrolladores y contar la historia del sistema, acerca de los usuarios del sistema y lo que hacen. Si miramos la parte superior (las grandes historias) tendremos un resumen de todo el sistema. Podemos ir descendiendo en donde queremos ver más detalle.
Caminar el mapa es una buena forma de encontrar elementos faltantes, u orden incorrecto en las actividades. También se pueden anotar historias problemáticas, o situaciones en las cuales el usuario tiene problemas en la actualidad (¡son oportunidades de mejora!).
Los usuarios así pueden visualizar el sistema completo, ver su propia actividad en un mapa, y ayudarnos a corregirlo.
Uno de los principales objetivos del mapa de historias es poder asegurarnos que realmente "tenemos" todo el sistema, y que no se nos olvidó ningun aparte importante.
La columna vertebral del software
Nuestro software tiene una columna vertebral y un esqueleto, y el mapa se encarga de mostralos.
Las historias superiores son justamente la columna vertebral del sistema, el motivo de ser y de donde se desprende toda la funcionalidad. Las historias inferiores son el esqueleto, unido por estas historias superiores.
Las historias de la columna vertebral no se priorizan: simplemente existen. En cambio, si se priorizan las historias más pequeñas, que dependen de este columna principal. Mientras más arriba estén, más necesarias resultan. Una vez ordenadas, todas las historias ubicadas más arriba en el mapa describen al sistema en su forma más básica, lo mínimo que tendría que hacer.
Planificar usando el mapa
Al momento de planificar entregas, como vimos, no es importante priorizar los elementos de la columna vertebral del mapa. Por ejemplo, si fueramos a construir un auto, los elementos principales serían:
> motor> transmisión
> frenos
> suspensión
> ...
Sería estúpido si nos ponemos a negociar: "¿qué es más importante, el motor o la transmisión?", o "no tenemos suficiente tiempo para la entrega, ¿podríamos entregar el auto sin los frenos y los añadimos después?".
Estos elementos son esenciales, y se los necesita para poder entregar un producto viable mínimo (o MVP, Minimum Viable Product).
En los niveles inferiores, en cambio, la priorización cobra sentido: ¿motor de 4 cilindros o 6 cilindros? ¿frenos con ABS o sin?
Cuando se prioriza un mapa de historias, se mueven las tarjetas o notas adhesivas para arriba y para abajo, indicando más o menos importancia. Luego se puede pegar una cinta para demarcar toda una línea de historias de la "misma importancia", creando así líneas horizontales para cada entregable.
Mantener el mapa visible
Construir el mapa de historias nos va a ayudar a tener una mejor comprensión inicial de la funcionalidad. Pensemos un poco: ¿en qué momento de todo el proyecto ya no nos interesa entender la funcionalidad? Obviamente, siempre es importante entender lo que estamos haciendo. Y sin embargo, usar un backlog plano no favorece a esto (nuevamente, estamos "cortando el árbol" que tanto nos llevó ver crecer).
Un mapa de historias público, pegada en la pared, se convierte en un excelente radiador de información que promueve el debate sobre el producto que estamos construyendo. Sirve para identificar las historias que se construirán en el próximo sprint, y como recordatorio constante del lugar que ocupa cada historia dentro del sistema en su totalidad.
Al construir software de manera incremental, historia por historia, se eligen primero las que se encuentran más arriba en el mapa de historias, de izquierda a derecha, de arriba hacia abajo. Nos vamos moviendo a través de la columna vertebral del mapa, y bajando por las prioridades. No construimos una única característica a la vez, sino más bien avanzamos por todas las características importantes. De esta manera nos aseguramos no entregar un auto sin frenos.
Más sobre mapas de historia
Los invito a que lean más sobre mapas de historia en el PDF original How you slice it (en inglés).
Basado en The new user story backlog is a map.
