Mapa de Historias Gestión de Proyectos

El mapa de historias de usuario- Jeff Patton (http://jpattonassociates.com/user-story-mapping/) es una técnica ágil que permite trabajar con una de las mayores problemáticas que aparece en la construcción de aplicaciones y productos tecnológicos software : la elaboración de documentación compartida no genera entendimiento compartido. Un ejemplo tradicional y común: definir y analizar los requisitos de cómo queremos que funcione una determinada aplicación y plasmar los resultados de reuniones, entrevistas, encuestas,… que podamos realizar con todos los interesados clave, en diferentes tipos de documentación como documento de requisitos alto y bajo nivel, casos de uso, diseño de arquitectura, patrones,….

Todo parece ir bien al inicio del proyecto, dónde existe un alineamiento entre todos los participantes o al menos esa es la impresión. Pero una vez que ya estamos obteniendo resultados de los requisitos definidos nos damos cuenta que esa sinergia inicialmente consensuada no lo es tanto en absoluto, y empezamos a ser conscientes que tenemos un entendimiento diferente en nuestras cabezas.

Este es un ejemplo de cuantas veces ocurre que lo que inicialmente interpretamos como una meta conjunta y consensuada, cuando empezamos a trabajar, nos damos cuenta que estábamos pensando cosas completamente diferentes.

Fuente: www.comakewith.us, Jeff Patton

El mapa de historias de usuario trata de mitigar el riesgo de este escenario a través de la gestión visual y la conversación. Por un lado, usa herramientas visuales como tableros físicos- posteriormente se puede llevar a un soporte digital si es necesario- y postits para trasladar el entendimiento que se va generando de lo que se quiere construir con la participación de todos los interesados clave, y además utiliza el modo de comunicación que tiene mayor probabilidad de éxito, la comunicación cara a cara con retroalimentación a través de la conversación continua entre todos los participantes, como base para la generación del entendimiento compartido.

Fuente: www.comakewith.us, Jeff Patton

Se trata pues de una técnica ágil perfectamente utilizable no sólo por el motivo para el que se ideó, construir aplicaciones de software, sino en cualquier contexto que demande conseguir el entendimiento compartido más allá de los resultados que se muestran en la documentación a desarrollar.

En particular utilizamos la técnica para trabajar el mapa de historias de usuario de la gestión de proyectos de una organización. El mapa resultado dinámico y evolucionable, es el fundamento junto con el apoyo de otras técnicas para construir una nueva metodología para la gestión de los proyectos de dicha organización, que no parece por concepto algo «ágil».

Lo más importante no es el documento o documentos entregables como resultado del proceso de definición de la metodología de gestión de los proyectos, sino este propio proceso o camino en la búsqueda del entendimiento compartido, el empoderamiento en los propios involucrados para participar en la construcción del cambio en la forma de trabajar de la organización, y establecer la base de un proceso de mejora continua mediante la inspección y adaptación conforme se vaya implementando la metodología inicialmente establecida para aprender tanto de lo que funciona como de aquello que no genera los resultados esperados.

La técnica del mapa de historias de usuario en este contexto abarca el ciclo de vida global end-to-end de la gestión de proyectos para la metodología, que sería el “producto” a definir, incluyendo la etapa de viabilidad pre-proyecto e incluso parte de la etapa del posible traspaso al área de operaciones.

La técnica del mapa de historias de usuario comprende una serie de pasos a realizar, que de forma resumida serian:

1. Enmarcar: Qué se quiere hacer, Quienes participan y Por qué se quiere hacer. Antes de mapear, creamos una breve descripción del producto para enmarcarlo y contextualizar el mapa. Este paso inicial fundamental lo trabajamos con una técnica ideada por nuestro compañero Raúl Herranz: el diagrama WAGI (http://blog.utopicainformatica.com/2014/03/el-diagrama-wagi-o-diagrama-de-mangle.html ) que recopila a su vez de forma ingeniosa una serie de técnicas ya reconocidas en su utilidad como los 5whys y el GQM (Goal, Question, Metric), para ayudar a enmarcar un proyecto de coaching/asesoría de implementación de agile en una organización. Vuelve a ser un objetivo trabajar con gestión visual el entendimiento compartido, en nuestro caso para la pregunta ¿Por qué queremos una metodología de gestión de proyectos en la organización?.

Se trabaja en identificar los beneficios/objetivos que la organización pretende obtener, o problemática que se quiere resolver con el producto “metodología de gestión de proyectos”, como seremos capaces de medir los logros pretendidos y quienes deben participar en el proceso y como deben hacerlo.

Es importante identificar cuáles son los diferentes usuarios que usaran el producto, y lo «electores» o clientes que “compraran” el producto, y para cada usuario y elector establecer el beneficio que pretende obtener de utilizar el producto.

A modo de ejemplo, diferentes actores que participan en la gestión de proyectos y productos de una organización (con una nomenclatura estándar) podrían ser:

CEO/Presidencia (“comprador”)
Director/Gestor de proyecto
Dueño de producto(agile)
Miembro del equipo
Manager funcional
Cliente
Usuario
….

Esto nos permitirá personalizar el “producto” metodología a las necesidades de cada rol y empatizar con todos los participantes. Se trata de crear el escenario de cada rol.

2. Mapear el Big Picture: Focalizarse en obtener la historia completa –think «mile-wide, inch deep»-: lo importante es cubrir todo el ciclo de vida de experiencia del usuario a través de las actividades y tareas de alto nivel que realiza y que cuentan la historia completa, formando el llamado backbone de nuestro mapa de historias.

Fuente: www.comakewith.us, Jeff Patton

Un mapa de historias de usuario contiene dos importantes características “anatómicas”

El backbone de la aplicación/producto es la lista de actividades-grandes historias o metas- esenciales que la aplicación/producto soporta.
El walking skeleton es el producto que construimos que soporta el mínimo número de tareas necesarias a través del ciclo completo de la experiencia del usuario.

De forma generalista y resumida, para el desarrollo del backbone comenzamos con el usuario más crítico para el éxito del proyecto e imaginamos un típico día en la vida del usuario con el nuevo producto. Mapeamos las acciones como tareas del usuario de izquierda a derecha.

A continuación identificamos las actividades del usuario, que son los grupos de tareas que trabajan juntas para soportar una meta común. Las actividades típicamente emergen después cierto tiempo transcurrido tras haber empezado a trabajar el mapa.

Después, se añaden los usuarios adicionales. Una vez hayamos pensado en el típico usuario del producto, podríamos trabajar con los otros tipos de usuario en nuestra historia. Continuamos modelando su historia de izquierda a derecha.

Para nuestro particular “producto” de la metodología de gestión de proyectos, como elemento de ayuda para plantear este nivel más alto del mapa de historias –backbone– podemos partir del marco propuesto por la guía de buenas prácticas en gestión de proyecto del PMBOK, que no es una metodología y que, en contra de creencias extendidas, no promulga un estricto apego a normas o documentación que no sean valiosas. A partir de PMBOK podemos construir tanto una metodología más predictiva aplicable a proyectos simples o complicados, como una metodología más ágil en escenarios de proyectos complejos (https://en.wikipedia.org/wiki/Cynefin_framework).

Tenemos pues el backbone identificado y establecido a través de las etapas de gestión propuestas en PMBOK: Estudiar la viabilidad del proyecto-esta no es formalmente PMBOK-, Iniciar el proyecto, Planificar el proyecto, Ejecutar el proyecto, Monitorizar y Controlar el proyecto y Cerrar el proyecto. Posteriormente podremos usar las diferentes áreas de conocimiento descritas en PMBOK para trabajar el mapa de historias en los diferentes niveles.

Hacer hincapié en que el mapa de historias de usuario puede reflejar de izquierda a derecha el posible orden cronológico de las acciones a realizar por los diferentes actores de la aplicación, aunque esta característica es posible que no siempre se cumpla o incluso que haya intercambios temporales para ciertas acciones.

Nuevamente para el caso de la gestión de proyectos, el propio planteamiento de la etapas de gestión implica cronología, si bien es cierto que es fundamentalmente en la etapa de planificación dónde se llevan a cabo procesos/ actividades con lógica temporal. Por ejemplo, se define/estima que se quiere construir a alto nivel, para después tratar de detallarlo- al menos el corto-medio plazo- y estimar cuanto tiempo y dinero implica desarrollarlo.

3. Explorar: Se trata de rellenar el cuerpo del mapa de historias descomponiendo las grandes tareas/actividades del usuario en sub-tareas más pequeñas y detalladas, e idealmente obtener como segundo nivel el llamado walking skeleton, que representa la primera versión/release del producto metodología que pretende entregar el mejor producto posible con las restricciones temporales presentes. Es la versión de funcionalidades más simple posible del producto que cubre el ciclo de vida completo del usuario a través de las actividades objetivo mostradas en el primer nivel del mapa –backbone-. Debe servir para validar el desempeño cuando se comience a implementar y ser escalable, por ejemplo por tipo o tamaño de proyecto.

En esta fase podremos añadir tarjetas al tablero físico del mapa de historias, dividir una tarjeta en dos, re-escribir tarjetas y reorganizarlas. Usar esta fase para pensar en el «cielo azul» sin restringir sobre todas las posibilidades que aparezcan y para pensar en todo lo que podría ir mal y qué tendría que hacer el usuario para corregirlo. No preocuparse si las ideas están «fuera de alcance».

Jugar a: «no sería fantástico si…» para grandes ideas del producto. Investigar variaciones: ¿qué más podrían haber hecho los usuarios?

Seguir considerar los otros usuarios: ¿Que podrían hacer otros tipos de usuario para alcanzar sus objetivos?

Añadir otros detalles del producto como herramientas de ayuda a la gestión del proyecto, reglas de negocio,…

Involucrar a otros: contar la historia de tu producto a otros para explicarles los usuarios y el uso. Encontrar agujeros en tu historia y la ayuda para cubrirlos. Ellos te pueden apuntar a áreas con riesgos o que resulten caras de implementar.

4. Dividir en Versione/Releases viables: El mapa de historias pretende ser dinámico y poder evolucionar, así como implementar el producto metodología de gestión de proyecto resultante de forma gradual e incremental para ir midiendo los resultados y aprender a través de un proceso de mejora continua. Se trata pues de cortar el mapa en “versiones” de producto viables que dividan los usuarios y el uso del producto. Estas rebanadas forman una hoja de ruta incremental de las versiones-releases- del producto donde cada versión es una liberación de lo que se conoce como producto mínimo viable.

Es recomendable para cada release, describir los resultados que son objetivo e impacto esperado, y como contribuyen a la meta global descrita tras el paso 1 sobre el por qué. Esto sirve de motivación para la construcción del producto.

Para cada release identificar la métricas clave de identificación de éxito del producto (forma parte también de la técnica wagi).Es la respuesta a la pregunta ¿Que podremos medir para determinar si este producto es exitoso?.

5. Estrategia de desarrollo/implementación: El mapa de historia también trata de reflejar en el eje vertical de arriba a abajo el criterio de importancia/necesidad en orden descendente de las historias conforme se van descomponiendo y detallando hasta un nivel apropiado.

El objetivo es cortar la primera release/versión del mapa, el “walking skeleton”, para permitir a la organización aprender rápidamente y evitar/mitigar riesgos de implementar toda una metodología y procesos asociados que no se vayan probando y midiendo el beneficio que se obtiene o la problemática que se resuelve.

A partir de esta primera versión, avanzamos completando las principales funcionalidades, haciéndolas más ricas y más detalladas. Seguimos buscado las pruebas con los usuarios y recibiendo retroalimentación para ajustar el producto.

Con el desarrollo de los talleres de trabajo para construir el mapa de historias de la gestión de proyectos, se profundiza y adapta para considerar casuísticas como tipologías- interno, para terceros- y tamaño de los proyectos, orientaciones predictiva y ágil para la gestión,… que pueden conducir incluso a la generación de más de un mapa.

Como ejemplo ilustrativo del trabajo sobre el mapa hasta un segundo nivel (las historias que aparecen son ficticias y parciales pero sirven para mostrar el resultado de la técnica):

Esta web usa cookies