Revisando el concepto de historia de usuario y las “job stories”

Salvo error, la primera vez que te hablé en este blog de historias de usuario fue en 2011, en aquel la historia de usuario no es el “requisito” de las metodologías ágiles. Ha pasado tiempo desde entonces, y el concepto de historia de usuario, en mayor o menor medida, más para aquellos que hacen uso de modelos ágiles, ha sido bastante interiorizado por el sector.

Una historia de usuario describe funcionalidad, describe el valor que algo aportará al usuario y, sobre todo, debe fomentar la interacción. Las historias de usuario, hablan de un “qué”, que aporta valor, frente a un “como”.

Si recuerdas, el formato típico de una historia de usuario es:

As a [persona/role] I want to [action] so that [outcome/benefit].

Como comentaba Ron Jeffries, una historia no es sólo una descripción de una funcionalidad, normalmente en un post-it, una historia de usuario es, además:
– La conversación a la que conllevan, ya que son una herramienta para interactuar.
– El cómo se confirma su implementación, las pruebas y verificación de la misma.

Como todo en esta vida, o en este mundillo, con el tiempo evoluciona, madura, le crecen los seguidores… y los detractores.

Críticas

La mayoría de las críticas que hoy te puedes encontrar al concepto de historia de usuario suelen venir de alguno de los siguientes:
1 –  Del propio concepto y naturaleza de las historias, de olvidar, como te contaba antes, que su objetivo no es dejar necesidades por escrito, sino fomentar la interacción, colaboración, hablar, etc.


2 – Otro foco típico de críticas viene de el riesgo de olvidar centrarse en el verdadero beneficio, valor, que aportará la historia de usuario. Esto lo puedes ver muy claro cuando la gente deja fuera de la historia, esto es muy típico, el «para que / so that», como si fuera opcional, y esto deja fuera la ventaja que el usuario se obtendrá cuando se añada esa nueva funcionalidad.

3 – De la ambigüedad en las historias. Esta tercera crítica suele estar reñida con la primera, porque quien propone una solución lo hace metiendo más información en la misma.

Para la segunda y tercera crítica hay, principalmente, dos propuestas de mayor popularidad. Una es Gherkin y relacionados, como lenguaje propuesta para ampliar la descripción con ejemplos de uso de la historia. Otra es las job story.

Vamos con las job story, que de Gherkin ya tienes muchos post en el blog (como este, por ejemplo, Cucumber no es una herramienta de Testing, es un modelo de colaboración o este Entendiendo qué es BDD (Behavior-Driven Development) (I))

Job Story

Un concepto que ha ido tomando fuerza, como alternativa a las historias de usuario, son las “job stories”, que revisan ligeramente el formato tradicional de la historia de usuario.

Si recuerdas, el formato típico de una historia de usuario es:

As a [persona/role] I want to [action] so that [outcome/benefit].

Pues bien, el de una job story es:

When [users work/life context] I want to [motivation] so that [outcome/benefit].

Mediante la eliminación del «As a / Como” de la historia de usuario por «Cuando / when», se elimina cualquier tipo de prejuicio que el equipo pudiera tener con esa persona, usuario, etc. Y se busca ampliar el contexto y situación en la que se encuentra el usuario. Y así, también, se busca que el «Quiero / I want» se centre en la motivación, en lugar de en dar una solución prescriptiva.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *