Esta es la primera de dos partes en las que voy a describiros cómo deberíamos enfocar la definición de uno de los pilares en el mundo agile: Las historias de usuario (HU).

En esta primera parte os voy a ayudar a identificar los problemas más comunes que suelen surgir en los equipos cuando las historias de usuario no están bien definidas y cómo enunciar correctamente una buena HU.

En una segunda parte hablaremos sobre los principios y técnicas que nos harán mucho más fácil la labor de definir una buena historia de usuario y hará que podamos tener más probabilidad de éxito en la implantación de agile.

Estos posts lo que pretenden es introduciros en las buenas prácticas de agile, y en todo momento os pondré referencias a blogs, artículos, tutoriales, etc. que os ayuden a complementar las ideas planteadas aquí.

 

Principios de una buena historia de usuario

Podemos enunciar los principios de la definición de una historia de usuario como:

  1. Está enfocada a aportar valor al usuario
  2. Está bien definida y estructurada
  3. Es lo suficientemente auto explicativa para que exista el mínimo número de dudas funcionales y técnicas posibles

Problemas conocidos

Imaginaos que una HU NO cumple alguno o varios de los principios anteriores. Los casos más comunes que pueden darse son:

Caso A: La HU está mal explicada (bien el usuario no ha sabido explicarla, o se ha trasladado mal al backlog), lo que lleva a confusión sobre lo que el equipo de desarrollo tiene que hacer

 

  • La historia de usuario (o lo que se pretendía explicar) pide A pero se entrega B, lo cual no podemos hacer otra cosa que descartar nuestro desarrollo, ya que la deuda técnica de arreglarlo cuesta más esfuerzo que empezar a hacerlo de nuevo. Esto se agrava cuando no hay una comunicación o refinamiento de la historia durante su desarrollo (práctica a evitar, obviamente).
  • Es posible que durante el desarrollo nos encontremos dificultades técnicas que podríamos haber abordado antes, lo cual provoca retrasos en la entrega (y en el proyecto), y cambios en la estimación de la historia.

Implicaciones:

  • La historia de usuario (o lo que se pretendía explicar) pide A pero se entrega B, lo cual no podemos hacer otra cosa que descartar nuestro desarrollo, ya que la deuda técnica de arreglarlo cuesta más esfuerzo que empezar a hacerlo de nuevo. Esto se agrava cuando no hay una comunicación o refinamiento de la historia durante su desarrollo (práctica a evitar, obviamente).
  • Es posible que durante el desarrollo nos encontremos dificultades técnicas que podríamos haber abordado antes, lo cual provoca retrasos en la entrega (y en el proyecto), y cambios en la estimación de la historia.

Caso B: La HU tiene tanta funcionalidad que es difícilmente abordable en un sprint

 

 

Implicaciones:

  • Es posible que parte de la funcionalidad no se entregue porque no se llegue al fin de sprint, con lo que no estamos aportándole el valor que negociamos en su día con el usuario (el cual estará bastante descontento, por cierto). La HU se descartará ya que no cumple toda la funcionalidad pedida (no cumple sus criterios de aceptación), y provocará incertidumbre en el usuario ya que no podrá ver la funcionalidad terminada hasta un sprint después (como mínimo).
  • Si se llega a terminar la HU debido a un sobresfuerzo del equipo (pizza time) tendremos a un equipo descontento y muy posiblemente baje el ritmo o peor aún, se marchen de la compañía.

Caso C: Definimos la HU de tal forma que no aporte valor al usuario, por ejemplo, creando un componente técnico que nos vaya a servir en un futuro, pero que ahora no aporta valor.

 

Implicaciones:

  • No estamos basando nuestras HU en casos de uso reales. Esto desinvolucra por completo al usuario y sus necesidades.
  • Es imposible pensar qué funcionalidad tendrá el componente a priori (dependemos de los requisitos que vayan surgiendo durante el desarrollo del proyecto). Esto puede provocar que hagamos más funcionalidad de la necesaria (creando “arcos de iglesia”) en nuestros componentes que luego no vayamos a necesitar.
  • En el peor de los casos, es posible que la necesidad de tener ese componente cambie durante el desarrollo del proyecto, ¡con lo que es posible que se descarte por completo!

 

