Historias de usuario

AVISO: LADRILLAZO (más de 2500 palabras). Creo que he superado a @eamodeorubio.

El pasado martes, en la reunión trisemanal del grupo de #madriagil, nos juntamos un grupo bastante numeroso a pesar de las bajas y la dura competencia del fútbol. Quiere ello decir que hay renovación en las personas y que se ha consolidado el trabajo de evangelización que entre todos hemos ido haciendo durante los casi dos años que llevamos. Somos ya tantos que no importa quién viene o deja de venir porque el “retorno de la inversión” para todos los que asistimos (regular o irregularmente) está garantizado.

Jesús Jiménez (aka @jjballano) propuso que hicieramos una sesión práctica sobre historias de usuario pero empleamos la primera media hora en introducir los conceptos más básicos (la mayoría, si no todos, contenidos en el libro de Mike Cohn: “User Stories Applied”; imprescindibles al menos los dos primeros capítulos). Entre otras cosas hicimos mucho hincapié en las tres C (Card, Conversation, Confirmation) y en que una buena historia debe ser INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable).

He de reconocer que monopolicé mucho la reunión. Las historias de usuario es un tema que me fascina porque es justamente la frontera entre lo púramente técnico y lo puramente de negocio. (Cuando digo negocio no necesariamente hablo de esto sino más bien de esto otro). Además, debo agradecer a Jesús la paciencia que tuvo conmigo porque desde el principio le fastidié provocando una “mini-incepción“. En mi opinión, es un error que cometemos demasiado a menudo: no obligar al dueño de producto (asumimos que tenemos uno) a reflexionar sobre la causa raíz de por qué tenemos que construir la aplicación que nos está encargando. Trataré de reproducir (en la medida que mi memoria me lo permita) la discusión que tuvimos.

El lienzo en blanco

Antes de empezar ya tuvimos una pequeña refriega metodológica: que si empezar directamente por las historias de usuario, que si empezar por los roles o incluso que si empezar por esa mini-incepción que yo proponía. Bueno, como me levanté y me puse en la pizarra rotulador en ristre, pues, ejem, ya os podéis imaginar qué hicimos… 😀  Ahora en serio, exploramos un poco sobre las motivaciones del cliente para arrancar el proyecto como manera para empezar a familiarizarnos con el problema y para establecer una misión para el proyecto. De esa manera, podemos evitar alejarnos del objetivo principal si en algún momento empezamos a escribir una historia que no aporta valor para conseguir esos objetivos declarados del proyecto. Así, cuando se da esa situación, podemos replantearnos los objetivos (que no deberíamos porque se supone que serán bastante sólidos) o revisar si esa historia es oportuna o no en el contexto del proyecto.

Incluso alguien (lo siento, no recuerdo quién fue exactamente) preguntó qué pasa si viene el comercial con una idea del producto y se creó un breve pero intenso debate. <offtopic>Yo, es que cuando oigo la palabra comercial, es que me entra un pitido en los oidos y tardo en recuperar la audición. 🙂 Es broma, amo a los comerciales, son los que hacen posible que lleguen los proyectos a los talleres… pero, claro, llamar comercial a alguien que vende motos…. Ea, lo voy a dejar que me caliento. 🙁 </offtopic>

Jesús quería algo así como una aplicación para que el grupo de #madriágil pudiera quedar sin hacer mucho ruido en la lista de Agile-Spain. Para arrancar la discusión empezamos escribiendo ese objetivo en la pizarra y le ofrecí como solución un googlegroup alternativo. Mmm. A Jesús no le gustó. Él quería gastarse su dinero en una aplicación y yo le estaba ofreciendo una solución muy sencilla. Así que seguimos hablando… conversando… y llegamos a que también quería centralizar la información y actividades que hace el grupo en un único sitio. ¡Ajá! Lo escribimos en la pizarra. Y para volver a fastidiar un poco más (y acercarme a los cinco por qué) le dije que en el googlegroup se queda toda la información a modo de histórico.

