martes, 19 de mayo de 2015

Story Mapping en acción

En el artículo anterior hablamos del objetivo general del Story Mapping, cómo realizar la convocatoria y otras características generales. Como prometí, esta vez voy a entrar en mayor detalle en la mecánica de la construcción.

Aviso: después de facilitar muchos talleres con esta actividad uno desarrolla ideas y tácticas propias, así que es importante destacar que voy a describir la manera en que yo veo el Story Mapping, que puede no coincidir con la de otros. La mayor parte está tomada de Jeff Patton, pero hay agregados personales que surgen de mi aprendizaje continuo practicando esto, sobre todo en América Latina, que puede cambiar el contexto cultural.

Cúentame tu vida

El primer paso de esta actividad es charlar sobre el problema que queremos resolver, pidiendo a los involucrados que cuenten la historia detrás. Usualmente dejo que esta parte sea bastante libre, y a medida que ellos cuentan los detalles, voy anotando en papeles algunos detalles como personajes, acciones, lugares, etc.

Voy a dejar para más adelante el tema de personajes y técnicas específicas para usarlos en el contexto del diseño del producto, y por ahora vamos a concentrarnos en la historia de alto nivel. Como ejemplo, vamos a tomar el clásico sistema de ventas, porque creo que es algo bastante común para todos los que desarrollamos software, y aunque puede haber algunas diferencias menores entre países, es un dominio relativamente conocido y sencillo de entender.

Supongamos entonces que de la narración de los involucrados sobre cómo es el proceso, aprendemos que: "hay un cliente que llega y realiza un pedido, para lo que hay que buscar los productos en el depósito y preparar la entrega mientras se le realiza una factura, que debe pagar."

Podemos preguntar algunos detalles más, y finalmente aislamos ciertas actividades principales a partir de esa historia, y algunos detalles para cada una. No voy a entrar mucho en los detalles del ejemplo, que están elegidos para dar una idea del flujo. Podríamos terminar con una serie de actividades de primer orden y un segundo nivel de actividades como el que se ve aquí:

Actividades principales

Algo que tratamos de mantener es que leyendo las notas de más arriba y agregando algunos conectores en el medio, podemos reconstruir la historia original: "llega un pedido, se busca en el inventario, se factura y luego se cobra".

La segunda línea agrega algunos detalles o partes de cada actividad principal. El Pedido, por ejemplo, tiene productos y condiciones, el Inventario requiere chequear si hay suficiente para un pedido, entregarlo, en algún punto requerirá reposición, etc.

El demonio está en los detalles

A partir de este "espinazo", podemos empezar a entrar en los detalles de cada una de esas secciones, hacia abajo, para entender el panorama completo. Eventualmente podemos llegar a algo como:

Detalles de la historia

Como se ve, en un primer nivel tratamos de cubrir todas las características que creemos necesarias, sin importar todavía el orden o valor de cada una.

Entregas y esqueletos caminando

El siguiente paso es -ahora si- comenzar a priorizar. Lo que vamos a tratar de hacer es ver qué es lo imprescindible de cada columna para una primer entrega que sea valiosa, desde el punto de vista de habilitarnos a usar la solución y obtener algún resultado. Es probable que podamos incluso saltear alguna columnas para la primer entrega.

Y como un valor que buscamos siempre con estas técnicas es maximizar el aprendizaje, usualmente buscamos una entrega anterior a la primera "oficial", de carácter interno, que solemos llamar Walking Skeleton (esqueleto caminante), y que debería permitirnos verificar que cumplimos el circuito que queremos recorrer (la solución ya camina) aunque todavía no podríamos exponerlo al público (le falta carne).

Una vez que encontramos ese esqueleto posible, podemos avanzar, agregando lo mínimo indispensable para llegar a la primer entrega que haríamos a nuestro público. Obviamente, esto asume que cuando construyamos realmente el Walking Skeleton lo que aprendamos no nos haga replantear toda la situación. Si es de esperar que comprendamos mejor y tengamos que hacer algunos retoques a nuestro plan.

