Hace unos días Roberto Canales (@rcanalesmora), tras venir de asistir al AOS 2013, me enseñaba un artículo firmado por Laura Powers sobre técnicas de división de historias de usuario y realmente me pareció muy interesante (http://www.agilelearninglabs.com/2013/05/new-quick-reference-guide-for-splitting-user-stories). El uso de técnicas y patrones siempre es bueno dentro de muchos ámbitos ¿Por qué no aplicarlo a algo tan vital como la división de historias de usuario? Todo el mundo puede hacer una división de historias de usuario y subirse al tren de las metodologías ágiles. Lo complicado es hacerlo bien, ya que la calidad de esta división afectará muy mucho al proyecto. Una buena división en historias de usuario las hará más comprensibles para todos, mejor estimables, etc. Es decir, nos acercará un poco más a nuestro objetivo: el éxito.
Una de las cuestiones más complejas y controvertidas en el mundo de las metodologías ágiles es la división en historias de usuario de los requisitos de un proyecto. Además es una de las partes más importantes y vitales para la correcta aplicación del llamado agilismo.
En muchas ocasiones nos vamos a encontrar con una mala división en historias e incluso algunas historias épicas, que son difíciles de comprender, estimar y aplicar. Éstas tienen que poderse dividir en varias historias más sencillas para ser abordadas de una forma más sencilla y ágil dentro de la definición de un sprint.
A veces esta divisón de historias épicas en varias historias más simples es una tarea compleja y algo subjetiva. A continuación se explicará unas técnicas o métodos para la división de historias épicas de usuario basadas en cuatro formatos de historias:
– historias de usuario con conjunciones y conectores
– historias de usuario con palabras genéricas
– historias de usuario con criterios de aceptación
– historias de usuario con análisis de timeline
Una de las primeras cosas que se tienen que tener en cuenta y muy clara desde el comienzo son los actores participantes dentro del proyecto, como por ejemplo usuario anónimo, usuario registrado, operador, supervisor, administrador, soporte, sistema, etc.
Antes de explicar las técnicas de división de historias se define un patrón o formato de éstas:
– As {role} I want {what} so {benefit}
Por ejemplo: «Como usuario yo quiero poder formalizar un viaje y así obtener la compra más ventajosa para ese trayecto«. Son las respuestas a ¿Quién? ¿Qué? ¿Por qué?
Historias de usuario con conjunciones y conectores
Esta primera técnica se basa en el reconimiento previo de conjunciones y conectores del tipo: y, o, si, cuándo, pero, entonces, como, bueno, como, «comas«, etc. Si se detectan algunas de estas palabras en una historia, ésta es sensible a divisón en varias historias más sencillas.
Por ejemplo, si tomamos la historia original «Como usuario anónimo quiero poder encontrar tutoriales y artículos para poder aplicarlos a mi crecimiento tecnológico«. Vemos que existe una conjunción «y» por lo que dicha historia se podría dividir en dos:
- «Como usuario anónimo quiero poder encontrar tutoriales para poder resolver dudas tecnológicas«
- «Como usuario anónimo quiero poder encontrar artículos para poder ampliar mi conocimiento tecnológico«.
Como se puede ver, al dividir una historia en varias más sencillas, puede darse el caso que en la definición de éstas se llege a una definición más específica al reducir el ámbito. En estos casos se puede cambiar la definición de éstas historias más sencillas para ser más específicas y de esta forma sean más fáciles de implementar, cubran todas las necesidades funcionales y sean más fáciles de comprender y estimar.
Historias de usuario con palabras genéricas
En esta segunda técnica de divisón de historias de usuario se trata también de identificar ciertas palabras, pero en este caso, nos centraremos en buscar palabras genéricas.
Por ejemplo, si tomamos la historia original «Como usuario anónimo quiero poder encontrar información para poder aplicarlos a mi crecimiento tecnológico«. Aquí se ve claramente como la palabra «información» abarca por debajo muchos otros conceptos y su ámbito es muy grande. Es una palabra sensible a ser llamada «palabra genérica«. Estas palabras genéricas se deberán poder dividir en varias palabras o términos más específicos como por ejemplo, tutoriales y artículos. Quedarías algo así:
- «Como usuario anónimo quiero poder encontrar tutoriales para poder resolver dudas tecnológicas«
- «Como usuario anónimo quiero poder encontrar artículos para poder ampliar mi conocimiento tecnológico«.
Al igual que la anterior técnica, la división en historias más sencillas puede llegar a definirlas con más detalle o más específicas.
Historias de usuario con criterios de aceptación
En esta tercera técnica se van a tener en cuenta una serie de criterios de aceptación que nos dirán si la historia definida se lleva a cabo según lo previsto. Cada historia debe tener entre 4 y 12 criterios de aceptación y es el Product Owner junto con el equipo de desarrollo quienes tienen que establecer estos criterios. Esta técnica se centra en el concepto del «benefit» dentro del patrón definido para las historias del proyecto.
Por ejemplo, si tomamos la historia original «Como usuario anónimo quiero poder encontrar artículos para poder ampliar mi conocimiento tecnológico«. El objetivo de la historia, el porqué de éstas, es el de amplicar mi conocimiento tecnológico, y para ello se pueden definir una serie de criterios de aceptación como por ejemplo:
- tienen que ser en inglés.
- tienen que ser de Spring 3.x
- tienen que ser de Directores de Negocio
- tienen que ser de Java 7
Con estos criterios de aceptación ya definidos se podría dividir la historia en varias más sencillas quedando de esta forma:
- «Como usuario anónimo quiero poder encontrar artículos en inglés».
- «Como usuario anónimo quiero poder encontrar artículos de Spring 3.x«.
- «Como usuario anónimo quiero poder encontrar artículos de Directores de Negocio«.
- «Como usuario anónimo quiero poder encontrar artículos de Java 7«.
Historias de usuario con análisis de timeline
Esta técnica es la menos utilizada ya que con las anteriores tres técnicas se puede ser capaz de dividir hasta el 95% de las historias de usuarios. Esta última técnica se basa en el análisis temporal. Para ésto se tiene que ver cada historia de usuario como un escenario a modo de workflow donde el actor puede «pasar» por varios estados o realizar diferentes acciones. Cada una de estas acciones/estados, que dependen cronológicamente unos de otros, se pueden considerar como historias más sencillas y son sensibles a divisón.
Por ejemplo, si tomamos la historia original «Como usuario anónimo quiero poder encontrar tutoriales para poder resolver dudas tecnológicas. Pero también quiero poder identificarme en el sistema para poder descargarme el código fuente para usarlo como ejemplo. Además quiero poder descargarme el tutorial en pdf para imprimirlo«. Vemos claramente como existe un flujo muy identifcado. Primero el usuario en modo anónimo encuentra un tutorial, luego tiene que logarse en el sistema, después puede descargarse el código fuente o descargarse el pdf». Cada uno de estos pasos del flujo se puede dividir en una historia más sencilla.
Buenos días, estoy introduciéndome en las historias de usuario y por tanto escribiendo los criterios de aceptación de la historia y tenía una duda sobre como registrar un requerimiento, que no se si es técnico o funcional, pero que que creo que es importante.
Este requerimiento es en relación al registro y en el que se debe indicar que la contraseña no pueda tener menos de 8 carateres y deba contener un caracteres y números. ¿debo poner esto como un escenario? o ¿esto el como y no el que y por tanto no se debe escribir en la historia?
Tendría en los escenarios de prueba algo como:
Como usuario quiero registrarme en la web
y una vez introducido el login de forma correcta
cuando escribe la contraseña con menos de 8 carateres el sistema le muestra un aviso indicándole como debe ser la contraseña.
En el caso de uso de Registro en una web sería :
Como usuario no validado quiero poder registrarme en la web mediante un formulario para ser usuario registrado y disfrutar del contenido para usuarios registrados.
No se si se deben registrar el “como” se deben validar los campos , y si no se deben registrar estas cosas en la historia de usuario me guatria sabe como lo debemos poner.
otro ejemplo sería si quiero que el login sea el mail, ¿ se debe especificar que el login debe ser un mail?
Gracias
Realmente interesante y útil al ser práctico. Tenía un esquema de división, pero este artículo lo aclara bastante bien.
En mi caso, apenas tenemos argumentos para dividir historias en los equipos y nos terminamos quedando con historias bien grandes por lo general.
Ahora ya tengo elementos para seguir argumentando.