Una historia de usuario describe una característica funcional de un sistema que resulta de interés tanto para el usuario como para el cliente que lo encarga.

Posiblemente sea Ron Jeffries ─uno de los padres de la Programación Extrema que participó junto a Kent Beck en el proyecto C3 de Chrysler─ quien mejor ha resumido [1][2] cómo crear y trabajar con historias. Jeffries divide el proceso en tres fases:

1. Anotación. Se apunta cada cosa que los usuarios quieran que haga el sistema.
2. Conversación. Se produce un diálogo entre el usuario y el ingeniero para extraer y concretar los detalles de la historia.
3. Confirmación. Se busca la manera de demostrar que el sistema lleva a cabo la historia correctamente, enumerando los aspectos a comprobar mediante pruebas de aceptación.

Las historias se suelen escribir a mano en tarjetas de papel. Aunque la tarjeta es la parte más visible de una historia, porque recoge su descripción, no es la más importante. Los detalles surgidos de las conversaciones con los usuarios, y confirmados mediante las pruebas, son los que realmente narran la historia. Podría decirse que en la tarjeta figura el «requisito», mientras que de las conversaciones se extrae su documentación, la cual se confirma con las pruebas.

El usuario

Las historias son descripciones funcionales del sistema llevadas a cabo por el usuario, pero quién es el usuario. La primera respuesta, obvia aunque válida, es la persona que utilizará el sistema. Sin embargo, ignorar que todas las personas no tienen los mismos objetivos, perfiles ni niveles de experiencia es un error.

Parece evidente que, en el caso de un cajero automático, quien acude a sacar dinero tiene objetivos muy diferentes respecto a un técnico del servicio de asistencia. Ambos son usuarios, pero emplearán el sistema de forma muy distinta. Incluso dentro del mismo tipo de usuario ─como la persona que utiliza los servicios del cajero─ se puede llegar a considerar si se debe distinguir como usuario de distinto tipo a una persona mayor o a un invidente.

Así las cosas, lo más correcto es hablar de roles de usuario en lugar de simplemente de usuarios. Un rol es una colección de atributos que caracterizan a un grupo de usuarios que interactúan con el sistema.

La identificación de los distintos roles tiene como meta asegurar que se van a cubrir las necesidades de todas las partes interesadas en el sistema para que éstas queden plenamente satisfechas con el resultado. Obviar esta tarea puede conducir a crear un sistema pensado para personas con perfiles muy concretos dejando fuera a otras. Dicho de otro modo, podría dejarse fuera parte de la funcionalidad del sistema.

Los roles de usuario suelen estar ligados a persona, no a máquinas. No obstante, si añadir un rol vinculado a una máquina puede ayudar a comprender mejor qué debe hacer el sistema, no hay mayor problema en hacerlo.

Anotación

El equipo encargado de anotar las historias no es el equipo técnico ─los ingenieros de software─ sino el equipo del cliente. En principio, nadie mejor que él para describir el comportamiento del sistema y garantizar que se usará su jerga ─el vocabulario del domino─ y no un lenguaje técnico.

Sin embargo, dado que es bien sabido que a los usuarios les cuesta explicar sus necesidades reales, el equipo del cliente no puede estar formado únicamente por los usuarios. Deben acompañarles el gestor del producto, que además se encargará de priorizar las historias en función de su valor, y ─sobre todo─ ingenieros especializados en pruebas y diseñadores de interfaces de usuario.

Es fácil de adivinar que trabajar con historias exige una implicación total del cliente. Nada de ocuparse de los requisitos al principio y pasar las pruebas de aceptación al final. Si hay desentendimiento en algunas fases del proyecto, no se podrá trabajar con historias.

Identificación de historias

Identificar las historias necesarias para realizar el proyecto es una tarea a ir realizando a lo largo del mismo. Sin embargo, durante las primeras iteraciones debe realizarse un esfuerzo activo para identificar el mayor número posible. Esto no implica que debamos entrar en sus detalles, sino simplemente anotarlas.

