Reunión en Nayade a la que llegué tarde, y menos mal que llegué, a causa de un amigo indómito al que le voy a echar una mano con su dominio, su web y todas aquellas cosas que le ayuden a salir del agujero en donde está metido.
Primera sorpresa… que montón de gente!!
Yo que pensaba que íbamos a ser cuatro gatos, me encuentro con la sala petada de peña, todos con unas ganas de aprender tremendas. JMB ya estaba de pié haciendo de jefe de proyecto (mira que le gusta) y había muchas caras nuevas y caras de gente ya largamente conocidas. Quiero señalar a Luís Fraile que demostró de largo porqué es un MVP de Microsoft y que no solamente sabe un rato, si no que es un muy buen comunicador.
Mr. Ballano tomo el rol de cliente e hicimos, siguiendo la batuta de JMB, una primera puesta en común de lo que es una historia de usuario. A continuación, siguiendo los dictados del “limonchelo” nos embarcamos en tres pomodoros para ir construyendo historias de usuario según las indicaciones del cliente. Lo cual resulto muy, muy fructífero al revisar cada paso desde múltiples ángulos y experiencias. Y no dudar en detenernos hasta quedar todos conforme del porqué y del cómo de las historias que iban surgiendo. Finalmente completamos dos y casi tres historias, en un interesante diálogo constante. Y que condenso en las siguientes conclusiones:
Historias de usuario
- Las reuniones iniciales con el cliente han de ser con pocas personas.
- El uso de las palabras en inglés no tiene sentido si la conversación se hace en castellano. Es decir utilizar As a role, ability, benefit queda muy “guay”. pero al final lo que usamos es “Cómo”, “quiero” y “para”. Vamos, mi sensación de que hay mucho esnobismo se ha reforzado. Teniendo en cuenta que soy bastante “taliban” del uso del castellano en el software (toma contradicción)
- El glosario del dominio lo debe construir el cliente y nosotros lo debemos seguir de forma lo más natural posible para que no halla errores de apreciación como entre las palabras “ver” o “consultar” un resultado. Lo importante es lo que signifique para el cliente y nosotros asumir ese significado como lenguaje del dominio.
- Tengo que tener más paciencia. Acostumbradísimo como estoy a tratar con clientes de todos colores y sabores, con cuatro preguntas y media obtuve la misma información que se tardo media hora en alcanzar más tarde. Y me apresuré y “saque los pies fuera del tiesto”. Lo bueno es que me di cuenta de mi impaciencia en ese momento y no volví a salirme del timming.
- Al principio del dialogo con el cliente sobre lo que quiere, lo que se obtienen son historias épicas. Osea, aquellas que no tienes claro el cómo se van a desarrollar. Y de las cuales van a salir historias de usuario concretas.
- Los roles van emergiendo en la propia construcción de las historias. Si bien hay que tener unos roles “épicos” al principio, siguiendo el principio de tomar las decisiones en el último momento, hay que esperar que dichos roles se definan a sí mismos según las historias vayan adquiriendo más precisión. Aquí JMB nos hizo gala de lo que ocurre en un equipo cuando un miembro sale “por peteneras”… que el resto del equipo pasa de el (eso sí, con mucho cariño). Y se entra en un dialogo de conflicto con el cliente. Trampa en la que hay que tener mucho cuidado en no caer cuando piensas que sabes más que tu cliente sobre su producto y que, además, se lo tienes que demostrar.
- Es importante la primera premisa “Como”. Es decir el rol va a marcar el resto de la historia de usuario ya que puede no ser la misma dependiendo de quien la realice. Yo caí en la confusión de cambiar el rol de acuerdo a la premisa en que estábamos y me monté un lio yo solo que de forma muy satisfactoria el resto de los asistentes (los que hablaban claro) me ayudaron a clarificar.
- Mi gran descubrimiento de la reunión: “Confirmación”. O la prueba de validación. A primera vista es algo tan simple como que el cliente diga cuales son las condiciones que se han de cumplir para que se de por realizada la historia. Pero, es curioso, con esta premisa hace emerger mucha más información de la esperada. Primeramente, al ser dependiente del rol, conduce al cliente a ponerse en la situación de dicho rol y a marcar las diferencias con otros roles -emergen las características propias del rol-. A continuación, las pruebas de aceptación inducen a encontrar nuevas historias de usuario o requisitos, ya que es ver el cubo desde otro punto de vista. Y, como en el caso de la tercera historia de usuario, si existen aceptaciones dependientes o condicionales, te permite “oler” que van a surgir aún más historias de usuario o requerimientos que en las premisas anteriores era mucho más difícil de obtener.
Mi retrospectiva (+)
- La idea de Ballano ha sido muy buena.
- Me he quedado con ganas de más.
- El nivel de los participantes era alto. Quien no aportaba experiencia, aportaba conocimientos. Pero no hubo grandes “salidas de tiesto”.
- He aprendido mucho. Ha sido una buena reunión.
Mi retrospectiva (-)
- El facilitador debió de ser Ballano. JMB, con toda su buena intención, se convirtió en un proxy de ideas y decidía cual y de qué manera se plasmaban. Dirigió en demasía, para mi gusto, la actividad.
- Hubiera querido que nos ajustáramos al guion de la reunión y hacer grupos de trabajo. Para sentarnos en circulo y quitarnos la palabra el uno al otro (menos los que levantaban la mano) podíamos irnos a tomar cervecitas. Suena estricto, pero es que en dos horas hubiéramos echo más que dos historias de usuario. Y centrar un poquito más las disertaciones, que al final nos vamos por los cerros de Úbeda.
- La retrospectiva fue terrible. No se hablo por turnos, por lo cual hablamos los que hablamos siempre. Por lo cual muchos no hicieron retrospectiva. JMB saco finalmente el látigo y obvió todo aquello que a sus oídos no le parecía correcto o con suficiente interés. Por lo cual en el tablero se leía lo que el pensaba y no lo que el grupo decía. Por lo cual el grupo no se sintió identificado con la retrospectiva y es como si no la hubiéramos echo. Y así se levantó la reunión, sin ninguna conclusión más que “esto se ha acabado. Vamos que nos vamos”.
Mi retrospectiva (Λ)
- Hacer otra reunión o incluso una User History Dojo.
- El cliente debe ser el facilitador. Podría ser una pareja. Y debe ser mucho más contundente.
- Quitarle el lápiz a JMB.
- Buscar un sitio más grande que Nayade. Que petamos su sala.
- Incentivar que la gente callada hable más.
- Un token para el turno de palabra. Y así evitar un poquito que los de siempre estemos rajando todo el rato y no caer en corrillos. Que, aunque poco, caímos todos.
Y ahora, este viernes, nos vemos en alicante!!
No hay comentarios:
Publicar un comentario