Taller de historias de usuario

Artículo actualizado en mayo 2022

La semana pasada asistí a una sesión de formación organizada e impartida por José Manuel Beas en Madrid, que llevaba por título Taller de Historias de Usuario. La motivación para asistir me viene de lejos ya que la convivencia con developers como Dani Latorre en el Estudio hace que la terminología que los agilistas utilizan en su trabajo, y algún que otro café que nos hemos tomado hablando del tema, hace que la curiosidad despierte.

Así las cosas, el taller impartido por José Manuel en las instalaciones de Deiser fue para mi un colofón más que interesante en ese proceso de acercamiento a terrenos que intuía interesantes.

En este post os quiero compartir algunas de las notas que tomé en la sesión.

Empezamos el taller viendo una ficha de usuario simple con la que José Manuel se presentó a si mismo a través de una ficha que tiene los siguientes elementos:

• Dibujo
• Nombre y descripción personal (ciudad, estado civil, profesión, etc).
• Tabla de motivaciones
• Tabla de objetivos
• Eslogan entrecomillado

En un primer momento pensé que era algo muy parecido a lo que conocemos por aquí como panel de personas. Y nada más cerca. Estábamos construyendo unos pequeños paneles de personas, si bien la obtención de información para los mismos la proporcionábamos nosotros mismos. Tenía su sentido pues cada cual era el origen y el final de la información.

Paneles de personas realizados en el transcurso del taller

Posteriormente hicimos un ejercicio por parejas en el que uno entrevistaba a otro para construir una ficha simple como la que nos había enseñado José Manuel. Posteriormente hicimos una presentación en público de la fichas. Yo presenté a la que todo el día fue mi compañera, Cristina Cirera.

José Manuel nos resumió el ejercicio que hicimos diciendo que habíamos puesto en práctica una técnica llamada Users Personas, haciendo referencia a la técnica que se usa en el mundo UX. También hizo referencia a que habíamos puesto en práctica la técnica de la entrevista.

Para comprobar en nuestras propias carnes cómo la transmisión de información desde el cliente hasta el equipo de desarrollo puede sufrir variaciones cuando hay demasiados interlocutores o documentación de por medio, hicimos un pequeño juego, muy ilustrativo, que me gustó mucho.

El juego se llamaba «¿en qué estoy pensando?»

Los participantes:

• 1 persona que hace de cliente. Su objetivo es que un equipo le haga algo.
• 1 analista. Su cometido es construir lo que le diga el cliente.
• 2 personas que hacen de resto del equipo. Ellos construirán lo que les diga el analista.

• El cliente coge una carta de un mazo y le explica, sin enseñárselo a nadie, algo relacionado con lo que hay en la carta que ha cogido. Pide que construyan algo con los requisitos que está dando.
• El analista, al tomar requisitos, le pregunta cosas y detalles al cliente para tratar de clarificar lo que desea.
• El cliente le va describiendo al analista lo que quiere que le construyan.
• Posteriormente, el analista, en 5 minutos, tiene que conseguir que los programadores construyan lo que quiere el cliente.

Esto es lo que entendió el analista al tomar los requisitos

Al final hemos visto cuál es el resultado de la construcción de lo que quería el cliente, ejecutado por el equipo a través de las indicaciones del analista.

Esto es lo que entendió el equipo al realizar la construcción

Posteriormente repetimos el juego, de forma que sea el cliente quien pida al equipo directamente lo que quiere, y éstos lo desarrollen. Tendrán un minuto para capturar requisitos y un minuto para producir lo que el cliente desea.

La conclusión es que en este segundo juego se avanzó más rápido al principio, aunque las partes de compleja construcción fueron mucho más complicadas y el resultado fue peor.

Es un juego bastante significativo.

Vimos también una serie de diferencias entre proyectos en función de cómo los abordamos:

• Predictivo: el cliente sabe lo que quiere y espera obtener una serie de funcionalidades en el final del proyecto.
• Adaptativo: poco a poco vamos pidiendo feedback al cliente y vamos construyendo, aunque por el camino puedan cambiar o matizarse los requisitos.

Y por otra parte, en la parte de desarrollo:

• Desarrollo interativo: tenemos claro lo que queremos y lo vamos construyendo por parcelas.
• Desarrollo incremental: no tenemos muy claro lo que queremos, pero empezamos a construir lo imprescindible para empezar a darle forma.

En las explicaciones de esta parte del taller la reflexión me llevó al concepto de sketching. En realidad trabajar haciendo uso de la técnica del sketching supone asumir una buena parte, por no decir toda, de la idea de desarrollo incremental.

Hablando de Historias de Usuario, José Manuel nos explicó que para entender esta técnica debemos comprender que se trata de las tres C:

• Card (se trata de una tarjeta de cartulina)
• Conversation (el origen del contenido de esa tarjeta debe estar en una previa conversación con el cliente)
• Confirmation (criterios de aceptación; es decir debe haber una serie de criterios que permitan concluir con que la historia de usuario se cumple)

Vimos un formato sencillo de Historias de Usuario:

• Título
• Como <rol>
• Quiero <funcionalidad>
• Para <beneficio>

Modelo de ficha de historia de usuario

Y esto es lo que más me importaba de la sesión de formación: qué son, cómo se construyen y cómo se utilizan las historias de usuario. El contexto que José Manuel nos preparó para el taller estaba completamente impregnado de agilismo, y es algo muy de agradecer para quienes veníamos de disciplinas colaterales.

Las Historias de Usuario son los vetustos catálogos de requisitos, pero de tamaño más pequeño. Aunque dejarlo ahí sería terriblemente injusto. Hay dos elementos diferenciales que hacen de las Historias de Usuario algo con mucho más sentido que los tradicionales catálogos de requisitos.

• Por una parte se trata de pequeñas porciones de requisitos, minimizados y atomizados en mínimas expresiones, lo cual permite que sean manejadas con más comodidad, libertad y sobre todo flexibilidad.
• El origen del contenido de las Historias de Usuario procede, o así debe ser, de la previa conversación con el cliente. Es decir, no se trata de criterios marcados por un equipo de desarrollo, ni tan siguiera por un equipo de negocio de un proveedor. Al contrario, debe ser el cliente el primer y único interlocutor que proporcione la materia prima con la que se aborde la construcción de las Historias de Usuario.

Estos dos importante matices hacen que esta técnica sea más que interesante para abordar la construcción, y diría que la conceptualización, de un proyecto digital.

Un modelo simple de Historia de Usuario

Por último, la utilización de las Historias de Usuario en User Story Maps es una estupenda combinación que permite, entre otras cosas, priorizar todo aquello que se proponga al usuario como experiencia en el sitio web, lo cual es algo muy a tener en cuenta, desde mi punto de vista, cuando estamos trabajando la experiencia de usuario de éste.

Empezando a trabajar un User Story Map

Hicimos más cosas en el Taller, pero tampoco es mi intención en este post desgranar minuto a minuto el contenido del mismo. José Manuel Beas ha compartido la presentación que utilizó, y siempre existe la posibilidad de realizar el taller, pues parece que habrá más ediciones.

En Torresburriel Estudio desarrollamos las capacidades técnicas de tu equipo en temas de usabilidad, experiencia de usuario y diseño de producto, a través de nuestros cursos online. Contacta con nosotros, y cuéntanos tus necesidades.