Esta tarea resulta mucho más eficaz si se cuenta con todos los tipos de usuarios del sistema, pero como algo así casi nunca es viable, deberán incluirse representantes de éstos en el equipo.

La identificación del conjunto de historias iniciales también puede ser útil para hacernos una idea del tamaño de la aplicación y, por tanto, del coste del proyecto en números redondos.

A medida que el proyecto avance, es posible que haya que dividir algunas historias en otras más pequeñas, combinarlas y, es más que probable, que aparezcan historias nuevas una vez que la primera versión operativa del sistema llegue a los usuarios.

Se suelen celebrar reuniones o entrevistas con miembros del equipo del cliente para identificar las historias iniciales y, durante el transcurso del proyecto, se recurre también a métodos adicionales como los cuestionarios o la observación de los usuarios.

Reuniones

Un medio bastante eficaz para identificar historias es un reunión que congregue a miembros del equipo técnico y del cliente, así como cualquier otra parte interesada en el sistema. El objetivo de estas reuniones, que deberían celebrarse antes de iniciar la primera de las iteraciones que conformen una entrega, es obtener el mayor número de historias posible; se busca la cantidad por encima de la calidad. Posteriormente, todas las historias halladas se someterán a revisión.

Entrevistas

Las entrevistas también son un gran método para identificar historias, pero hay que saber hacerlas. Preguntas del tipo «qué quiere usted que haga el sistema» no conducirán a ninguna parte. Si no sabemos hacer las preguntas correctas y ayudar al usuario a expresarse, no debe resultarnos extraño que haya proyectos donde terminemos haciendo lo que el cliente pidió, pero no aquello que realmente quería.

Las preguntas a realizar no pueden ser capciosas ni tendenciosas.

Una pregunta como «¿quiere la máxima seguridad posible en los cajeros?», conducirá irremediablemente a un simple sí por parte del entrevistado. Este tipo de cuestiones no proporcionan ningún grado de detalle sobre las implicaciones de dotar a un cajero automático con las máximas medidas de seguridad. Reformulándola como «¿es necesario dotar al cajero con la máxima seguridad pese a que esto implique un mayor coste para el proyecto?» abrirá el debate. Entonces será el usuario (o el cliente) quien empiece a responder a la gallega y empiece a fluir el diálogo: cuáles son los diferentes niveles de seguridad, qué diferencias de coste hay, etc.

Por otro lado, preguntas del tipo «¿en cuántos milisegundos debe responder el ordenador central a una petición del cajero?» imponen al usuario que el alto rendimiento es un requisito necesario. Sería deseable replantear la consulta como: «qué tiempo de espera es aceptable para recibir la respuesta del ordenador central» o «qué importancia tiene el tiempo de respuesta del ordenador central» para abrir el abanico de respuestas y dar lugar a la formulación de preguntas por parte del interlocutor.

A medida que avance la entrevista, podremos ir profundizando y realizando cuestiones más específicas, pero no debemos olvidar que las preguntas iniciales siempre deben originar el diálogo entre las partes.

Cuestionarios

Los cuestionarios son útiles para conocer el parecer de una gran número de personas. Identificar las historia iniciales mediante este método no es nada eficaz, pero puedo serlo una vez que se ha desplegado el sistema y los usuarios han empezado a usarlo, así tenga una funcionalidad mínima.

Las preguntas típicas que aparecen en cuestionarios de este tipo son relativas a la frecuencia con la que se usan funciones concretas del sistema (mucho, poco o nada), si son cómodas de usar y cómo mejorarlas.

Al usuario le resulta más fácil responder si cada pregunta viene con cuatro o cinco respuestas prefijadas. Sin embargo, haciéndolo así estaremos acotando las posibles respuestas y podemos caer en el error de, por ejemplo, dar como opción las cinco funciones que nosotros consideremos que más deben estar usándose, cuando no tiene por qué ser cierto. Es preferible dar libertad de expresión al usuario, aunque cueste más trabajo revisar los cuestionarios de cara a extraer conclusiones.

Observación