OBJETIVOS:

  • Minimizar los correos a la lista de Agile-Spain para quedar en Madriágil
  • Centralizar toda la información que genera Madriágil : elección de fecha / lugar / tema + histórico

Seguimos escribiendo algunos roles que fueron apareciendo durante la conversación y sus responsabiidades principales. Nos salieron el “miembro de madriágil” (que podía identificarse) y “cualquier persona” (que podía ver los eventos publicados). Pensé que íbamos a ir por el camino de las tarjetas de CRC, pero al final aquello no cuajó y avanzamos en la conversación hasta concluir que lo que Jesús quería verdaderamente era simplificar la elección de lugar, fecha y tema para las reuniones del grupo y además tener un histórico que se pudiera consultar de todo eso. ¡Bien! Ya teníamos la primera historia de usuario a punto para ser escrita:

Como miembro de madriágil
Necesito crear un evento
Para que cualquier otra persona pueda verlo (y decidir apuntarse)

(Nota: en las tarjetas que escribimos yo usé el verbo Quiero en vez de Necesito, aunque realmente durante todo el rato hablamos de Necesito.)

Confirmación

En el grupo hubo mucha discusión al respecto porque todos pensaban que se trataba de una historia épica y yo, para provocar (otra vez), les dije que para mi era un 1 y que al llegar a casa la tendría hecha. Mmmm… Era como haber sacado las cartas del planning póker y que todos sacaran un 100 y yo un 1. Algo no encajaba. ¿Qué sabía yo que ellos no sabían? ¿Qué sabían ellos que yo no sabía? ¿Qué estabamos suponiendo cada uno de nosotros? Conclusión: faltaba más conversación. (Otra vez). Para avanzar un poco escribimos la “definition of done” o, para los que echen de menos un poco de español en los términos, “criterio de aceptación” (¿no habíamos dicho “Confirmation” en CCC y “Testable” en INVEST?).

Confirmación:
En una página web (de momento) puedo ver los detalles del evento: Fecha / Lugar / Facilitador.

Llegados a este punto ya el cliente (Jesús) había tomado un montón de decisiones. La más controvertida fue la de que fuera una página web. Luis Fraile, por ejemplo, recuerdo que ofreció mostrar el resultado en un RSS. A mi me parece que eso es tomar demasiadas decisiones en una fase del proyecto donde aún hay mucha incertidumbre. Yo, por otro lado, ofrecí que fuera el equipo de desarrollo el que ofreciera la solución que le resultara más fácil (barata) dentro del timebox de la primera iteración. Al fin y al cabo, hacemos un desarrollo iterativo e incremental justamente para poder dar espacio a la innovación, a explorar aquellas soluciones que al dueño del producto no se le han ocurrido y que si toma demasiadas decisiones evita que aparezcan. Es el principio del “last responsible moment” (ver “Defer Commitment” en el libro “Implementing Lean Software Development” por ejemplo). Jesús se sintió bastante incómodo con mi propuesta. Era como si le estuviera diciendo que él no sabía lo que quería… 🙂 Curioso, porque realmente Jesús estaba jugando ese papel: el del cliente que no tiene muy claro lo que quiere. Lógicamente, tanto él como yo estábamos haciendo un poco de parodia de la vida real, por lo que nada es ni tan blanco ni tan negro, pero la parodia sirvió muy bien para escenificar cómo existe una tensión entre el técnico-que-sabe-mejor-que-el-cliente-lo-que-el-cliente-necesita y el cliente-que-sabe-mejor-que-el-técnico-cómo-se-deben-hacer-las-cosas. Mi conclusión: hay que tratar de dejar el qué al dueño del producto y el cómo al equipo. En medio, miles de claroscuros y matices que no caben en este ladrillaco.