En la figura se ve un posible Walking Skeleton y una primer entrega (R1 o release 1):

Walking Skeleton y R1

Por supuesto podríamos discutir si en este ejemplo las características elegidas alcanzan o no, pero supongamos que entre todos los involucrados en el ejercicio de Story Mapping (responsables del negocio, roles operativos, gente de tecnología, procesos, etc) nos hemos puesto de acuerdo en que el esqueleto es suficiente para aprender lo que necesitamos y probar el circuito completo, y que agregando lo mínimo podemos tener una primer versión valiosa, que en este caso nos permitirá tomar pedidos para entregar en el momento, facturarlos y cobrar en efectivo y cheque (que por alguna razón es necesario para arrancar).

Como vemos, esta primer entrega es muchísimo más pequeña que lo el alcance total que imaginábamos, pero mediante este ejercicio encontramos qué es lo mínimo que nos permitirá empezar a usar la solución tempranamente, en una fracción de lo que involucraría construir toda la funcionalidad imaginada.

Este es un tema clave en el desarrollo ágil, y como vemos, el Story Map nos permite tener una visión global, para que el foco de corto plazo en el backlog de producto no nos haga perder de vista el objetivo final.

En uno o dos artículos más voy a profundizar en alternativas, el uso del Story Map a lo largo del proyecto y algunos consejos a la hora de facilitar la actividad. Por supuesto, si tienen consultas o comentarios, pueden avisarme a través de Twitter, idealmente con el hashtag #StoryMap. Nos vemos.

martes, 5 de mayo de 2015

Story Mapping: de la Incepción hacia el Backlog de Producto

Tiempo atrás publiqué una serie de artículos sobre la práctica de Incepción Ágil que tuvieron bastante éxito y generaron varios comentarios y preguntas, entre otras, acerca de otra práctica relacionada, que a veces algunos incluyen como parte de la Incepción: User Story Mapping.

Esta técnica para analizar un proyecto (completo o un sub-proyecto) fue nombrada y documentada originalmente por Jeff Patton, primero en un artículo de su blog, y posteriormente en su libro "User Story Mapping" (pueden ver la tapa a la derecha), ambos inmensamente recomendables.

Conocí los detalles de esta práctica por primera vez alrededor de 2008 o 2009, y comencé a usarla en algunos proyectos míos o de organizaciones a las que estaba ayudando, y después de usarla al menos una docena de veces, comprendí mejor cómo aprovecharla y cómo facilitar su construcción, y se convirtió en una pieza clave para mi en el inicio de proyectos ágiles.

Lo que quiero hacer en este artículo es recorrer qué es un Story Map, cómo se genera, cómo se usa posteriormente y cuáles son sus beneficios. En algunos posteriores entraré en detalle sobre la mecánica de la reunión, las alternativas y conceptos subyacentes.

¿Cómo y cuándo?

Trabajando en conjunto

Como en el caso de la Incepción Ágil, el Story Mapping se realiza al inicio de un proyecto, o una nueva fase, típicamente en formato taller. Algunas veces se realiza como parte final de la Incepción, aunque para mi es bueno entenderlo como momentos diferentes.

La Incepción trata de poner el foco en asegurar que todos los involucrados acuerdan un objetivo común, ciertas características y restricciones del producto, y deciden en conjunto qué van a construir.

Story Mapping es una actividad que nos permite entrar en detalle estratégico sobre cómo construirlo, entender qué es lo fundamental, poner foco en la entrega temprana y entender cómo ir incrementando el valor frecuentemente.

Lo que tienen en común ambas prácticas, que para mi son complementarias, es el tipo de convocatoria: en ambos casos queremos contar durante toda la actividad con gente de negocios a nivel directivo y a nivel operativo, operaciones, procesos, infraestructura, desarrollo, seguridad, etc. Queremos tener representados a la mayor cantidad posible de sectores involucrados en el proyecto del que vamos a hablar, para tener una perspectiva amplia.