Nada mejor que observar a los usuarios cómo usan el sistema para obtener información sobre mejoras del mismo. Desgraciadamente, pocas veces tenemos la oportunidad de hacerlo, pero si ésta se presenta ─así sea sólo una vez durante todo el proyecto─ aprovéchela al máximo.

Registro de historias

Dado que las historias las anota el equipo del cliente, éste puede limitarse a escribir simplemente una característica funcional del sistema.

El cajero permitirá realizar transferencias.

Cuando un ingeniero tome una tarjeta como ésta de cara a iniciar una conversación con quien la escribió, se le pueden presentar dos problemas: que tenga dificultades para encontrar a la persona correcta y que semejante descripción, donde no figura el quién ni el porqué, no dé pie a iniciar una buena conversación.

La empresa Connextra presentó en 2001 un formato para articular la descripción de una historia mediante la cual evitaron que sus empleados de ventas y mercadotecnia ─aquellos que escribían la mayoría de las historias─ se limitarán a anotar características funcionales.

Como [rol de usuario]
Quiero [hacer algo]
Para poder [conseguir algún beneficio]

Esta plantilla fuerza a pensar sobre quién, qué y por qué. Tres aspectos que puede ser un gran punto de partida para iniciar una conversación.

Sin embargo, forzar a todo un equipo a usar esta plantilla puede llegar a ser contraproducente porque hay ideas que no encajan en ella como, por ejemplo, contar historias sobre requisitos de seguridad. Ahora bien, viendo lo que se cuenta por la red parece que si una historia no sigue este formato no es una historia (!). Hay quien incluso las presenta carentes de título. ¿Se imagina trabajar con historias que para citarlas tuviera que pronunciar toda esa frase?

Lo importante de una historia no es lo que se escribe en una tarjeta, sino lo que se aprende al contar la historia. Las plantillas pueden ayudarnos a aprender a anotar las historias, pero no deberíamos preocuparnos lo más mínimo si hay veces que no encajan. Una mejor plantilla [3] que la de Connextra, aunque basada en ella, consiste en escribir un título y escribir quién, qué y por qué. Las respuestas se pueden escribir bajo epígrafes distintos o uniéndolas en un pequeño párrafo.

Realizar una transferencia
Quién: Usuario del cajero.
Qué: Realizar una transferencia de dinero desde su cuenta a otra cuenta nacional.
Por qué: Liquidar un pago.

En cualquier caso, las respuestas a las tres preguntas se completarán con los detalles que surjan durante la conversación.

Realizar una transferencia
El usuario del cajero realiza una transferencia de dinero desde su cuenta a otra cuenta nacional para liquidar un pago.

La razón por la cual un usuario se acerca a un cajero a realizar una transferencia puede ser muy dispar. Siendo así, en el epígrafe «por qué» se está asumiendo algo que no tiene por qué ser cierto. Lo mejor sería simplemente eliminarlo, pero si he decidido dejarlo escrito es para mostrarle un ejemplo del «poder» de las conversaciones incluso con epígrafes obvios o tendenciosos.

Imagínese que durante la conversación surge el debate sobre qué podríamos hacer para ayudar al usuario a realizar el pago si el cajero tiene algún problema. Quizás la máquina podría recomendarle hacerlo vía web o, mejor aún, indicarle la dirección de los cajeros más próximos. Ambos casos darían lugar a nuevas historias surgidas de un epígrafe que, a priori, parecía de escaso valor.

Con una tarjeta con un título y tres epígrafes parece improbable que el equipo técnico y otros cargos tengan información suficiente para realizar su trabajo. Son muchas las personas que esperan conseguir información de una tarjeta:

• El jefe de producto buscará quién puede comprar el producto que se está desarrollando y cómo afectará a la rentabilidad de la empresa.
• Un analista del negocio buscará las reglas de negocio presentes en cada historia.
• Un ingeniero de software buscará diseñar y programar la historia de un modo eficaz.
• Un ingeniero de pruebas buscará elaborar un buen plan de pruebas analizando cómo puede fallar el software.
• Un diseñador de interfaces de usuario buscará quién va a usar el software, por qué y cómo para diseñar una interfaz adecuada.
• Un jefe de proyecto buscará como coordinar a todo el equipo y prestará atención a las dependencias entre historias, los plazos, el estado de las historias, etc.

