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:
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
Un spike debe tener un timebox para evitar la tentación de parálisis por análisis.
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:
De la que podemos sacar los siguientes pasos convertidos en historias de usuario:
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:
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:
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:
- 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:
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.