La potencia del criterio de aceptación es que nos puede servir de guía para la aceptación de la historia de usuario, bien en la demo, bien como guía para el propio proceso de desarrollo si hacemos ATDD y somos capaces de automatizar este criterio de aceptación (p.ej. con Cucumber, Fitnesse, Concordion, etc). Por ello, para que nuestras pruebas de aceptación automatizadas (también conocidas como especificaciones ejecutables) tenga un mayor recorrido, nos conviene no imponernos restricciones tecnológicas muy fuertes. Por ejemplo, decir que los detalles del evento se verán en una página web o en un RSS puede llegar a ser limitante si en el futuro queremos cambiar el enfoque del sistema y basarlo en otra tecnología. (Ya sé, es un caso algo extremo…) En cualquier caso, y para no abundar más en este asunto, os remito a la página 18 del libro de Cohn (“Negotiable” en el capítulo 2) y la 79 (“Keep the UI Out as Long as Possible” en el capítulo 7).

Tras romper la parálisis que siempre asoma cuando la pizarra está vacía y, en parte, superar también esa sensación de agobio por no definir todos los detalles, pasamos a la siguiente historia.

¿Qué más quiere el señor?

Ya habíamos visto que, de alguna manera, el equipo ya podría comenzar a iterar sobre la primera historia, que encajaba bien con el primer objetivo de reducir el ruido en la lista de Agile-Spain a la hora de organizar las reuniones del grupo de . Pero claro, no parecía suficiente. Así que seguimos hablando con el cliente y llegamos a algo como esto:

Como miembro de madriágil
Necesito apuntarme a un evento
Para reservar mi plaza

Aquí tuvimos muchísima controversia porque no estaba muy claro cuál era la mejor manera de escribir el valor que aportaba esta historia de usuario. Está claro que el valor (el “para”) debe ser descrito desde el punto de vista del rol que describe esa necesidad. Algunos decían que el valor que aportaba esta historia era que así la organización podía adaptar el lugar de reunión a la cantidad prevista de asistentes. Otros que era la garantía de tener una plaza reservada para asistir a la reunión.

Confirmación:
El miembro X [que realiza la petición para asistir al evento E] tiene reservada su plaza en el evento E.

(Nota: Entre corchetes una modificación que he introducido yo para dejarlo más claro. Pero no fue así exactamente como la escribimos durante la reunión.)

De nuevo vemos que no hemos tomado muchas decisiones y dejamos al albedrío del equipo tomar la decisión técnica. Sin embargo, esto provocó mucho debate porque… ¿desde qué punto de vista se hace esta comprobación de que la plaza en el evento está reservada para el miembro que ha realizado la petición? ¿Desde el punto de vista del sistema? Con una lista de reservas y comprobar que la de la persona en cuestión está presente sería suficiente. ¿Desde el punto de vista del usuario (el que escribe la historia de usuario)? En este caso sería algo como que el sistema proporcionara una confirmación de que se ha efectuado la reserva adecuadamente (bien con un mensaje en la pantalla, bien con un correo electrónico, un SMS…) Lo cierto es que nunca antes me había parado a pensar sobre esta posibilidad, pero después de reflexionar sobre ello, esta última opción tiene más pinta de que otra historia de usuario.

Más sobre el criterio de aceptación

La discusión nos llevó justamente a que Jesús escribiera esta nueva historia:

Como miembro de madriagil
Necesito tener una confirmación de que me he apuntado al evento
Para saber que tengo mi plaza reservada

Y estudiar las pruebas de aceptación que deberíamos hacer nos llevó a otra interesante discusión.

Confirmación:
En el caso de que sí tengo plaza: veo en pantalla un mensaje de confirmación [y recibo un correo-e]
En el caso de que NO tengo plaza: –> ¿cómo sé sabe que no tengo plaza?

