SPIDR, criterios para dividir historias de usuario

Las historias de usuarios son una gran herramienta para entender lo que se quiere hacer, por qué y para quién. Ron Jeffries en el libro Extreme Programming Installed, describe los tres aspectos críticos de las historias de usuario como Card, Conversation, Confirmation, dónde la tarjeta (Card) simplemente recoge el texto suficiente para que podamos tener una conversación más adelante. Dicho de otro modo, una historia de usuario es el recordatorio de una conversación.

La diferencia con la captura de requisitos clásica, es que los requisitos intentan expresar todos los detalles de manera escrita. Las historias de usuario en cambio buscan obtener esa información mediante una conversación en el momento preciso. Ese momento será cuando quede poco para que la historia de usuario sea abordada.

Uno de los típicos problemas cuando se escriben las historias de usuarios es mantener conversaciones largas y complejas. Esto es probablemente un síntoma de que el tamaño de la historia de usuario abarca demasiados temas. Otro problema común suele producirse más adelante, cuando se tarda mucho en que los usuarios dispongan de la funcionalidad derivada de la historia de usuario, este problema también puede ser causado por el tamaño de las historias.

El arte de crear historias de usuario de tamaño adecuado por tanto es esencial para sacar partido a todo su potencial.

Existen diferentes heurísticas que nos ayudan a detectar y resolver problemas con el tamaño de las historias de usuario. Bill Wake y Mike Cohn tienen un trabajo interesante al respecto. En este articulo nos centraremos en un conjunto de heurísticas que Mike Cohn propuso para partir historias de usuario, y que denominó SPIDR.

SPIDR es el acrónimo de Spike, Paths, Interfaces, Data and Rules, que son en realidad una serie de criterios por los que potencialmente podríamos partir una historia de usuario.

Spike

Algunas veces las historias son demasiado grandes porque el equipo no sabe cómo hacer alguna parte de la historia. Quizás la historia envuelve una tecnología no familiar o una parte del código desconocida. Lo mejor en esto casos es hacer un spike para reducir incertidumbre. Un spike es una actividad de investigación.

Un ejemplo podría ser:

Como miembro, cualquier click es analizado por el Super Sistema de Marketing Automatizado para que pueda recibir un email con información sobre cosas en las que yo parezca estar interesado.

Y al reconocer que nadie conoce cómo funciona el Super Sistema de Marketing Automatizado y puede haber mucha incertidumbre, pasaríamos a crear el siguiente spike

Investigar el Super Sistema de Marketing Automatizado.

Un spike debe tener un timebox para evitar la tentación de parálisis por análisis.

El objetivo de un spike es el aprendizaje, no el desarrollo de una funcionalidad. Los spikes ayudan a reducir incertidumbre sobre cómo construir la funcionalidad. Por otro lado, crear spikes con demasiada frecuencia puede ser un síntoma de que el equipo necesita formación en aspectos concretos (tecnología, dominio, etc).

Paths

A veces se puede considerar que una historia tiene múltiples pasos. El usuario hace X y entonces hace Y y entonces Z. Un ejemplo podría ser:

Como miembro, puedo pagar por una reserva que he realizado.

De la que podemos sacar los siguientes pasos convertidos en historias de usuario:

Como miembro reservando un coche, puedo introducir la información del pago.
Como miembro reservando un coche, puedo introducir la dirección de facturación.
Como miembro reservando un coche, puedo indicar la oficina en la que recogeré el coche reservado.

Las diferentes historias en las que se divide la historia original son independientes y por tanto, si quisiesemos podríamos implementarlas en paralelo. O podríamos optar por realizar una primera release en el que alguno de los caminos sea aún manual.

Por ejemplo, se le podría avisar al usuario que para la parte relativa a “emitir la factura” debe enviar un correo con sus datos fiscales. Posteriormente este correo es respondido por una persona de manera manual hasta que el sistema implemente la generación de la factura.

Interfaces

Algunas historias de usuario son complicadas porque tienen múltiples interfaces. A veces pueden ser user interfaces (mobile, desktop) y otras data interfaces (múltiples APIs).

Si tuviéramos una historia que necesita que funcione en la web, en iOs y Android, una buena opción es partir por tipo de interface, Ejemplo:

Como un usuario de iOS, puedo hacer cualquier cosa.
Como un usuario de Android, puedo hacer cualquier cosa.
Como un usuario usando un browser, puedo hacer cualquier cosa.

Data

Una historia puede ser larga por la cantidad y tipos de datos que debe soportar. Desarrollar una versión inicial que soporte un subset de datos puede ser una gran modo de partir una historia.

También podríamos decidir ignorar algunos tipos de datos de manera eventual. Ignorarlos puede pasar por no coleccionarlos o no procesarlos o validarlos.

Un ejemplo podría ser:

Como turista quiero ver cosas interesantes en la ciudad.

Podríamos partir la historia de acuerdo con los diferentes tipos de “cosas interesantes”, en este caso, museos, tours, actividades, etc.

Rules

Algunas historias de usuario son largas porque implican implementar múltiples reglas. Un ejemplo sería:

Como miembro, puedo reservar un coche
  • Un miembro no puede reservar un coche con más de 90 días de antelación.
  • Un miembro no puede tener más de 3 reservas activas a la vez.

Que se podría partir atacando alguna regla en una historia de usuario diferente:

Como miembro, no puedo tener más de 3 reservas activas a la vez

Conclusión

Manejar el tamaño preciso de las historias de usuario nos ofrece ventajas para entregar funcionalidad de manera temprana y focalizarnos en pequeños aspectos de valor. Conocer heurísticas para partir las historias de usuario nos ayuda a visualizar formas de hacerlo. Aunque existen múltiples propuestas a este problema, SPIDR de Mike Cohn ofrece un conjunto simple, fácil de recordar y que nos puede ayudar bastante en la mayoría de los escenarios.

Referencias