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 #madriagil. 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 #madriagil 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 #madriagil)
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:
- 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”. 🙂
- 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)