Aquí discutimos si era un smell (señal de alarma de que algo estamos haciendo mal) el tener más de una prueba de aceptación para una historia. Personalmente creo que no, aunque sí es cierto que trato de que sea siempre una. En este caso, lo que sí observamos es que para poder implementar esta historia era necesario antes saber cómo distinguir si aún había plazas libres en la reunión o no, lo cuál sí que tiene un cierto tufillo porque se supone que las historias de usuario deberían ser “Independent”. Pero lo cierto es que no tengo una opinión bien formada al respecto, así que me gustaría saber cuál es la vuestra.

PomodoroExhaustedException

El tiempo se acabó y no nos dió tiempo ni de tener suficientes historias para ver cómo priorizar el backlog, ni de estimar las historias ni de ver cómo partiríamos esas historias de usuario en tareas. Sin embargo, creo que la mayoría quedamos muy satisfechos porque hicimos muchas reflexiones en voz alta, las contrastamos con más gente (algunos con mucha experiencia, como es el caso de Luis Fraile), y ése es uno de los grandes valores de estas reuniones: donde profesionales de diferentes orígenes, experiencias, tecnologías, motivaciones… nos juntamos para, en un ambiente generoso y seguro, donde sabemos que nadie nos va a cuestionar por saber más o menos, donde podemos equivocarnos y arriesgarnos sin miedo, podemos compartir nuestras dudas y ofrecer nuestras respuestas y reflexiones.

Retrospectiva

Aunque quede un poco off-topic con el título del artículo, no quería olvidarme de la retrospectiva. Los asistentes más habituales a las reuniones de sabemos que no somos un grupo muy disciplinado, lo que se evidencia en nuestro poco respeto a una de las prácticas ágiles más importantes: la retrospectiva. Así que conseguir acordarnos de que debíamos hacer la retrospectiva es remarcable en sí mismo. 🙂

Esta vez me apetecía mucho ver a otro hacer una retrospectiva, éramos un grupo muy numeroso y seguro que podría haber aprendido algo, aunque solo sea por estar en el rol de asistente. Ofrecí el rotulador pero no hubo suerte. Así que hice lo que hago últimamente (mi pequeña receta siempre en constante actualización):

1) recordé a todos el objetivo que perseguimos con la retrospectiva: la mejora continua

2) una carita sonriente: para agrupar todo aquello que nos gusta, que nos hace sentirnos cómodos y que queremos seguir repitiendo

3) una carita triste: para agrupar todo aquello que no nos gusta, que nos molesta y que queremos dejar de hacer o que queremos impedir que siga ocurriendo

4) una bombilla: para agrupar todas aquellas ideas que se nos ocurran que nos gustaría probar para mejorar cualquier aspecto de lo que hacemos

5) una flor: para agrupar los nombres de aquellos a los que queremos agradecer algo en especial (esto último lo aprehendí de una visita que nos hizo Angel Medinilla hace ya mucho tiempo al grupo de )

El resultado de la media hora fue el que veis en la foto (aunque sea de mala calidad). Cierto es que a esa hora (las 21:30 aprox) ya estábamos bastante cansados y muchos ya con más ganas de ir a por unas cervezas y a ver si veían la segunda parte del Madrid que otra cosa. 🙂

Más comentarios sobre la retrospectiva en este hilo de la lista de Agile-Spain. (DISCLAIMER: No me hago responsable del contenido de ese hilo) 😀

Y para terminar una muy amena charla en un irlandés con varios espartanos del proyecto de la muerte y un polaco en bicicleta. 🙂

Muchas gracias a Nayade y en particular a Manuel Castro, que siempre ofrece el espacio y parece que siempre rechazamos su oferta. A ver si ahora que ya hay menos peso ágil en IPSA podemos retomar la vieja idea de ir rotando por diferentes localizaciones de Madrid y así favorecer el que, en algún momento que se me antoja no muy lejano, haya más de un grupo agilista en Madrid. Algo como un Madrid Sur y Madrid Norte o Madrid A-6 y Madrid A-4 o Madrid Vallecas y Madrid Chamberí (por dar ideas). 😉