También, como en el caso de la Incepción, más allá del entregable (el Story Map) lo más valioso son las conversaciones durante el ejercicio. No deja de sorprenderme al facilitar encuentros de este tipo en diferentes organizaciones (desde micro-emprendimientos hasta corporaciones) cómo surgen discusiones que nunca se habían tocado antes a pesar de estar trabajando en el tema en cuestión durante muchísimo tiempo.

Dependiendo de la complejidad y la importancia del proyecto, la actividad puede durar desde 2 o 3 horas, hasta un día completo. En proyectos críticos he facilitado frecuentemente un día completo de Incepción y otro día completo de Story Mapping.

Entre uno y otro puede pasar un tiempo, porque a veces la Incepción sirve para confirmar qué tipo de proyecto tenemos que realizar (cuanto más temprano la hagamos, mejor, porque tenemos menos cosas decididas de antemano), y podemos tomarnos un tiempo para tener identificado al equipo de trabajo y saber quiénes deberían estar presentes para construir el Story Map.

 

¿Qué queremos lograr?

En los próximos artículos voy a entrar en detalles, pero para cerrar éste, quiero mostrar el resultado final y explicar cuál es la expectativa.

Story Map final

 

La imagen muestra un mapa de un proyecto real. La imagen no tiene nitidez suficiente para leer lo que está escrito en las notas, que es algo específico y particular de este proyecto, pero que no importa para explicar el resultado.

Lo que se ve en la primer fila, en las notas celestes, como cabeceras de cada columna, son las Actividades Principales del proyecto, en el orden en que fluyen en "la historia" contada por los diferentes participantes de la actividad. Hacia abajo de cada Actividad hay Detalles sobre cómo se realiza esa actividad, en muchos casos como alternativas o pasos que pueden ser o no opcionales.

Las líneas azules que cortan transversalmente el mapa (en dos tajadas finas, inicialmente) son las Entregas planificadas, cada una con el mínimo de funcionalidad necesaria para cumplir con el propósito de la solución. Como puede notarse, esas dos primeras entregas son muy pequeñas respecto al total del alcance esperado (el conjunto total de notas debajo de los encabezados celestes). Sin embargo, las dos entregas planificadas concentran el más alto valor de negocio, porque destraban problemas importantes y habilitan nuevas posibilidades. Esto suele suceder en casi todos los proyectos, siguiendo la ley de Pareto: aproximadamente el 20% del alcance da el 80% del valor de negocio de un proyecto.

Utilizando esta práctica, que detallaré más en los próximos artículos, podemos buscar ese mítico 20% y tratar de concentrarnos en tener el más alto valor rápidamente, que además nos permitirá tener un producto real funcionando y poder aprender de la experiencia concreta antes de seguir agregando funcionalidad en abstracto.

Actualización: podés encontrar el siguiente artículo de esta serie aquí.

jueves, 11 de diciembre de 2014

hack.summit() -> code(4).all

hack.summit()

Este evento virtual es imperdible para cualquier nerd que se precie de tal.

Fue una conferencia totalmente en línea con celebridades del ambiente del desarrollo y alrededores, y todas las sesiones están grabadas para verlas cuando uno quiera.

Algunas de la personalidades que me resultan más interesantes (a mi) son:

  • Kent Beck, el papá de XP y TDD
  • Ward Cunningham, corresponsable de XP e inventor de la Wiki
  • Rebecca Parssons, CTO de Thoughtworks
  • Scott Hanselman, dando pelea desde dentro de Microsoft
  • Bram Cohen, inventor de BitTorrent
  • Gilad Bracha, co-autor de la spec de Java y creador de Newspeak
  • Scott Chacon, CIO de Github
  • Tim O'Reilly, de O'Reilly Media
  • Orion Henry, fundador de Heroku

y unos cuantos más.

Espero que lo disfruten.

lunes, 8 de diciembre de 2014

Incepción Ágil: la pregunta del millón

¿Cuánto cuesta?

¡Llegamos a la última actividad de la Incepción!

¿Parece largo? En realidad muchas de las actividades pueden regularse para que avancen rápido ó podemos llegar a saltear algunas si tenemos menos tiempo. Eso es parte de la decisión del facilitador. Mi recomendación es tratar de recorrer las 10 actividades, aunque sea dedicándole 20 a 30 minutos en promedio a cada una, para que entre en una mañana o una tarde.