Parece que con tanta gente vaya a ser necesario usar tarjetas tamaño sábana para dar cabida a toda la información que buscan, pero es que la mayor parte de la información de las historias no está en las tarjetas. Esto no funciona así. Una tarjeta contiene un mínimo de información relevante que conduce al resto, puede compararse con la entrada del índice de un libro. La entrada es una referencia que señala la página dónde está el grueso de la información. Con las tarjetas sucede lo mismo.

Las tarjetas deben registrarse en alguna herramienta de seguimiento y utilizarla para asociarle los documentos surgidos de las conversaciones. Por ejemplo, al tratar con un usuario sobre los detalles de una historia, lo más normal es que vayamos anotando los detalles ─bien con texto, bien con diagramas─ en una hoja o, si hay más de dos personas implicadas, mejor en un rotafolio o papelógrafo. Al terminar, podemos hacer fotos a toda esa información y almacenarlas en la herramienta vinculadas a la historia. Así, cuando cualquier miembro del equipo no encuentre la información que busca en la tarjeta, podrá usar a la herramienta para acceder a todos los documentos de la historia.

Hay que ser muy cuidadosos a la hora de anotar los detalles de las historias si vamos a terminar haciéndoles fotos. Descifrar la caligrafía de algunas personas puede ser más difícil que romper un algoritmo de cifrado e interpretar diagramas inventados al vuelo mientras hablaban con el usuario, toda una odisea. Hay que cuidar la letra y la ortografía y, si se usan diagramas, debe usarse UML, que para eso es un lenguaje visual universal. Si, pese a todo, las fotos son ininteligibles, merece la pena dedicar media hora en pasar la información en limpio porque terminaremos ahorrando muchas veces ese tiempo al resto del equipo. De lo contrario, prepárese para explicar a todo el mundo, pero de uno en uno, que quiere decir esa expresión o que pretendía explicar con ese diagrama.

Aunque la mayor parte de la información quede fuera de la tarjeta, ésta ─como ya se ha expuesto─ debería tener al menos un título y una descripción.

• Título. Una frase fácil de emplear como referencia de la historia. Posiblemente, ésta sea la parte más importante de la tarjeta. Si es necesario cambiarla varias veces para dejarlo más claro, no dude en hacerlo.
• Descripción. Un breve párrafo o tres epígrafes (quién, qué y por qué) que describan quién la usará, con qué objetivo y qué beneficio obtendrá de la historia.

Según avancen las conversaciones, se puede ir añadiendo más información:

• Número de historia. Un identificador de la historia que se usará en el sistema de seguimiento para acceder a toda la información. Jamás haga referencia a las historias en las conversaciones por su número, use el título.
• Estimación. Una predicción de cuánto se tardará en completar la historia o su coste.
• Valor. La importancia de la historia para el usuario: alto, medio o bajo.
• Métricas. Métricas de calidad obtenidas una vez se ha terminado la historia.
• Dependencias. Otras historias que depende de ésta o de qué historias depende ésta.
• Estado. Para qué entrega está previsto terminar la historia. Si es la entrega en curso, se puede indicar si se ha empezado a desarrollar o está terminada.
• Fechas. Fecha de creación de la historia, fecha inicial de desarrollo y fecha de finalización.

Es posible añadir más información, pero el espacio es limitado y es bueno que así sea. Al fin y al cabo la tarjeta no es más que una referencia rápida para el equipo. Recuerde que los detalles de la historia los encontrará en la herramienta donde se registren.

Referencias

[1] Ron Jeffries. Essential XP: Card, Conversation, Confirmation. 2001. url: https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/

[2] Ron Jeffries, Ann Anderson y Chet Hendrickson. Extreme Programming Installed. Addison Wesley, 2000.

[3] Jeff Patton y Peter Economy. User Story Mapping. O’Reilly, 2014.

Fotografía de la entrada de Bonneval Sebastien en Unsplash