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.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024