Definiendo buenas HU

Para evitar las situaciones anteriores, en el desarrollo de nuestras HU tenemos que enfocar buenas prácticas que nos ayude a minimizar la incertidumbre, dar valor al usuario y mantener motivado al equipo.

La primera característica de una buena HU es que se enuncia desde la perspectiva de la persona que desea la funcionalidad, esto es, el usuario. Esto dará un aporte de valor al mismo, promoviendo el modelo de entrega iterativa e incremental:

 

 

Esta imagen muestra la forma en la que un producto mínimo viable debería ser abordado, siempre aportando valor al usuario en cada entrega. Y detrás de cada entrega incremental está una buena definición de historia de usuario J

Si en la primera entrega de los primeros sprints hemos enfocado nuestras HU a componentes (o en la metáfora del coche, a las piezas del coche), lo que vamos a entregar va a ser en el primer caso la rueda del coche. El usuario no quiere una rueda del coche, lo que quiere es un medio de transporte que le permita ir más rápido de un sitio a otro.

En el modelo iterativo incremental, estamos enfocando nuestras historias de usuario desde un punto de vista de cliente, es decir, en lugar de enfocarlas a construir piezas de nuestro coche, estamos teniendo en cuenta desde el principio el aporte de valor al usuario final, es decir, el que quiere el medio de transporte rápido.

Evidentemente, en la primera iteración, siguiendo con la metáfora del coche, lo que estamos aportándole es un simple patinete que, bueno, no es el medio más rápido, pero es un producto final listo para ser usado, y que ya consideramos un medio más rápido que ir a pie.

Lo que conseguimos como equipo de desarrollo con este modelo iterativo e incremental es el aprendizaje continuo, concepto básico en agile que nos permitirá:

  • Aprender rápido de nuestros errores
  • Obtener madurez como equipo, en cuanto a auto organización y experiencia con las tecnologías y en el entorno con el que trabaja
  • Poder dar estimaciones cada vez más precisas a medio/largo plazo de lo que queda por hacer en base a lo aprendido

Tenéis más información en el artículo de Henrik Kniberg: Making sense of MVP

Un ejemplo de HU

Pongamos un ejemplo de enunciado de HU:

Yo como cliente de ING quiero poder adjuntar mi DNI en el sistema, para poder agilizar mi proceso de creación de cuenta.

Si os fijáis, el enunciado anterior se compone de dos partes bien diferenciadas:

 

Parte Enunciado Nos va a servir para
Usuario “Yo como X” –          Definir el stakeholder o usuarios involucrados

(¡Ojo!: Si no aporta a nadie, no es una historia de usuario)

Acción / función “Quiero Y” –          Definir la funcionalidad exacta que se quiere implementar
Beneficio / Valor “Para” –          Nos ayuda a definir el valor que se quiere dar en base a la necesidad. Con esto:

o    Definimos exactamente para qué quiere el usuario la funcionalidad pedida

o    Podremos asociar la HU a la épica correcta

o    Podremos priorizarla con respecto a otras HU

 

Es bueno usar un lenguaje común como el que acabo de expresar. Es un lenguaje que entiende el usuario y los miembros del equipo, y que es vital para mantener una comunicación fluida y constante con el mismo. Es muy común a su vez encontrarnos con la nomenclatura Gherkin en los criterios de aceptación de las HU, ya que luego nos ayudan a definir nuestros tests unitarios. Con BDD / ATDD podremos hacerlo posible (podéis ver el post de José San Román donde se habla de Specification by example: ¿Por qué es más importante el código de test que el código de la aplicación?).

 

En el siguiente post explicaremos los principios básicos y algunas técnicas que nos permitirán tener historias de usuario estructuradas y desarrolladas correctamente.

Podéis seguir más artículos, noticias y datos interesantes en https://www.ingtechit.es y en mi cuenta de Twitter.