El martes estuve en la Charla-Taller de Cylicon Valley, Story mapping, de la mano de beCodemyfriend. Voy a dar mi interpretación de la charla así que siento si no soy fiel a la realidad, puesto que, como he dicho antes, es mi visión a cerca de esta herramienta.

Según nos contaron, esta herramienta estaría dentro de un proyecto agile, un proyecto en el cual se sigue Scrum y en el que se definen Historias de usuario.

Definición de Story Mapping: es una herramienta que te permitirá ir construyendo un Backlog de historias de usuario junto con tu cliente.

¿Quién debe ir a este tipo de reuniones? Cliente, 1 o 2 desarrolladores, CTO, stakeholders (personas que las interesa que el proyecto salga bien pero que no participan activamente en el desarrollo del mismo), un alien que no tiene ni idea de lo que va a ver pero que está comprometido y quiera llegar a cumplir los objetivos de la reunión (construir un backlog entre todos que dé como resultado una aplicación que valor al usuario final).

Voy a ir explicándoos la imagen (perdonad por la imagen…lo mio no es dibujar… :)).
Lo primero, definir los roles que van a interactuar con la aplicación (son los monigotes de arriba). Se define el contexto en el que nos vamos a mover (suelen ser condiciones trasversales a todo el proyecto, como por ejemplo, el presupuesto del que se dispone, las medidas de calidad que se van a implementar, restricciones globales a toda la aplicación…. etc.).
Se fijan los ejes (pintados en verde). El eje de las X es el tiempo o secuencia en el que se deberían desarrollar y terminar las historias. En el eje de las Y la necesidad, la cual nos ayuda a medir el valor que tienen esas funcionalidades para el usuario final.
Como veis en el Backbone hay una serie de Actividades (épicas, suelen ser explicaciones, a grosso modo, de las funcionalidades. Sin entrar en mucho detalle). El Backbone define las actividades mínimas que tiene una aplicación. Por ejemplo, tiene que dar de alta usuarios (Actividad 1) y permitir que compren (Actividad 2).
Debajo de cada actividad se van escribiendo las historias de usuario (H1, H2….) correspondientes a cada actividad y se van colocando respetando los ejes previamente definidos.
En el Walking Skeleton está el número mínimo de historias que abarcan el espectro de la aplicación. Si en alguna Actividad no hay historias dentro del Walking Skeleton podemos llegar a la conclusión de que esa actividad no es tan prioritaria para el cliente y se puede repriorizar o incluso con el tiempo suprimir (Aquí ya vamos viendo las ventajas de trabajar este mapa visual con el cliente…).
Se pueden definir en este momento (siempre con el cliente presente) las release o entregas que se van a hacer. Puede que las historias a entregar en la primera release sean más que el Walking Skeleton, eso puede ser porque dan más valor al usuario final y son necesarias para que la primera release ya sea un producto (aunque sin todas las funcionalidades deseadas) usable.

Beneficios de Story Mapping:

• Conversación con el cliente!!!!! Muy importante porque muchas veces el cliente pide pide, pero luego no se da cuenta de que eso le supondrá dinero y puede que no sea de mucho valor por el usuario final de la aplicación.
• Análisis de las funcionalidades (a un alto nivel, no se definirán muy exhaustivamente porque no es la prioridad máxima).
• Es muy visual y de un simple vistazo se pueden ver determinados fallos (algo que parecía muy importante no tiene historias en el walking skeleton…)
• Planificación de release (que no de proyecto) Esto es como un paso intermedio que ayuda a definir las entregas que van a dar valor a cliente. Pero no definirá estimación en tiempo…

Consideraciones: Se pueden cambiar los ejes, por ejemplo, el de la necesidad se podrá cambiar por coste, y así una misma historia de usuario se podrá valorar tanto por importancia al usuario final como por coste a cliente….