Historias de Usuario: dos aproximaciones distintas (II)

En el artículo anterior hablábamos sobre lo que nos ofrece el modelo de historias de usuario para especificar las cualidades del producto a desarrollar. En esta segunda parte, voy a abordar una forma de escribir historias de usuario a través de una técnica muy conocida por muchos: User Story Mapping, de Jeff Patton.

El objetivo de este artículo es ver cómo la técnica User Story Mapping nos permite escribir un tipo concreto de historias de usuario, no explicar la técnica en sí misma. Para ver una explicación completa sobre cómo usarlo y todo el partido que le podemos sacar, puedes visitar esta dirección. Así mismo, no voy a desarrollar el contexto de cada historia de usuario, sino que voy a poner el foco en la redacción del título, para así ver cómo pensar en historias de usuario.

User Story Mapping

Esta técnica nos invita a describir acciones concretas del usuario con nuestro producto. Una vez identificadas esas acciones, pensamos en las tareas que hay que desarrollar para realizar esas acciones, con el objetivo de que esas tareas describan un flujo básico de cada acción y, todas en conjunto, describan un flujo de nuestra aplicación. Jeff Patton indica que contemos una historia. Esas tareas se convertirán en historias de usuario, de forma que constituyan un incremento de parte del flujo de la aplicación.

Un ejemplo sencillo

Vamos a ver cómo crear historias de usuario de esta manera a través de un ejemplo muy sencillo: ¿qué hago todas las mañanas desde que me levanto hasta que me voy a la oficina?

User activities

Imaginemos que estamos en un bar tomando una cerveza. Sí, sé que para un español medio eso es algo raro, pero hagamos el esfuerzo. Estamos con nuestros amigos y alguien comenta: – Yo me levanto todas las mañanas y en 15 minutos estoy saliendo al trabajo -. Levantamos la mirada con absoluta fascinación por ser capaz de realizar semejante proeza, a lo que nosotros contestamos: – Vaya, pues yo necesito un montón de tiempo. Cada mañana, cuando me levanto, preparo el desayuno, desayuno, me aseo, me visto, preparo la mochila y me voy, y para hacer todo esto necesito una hora-.

Vemos como las actividades, a alto nivel, serían:

• Preparar el desayuno
• Desayunar
• Asearse
• Vestirse
• Preparar la mochila

Así, tienen mucha semejanza con lo que denominamos Épicas.

User tasks

Si pensamos en desarrollar un poco más la conversación, podemos comentarle a nuestros amigos que preparar el desayuno consiste en tostar el pan, triturar tomate o preparar un par de lonchas de pavo y en preparar el café. A la hora de desayunar, solemos tomarnos primero las tostadas y, después, el café despacito para saborearlo bien. Una vez que pasamos al aseo, nos lavamos los dientes, deslizamos nuestra cara por la cuchilla suavemente para no cortarnos y, por último, hacemos una pasadita por el túnel de lavado, la ducha.

De esta forma, las user tasks quedarían:

• Preparar el desayuno
  • Tostar el pan
  • Triturar tomate o preparar dos lonchas de pavo
  • Preparar el café
• Desayunar
  • Tomar las tostadas
  • Beber el café
• Asearse
  • Lavarse los dientes
  • Afeitarse
  • Ducharse

Con esto podemos hacernos ya una idea de cómo va quedando explicado el flujo normal a través de las user tasks. Estas user tasks serán nuestras historias de usuario, aunque podemos desgranarlas más. Si cogemos, por ejemplo, Lavarse los dientes, podemos sacar varias opciones distintas: Lavarse los dientes con cepillo, lavarse los dientes con cepillo y hilo dental, lavarse los dientes con cepillo y enjuague bucal… Como vemos, podemos sacar más historias de usuario de una sola.

Estilo de user stories

Como podemos observar, primero describimos un flujo y, a continuación, describimos con más detalle en qué consiste ese flujo, planteando además distintas posibilidades de completar cada una de las partes, incrementando así las posibilidades y, por tanto, lo ofrecido. Al final, incrementamos el valor de cada parte del flujo. La idea tras esto es trabajar en las historias de usuario de manera horizontal, no vertical, para tener un flujo completo lo antes posible y, posteriormente, vitaminarlo.

Esta alternativa es muy útil para aquellas personas que están habituadas a pensar de esta manera, además de dotarnos de un mapa completo del proyecto que nos permite generar, visualmente, estados del desarrollo del producto, identificación de riesgos y dependencias, etc., teniendo en cuenta el scope completo. Esto está muy bien si ese scope sabemos de antemano que es cerrado, pero pierde valor si el scope está abierto a modificaciones. Además, para completar un flujo completo de funcionalidad, hace falta desarrollar mucha funcionalidad, y eso puede retrasar la obtención de cierto feedback.