ACTUALIZACIÓN:

Lo siento, olvidé comentar dos cosas:

  1. La discusión sobre si identificar al “miembro de madriágil” era una historia de usuario prioritaria. Fue quedando un poco postergada porque no vimos que fuera realmente algo que mereciera nuestra atención aún. Pero tenía pinta de ser una de esas historias de usuario “técnicas” muy socorridas para superar nuestro “horror vacui”. 🙂
  2. Surgió en la retrospectiva una idea muy interesante que no quería que se perdiera. Creo que fue Rafa de Castro, pero puedo equivocarme fácilmente en la atribución, quien comentó que se podrían hacer UserStoryKatas (y como consecuencia también UserStoryDojos). La idea sería algo así como ejercicios para practicar la escritura de historias de usuario. Es decir, practicar no sólo la escritura de la tarjeta sino, sobre todo, la conversación y la confirmación. (Quizás enlace esto también con el concepto que Gojko Adzic promueve de las sesiones de especificación)
  • Me ha gustado este post. Para mi una de las cosas más complejas es hacer las historias de usuario ¡Siempre termino con épicas! Claramente es uno de los puntos que tengo que mejorar.
    Me apunto lo del CCC y el INVEST.
    Salud !

  • Buenas! 😀

    Muy interesante todo lo que has escrito 😀 Parece que la reunión moló bastante.

    Al grano 😛

    Creo que en la historia:
    Como miembro de madriágil
    Necesito apuntarme a un evento
    Para reservar mi plaza

    Estoy más con los que ven el valor en la organización:
    Como organizador de una reunión de madriágil
    Necesito saber cuanta gente va a venir
    Para no tener problemas de espacio

    Realmente poco valor obtenemos nosotros apuntándonos, nadie se queda fuera nunca 😛
    ¿Por qué quiero que se apunte la gente? Para saber cuantos vienen ¿Por qué quiero saber cuantos vienen? Para saber donde reservar el local para la reunión
    Por eso tuvisteis problemas para decidir sobre la notificación de reserva. Nunca lo habías pensado porque no es importante, lo importante es el sitio 😛
    Dicho esto, la última historia creo que no me aporta ningún valor a mi como miembro de madriagil :S No creo que necesite confirmación para asistir a ninguna reunión (de momento). Creo que perdisteis un poco el foco (critica sin malicia ninguna, es solo que no lo veo en la retro y creo que es cierto).
    La siguiente historia para mi habría sido “Quiero tener una lista de locales disponibles”, que creo que es mucho más importante.

    Está claro que no es nada fácil “descubrir” las historias de usuario. Cualquier despiste equivoca el camino (¿cuantas veces me habrá pasado a mi sin darme cuenta?)

    Abrazos ágiles 😀 (6 segundos)

  • Alberto, yo como product owner le di un poco de vuelta al asunto, no buscaba una gestión real de madriagil, porque no quería que fueran ellos los que decidieran sobre el qué. Por eso dije que para mi era obligatorio apuntarse o no entraban… Por lo que sí que tenía sentido la última historia (o al menos a mi me lo parece)

    Buen post de “resumen” (a un ladrillo así se le puede llamar resumen???) 😉

    • Ups, entonces nada 😀 Ignorad mi comentario 😀

  • AMEN al ladrillo sobre Historias de Usuario. Me lo leeré detenidamente para refrescar conceptos.

    Mis dos centavos para ti y Jesús: una buena manera de gestionar los eventos sin taladrar en una lista de correo que es muy 1.0, es MeetUp: http://www.meetup.com/

    • jmbeas

      Sí, David, nos han recomendado muchas veces MeetUp y lo conocemos por encima, aunque no como organizadores porque tienen cuota (12 $/mes) y nunca nadie que conozca ha estado dispuesto a romper esa barrera de pagar para los demás más allá de ceder un hosting o algo así. La verdad es que quizás ahí la Asociación Agile-Spain podría hacer algo.

  • Muy interesante el post.
    No vais a montar nada por Mallorca o alrededores?
    Muchas gracias por evangelizar!

    • jmbeas

      Muchas gracias, Sebas. Si te refieres a agilismo.es, ahora mismo no tenemos nada programado. Si te refieres a Agile-Spain, creo que lo más pronto que hay seguro algo será la XP2011, en Madrid. Pero como iniciativas de otras comunidades, asociaciones, entidades, individualidades… se están organizando a cada dos por tres. Te recomiendo echar un vistazo a WalkingThePath porque ahí @plagelao está tratando de llevar al día todos los eventos orientados al desarrollo de software que se realizan en España. Es cierto que la insularidad de Baleares puede ser un inconveniente, pero si puedes acercarte a algo de lo que se hace en Barcelona o Valencia (que quizás es de lo que te pilla más cerca) y luego aplicas la misma fórmula sencilla para arrancar vuestras propias reuniones. No hay mucho más que hacer que provocar el cambio a tu alrededor para que las cosas vayan cambiando.

  • Gran post. Se nota que te lo has tenido que currar en el “proyecto de la muerte”.

    • jmbeas

      Vaya, Alberto. Pues no creas. Hemos escrito muy pocas historias de usuario (como es debido) en el proyecto de la muerte. Ahora estamos empezando a acercarnos. El cambio cultural y técnico era tan dramático y, sobre todo, el proyecto estaba ya tan avanzado, que no me pareció adecuado ser demasiado riguroso en estas cosas.

  • Creo que habéis tenido un montón de problemas porque habéis intentado formalizar los requisitos/historias de usuario antes de haber tenido reuniones informales para encuadrar el trabajo.

    Habéis tratado de pasar de desconocer el problema a formalizarlo en términos técnicos. Lo mejor es pasar por una etapa intermedia en la que no se genera ningún “entregable” técnico pero se comprende el problema.

    Posteriormente, partiendo de esa comprensión, se pueden formalizar las historias de usuario, requisitos o cualquier otra cosa, según las prácticas de cada uno.

    Está claro que no se puede hacer todo en una sola reunión de #madriagil (no hay tiempo), así que para el tiempo disponible creo que le habéis sacado bastante provecho 🙂

    • jmbeas

      Justo, Abel. La idea de esa mini-incepción era justamente para hacer hincapié en lo que tú tan bien has resaltado.

      Por cierto, a ver si hacemos un Tetuán Agil o lo que sea y podemos charlar con más “ancho de banda”. 🙂

  • Para las futuras sesiones hay que asumir que el cliente sabe que producto quiere (ya hizo la inception) y no cuestionar la viabilidad del proyecto del cliente.

    Era yo quién propuso la idea de user story dojo. Luis Fraile empezó a liarme para que organizara un tal dojo 🙂 A ver si organizamos el dojo; tengo incluso una idea del producto en la cabeza 🙂

    • jmbeas

      Me encanta, Marcin, porque vamos (agilismo.es) a proponer para la #XGN (una LanParty que se organiza desde hace muchos años en Galicia) justamente este taller. Ya os contaremos qué tal.

  • francho

    Muy bueno el post (y la reunión por lo que leo)

    Me gusta mucho lo de las UserStoryKatas

  • Muy buen post. Ha logrado romper mi tendencia de leer bien el principio y luego “en diagonal”, lo he leído completo. Muy interesante.
    La idea de las UserStoryKatas y UserStoryDojos es buenísima.

  • Ops, acabo de ver que es del 26 de February, 2011 😛

    • Gracias. Sí, fue una reunión de hace casi dos años y justamente me trajo a la memoria la idea de las UserStoryKatas. A ver si puedo trabajar un poco sobre la idea y las ponemos en marcha. Aportaciones bienvenidas. 🙂

  • JunaJo

    Pues sí, es un buen articulo (y buenas referencias)

    JuanJo