En la última actividad vamos a tratar de tener una estimación de MUY alto nivel sobre el costo del proyecto. Casi nunca llegamos a un número, sino a un nivel de inversión, como para responder dudas como (dependiendo del tipo de proyecto y organización):

  • ¿Podemos encarar esto con el presupuesto que ya teníamos?
  • ¿Necesitamos conseguir un inversor?
  • ¿Qué chances hay de que el proyecto se auto-financie a partir de X entrega?
  • ¿Hace falta conseguir aprobación presupuestaria del Gerente del Área? ¿Del Directorio?

Para poder llegar a alguna conclusión de ese tipo, lo que hacemos en grupos es una "lista de compras", en la que incluimos todos los costos importantes que pueden incidir, como:

  • Costo del equipo (si son internos y tenemos que costearlos, o si debemos contratar)
  • Equipamiento, espacio físico, licencias de software, suscripciones
  • Homologaciones, certificación o auditorías necesarias
  • Espacio físico o instalaciones necesarias durante el proyecto

Nuevamente, cada grupo presenta su lista, y se discute en conjunto hasta lograr una versión unificada. No es importante ponerle valores, más allá de una estimación muy gruesa para llegar a entender el nivel de presupuesto, pero esa lista será el punto de partida para empezar a elaborar el presupuesto definitivo cuando el proyecto arranque realmente.

Y con eso finalizamos el proceso de la Incepción. Dejo una foto de otro taller. 

Inception en un Taller

sábado, 6 de diciembre de 2014

Incepción Ágil: hablemos de prioridades

Balance de Prioridades

Como mencionamos antes, sabemos que nuestra Incepción va a darnos una idea general, pero que el proyecto va a ir mutando y adaptándose en el tiempo para lograr el mejor resultado posible.

Si embargo, podemos tratar de seleccionar algunas restricciones tempranas que nos ayuden a pensar si los cambios o novedades que aparezcan nos están alejando o no de la idea inicial. Y podremos en ese momento decidir que no es un problema, o incluso re-evaluar estas prioridades, pero lo bueno es tener más elementos para evaluar esas decisiones.

Para esta actividad los equipos se dividen en grupos nuevamente y piensan en una lista de requisitos no-funcionales o preocupaciones transversales al proyecto, como por ejemplo:

  • Costo de operación del producto final
  • Mantenibilidad
  • Time-to-market (cuanto antes tengamos algo, mejor)
  • Interoperabilidad
  • Equipo propio (o local)
  • Seguridad o Confidencialidad
  • Tiempo de respuesta
  • Cumplimiento de regulaciones
  • Cobertura desde múltiples dispositivos

...o muchos otros, desde características de calidad, temas de mercado, cuestiones internas o lo que nos preocupe.

Lo importante es que cada grupo quede con los 5 a 10 temas que les parecen más importantes tener en cuenta.

El siguiente paso es priorizarlos. Para eso prefiero una variante que aprendí de Alan y Ariel, que es seleccionar entre todos los que queremos priorizar, y a continuación elegir un participante por cada uno de los atributos a priorizar, que se pone de pie con una hoja de papel en la mano con el nombre de ese atributo. Esas personas se ponen en fila, y el resto, mirándolos de lado, de manera de verlos a todos, va intercalando con ellos, haciendo que se muevan hacia adelante o atrás en la fila, hasta que llegamos a un acuerdo.

Idealmente, al llegar al orden final, tomamos una foto de todos sosteniendo su cartel bien visible.

Esta actividad es más divertida con ese componente físico, y tiene también el valor testimonial de la foto con mucha gente involucrada, que perdura y queda para el equipo de proyecto. Muchas veces al ver las personas que participaron en esa priorización el mensaje es reforzado.

Insisto: esas prioridades no son inamovibles, pero tenerlas como filtro nos permite tener las discusiones necesarias a tiempo, y nos da contexto.