Última reunión: historias de usuario

Ayer, estuve en mi primera reunión de las Agile-Girls, en la que Laura Morillo-Velarde (@laura_morillo) nos deleitó con un interesante taller de historias de usuario.

Primero, nos hizo ver la necesidad de las mismas, con los problemas de ambigüedad que puede resolver, explicando las tres C’s: Card, Conversation y Confirmation (Tarjeta, Conversación y Confirmación). La historia de usuario tiene que seguir la siguiente plantilla: “As <type of user>, I want <to do something> so that <the reason>” (Como <tipo de usuario>, quiero <hacer algo> para/por <alguna razón>) y tiene que caber en una tarjeta. Es decir, lo primero que necesitamos es definir el tipo de usuario (usuario registrado, no registrado, administrador…) para el que esta nueva feature va a ser útil, la definición de esa feature y por qué será útil. Todo ello de forma exacta y acotada. Aquí es importante no entrar en el “cómo se va a hacer”. Es importante sólo “el qué”. Esto genera conversaciones o discusiones entre cliente y equipo para refinar esa historia de usuario y ver cómo se va a llevar a cabo. Y por último, confirmación, necesitamos alguna manera de comprobar que esa historia de usuario ha sido implementada correctamente.

Para ayudarnos a llevar estas tareas con éxito, disponemos de un mnemónico: INVEST. Vamos a verlo en detalle.

  • Independent (Independiente): todas las historias de usuario deberían ser independientes en la medida de lo posible.
  • Negotiable (Negociable): los requisitos cambian en el tiempo y, como consecuencia, las historias de usuario también. Esto está muy unido a la conversación que comentábamos previamente en las tres C’s.
  • Valuable (Valioso): una nueva historia de usuario debe dar valor a la aplicación para algún tipo de usuario. Esto está relacionado con el porqué de la plantilla.
  • Estimable: deberías ser capaz de estimar el coste, el tiempo y las tareas que va a necesitar. Cuanto más grande sea la feature, menos estimable o más difícil de estimar será. Y esto nos lleva a la siguiente sigla.
  • Small (Pequeño): toda historia de usuario debería ser lo suficientemente pequeña como para poder planificar, dividir en tareas o priorizar con un nivel de incertidumbre adecuado.
  • Testable: si no se puede comprobar si una historia de usuario está hecha o no, no es correcta. Esto está unido a la confirmación de las tres C’s.

Una vez escrita la historia de usuario, se escriben distintos escenarios que definan el comportamiento del sistema ante ciertas acciones por parte del usuario. En estos, seguimos la siguiente dinámica: teniendo las cosas que asumimos que están ahí ya sin importarnos cómo se ha llegado a esa situación (por arte de magia), el usuario hace algo para interactuar con el sistema. Entonces el sistema reacciona de algún tipo que, preferiblemente, el usuario vea.

Una vez expuesta toda esta teoría y como se entiende mejor haciendo que viendo, tuvimos que practicar lo aprendido con un ejemplo: crear la historia de usuario para timetable privado de Twitter. En éste, pudimos ver la problemática que podría tener y cómo ante la misma feature común, cada una intentábamos pasarlo a historia de usuario con una idea totalmente distinta en la cabeza. Lo que ciertamente provocaba conversación sobre cómo definirlo y cómo reacciona el sistema en los distintos escenarios.

Y para finalizar la reunión, como no podía ser de otra manera, las cervezas de rigor.

2 comentarios para “Última reunión: historias de usuario”

Deja un comentario