HISTORIAS DE USUARIO, ENTES ÁGILES VIVOS

Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. Esa es la definición de la wikipedia para una historia de usuario. Su origen se remonta a Extreme programming y han ido madurando con el tiempo, gracias a grandes agilistas como Mike Cohn.

Las historias de usuario, se entienden como un contrato. Pero desde mi punto de vista, una historia madura con el tiempo, al igual que un proyecto agile va evolucionando en el cono de incertidumbre con el tiempo, la historia también. Por tanto, ese "contrato" evoluciona y cambia, se adapta a las necesidades del cliente durante la vida agile del proyecto.

A diferencia con las epics o features, las historias de usuario (user stories) deben de ser pequeñas, para poder realizarse en poco tiempo (días o un par de semanas a lo sumo). De esta manera aportarán valor pronto, rápido y concreto al cliente y se adaptarán a sus necesidades de negocio. Porque el propósito de ellas es aportar valor de negocio al cliente.

Si la historia se va de tiempo, a más de dos semanas, es un indicativo de que no es una historia de usuario, es más, podrán ser  varias incluso, o no tener suficiente conocimiento del problema.

Estamos acostumbrados a leer u oír que una historia debe de ser independiente, negociable, valiosa, estimable, pequeña y comprobable, pero que es todo eso?

Independiente: En agile estamos acostumbrados a trabajar en equipo, pero aplicando el sentido común, tratando de evitar bloqueos, dependencias entre miembros del equipo, para que el trabajo "fluya" a lo largo del sprint correctamente. Con lo cual, si conseguimos historias independientes, tanto entre sí, como independientes de miembros del equipo y de conocimiento explícito de personas, estaremos haciendo historias más robustas. Historias dependientes conducen a priorizar y planificar en función de esas dependencias, no del valor que proporcionan al cliente. Dependencias entre historias pueden hacer más difícil la tarea de estimación. Cuantas veces nos hemos encontrado ante el dilema con el cliente de "No, es que si te hacemos esta historia primero, o al mismo tiempo que esta otra, la estimación de la primera es menor". Ante dependencias, podemos realizar un agrupamiento de ambas historias en una historia más amplia, que se vuelve independiente del resto (siempre que sea viable realizarla en un sprint) o por el contrario tratar de encontrar una forma diferente de dividir las historias para romper la dependencia. Siempre trataremos de realizar estas dos acciones, y como última, la de dos estimaciones en función del orden de resolución de las historias. Pero, esta opción, debería de ser la última a contemplar cuando las anteriores nos han fallado o no hemos podido llegar a solucionar dicho problema de división.

Negociable: Las historias son negociables, son breves descripciones de la funcionalidad deseada por el cliente. Los detalles han de ser negociados en una conversación entre el cliente y el equipo. No se incluyen todos los requisitos muy detallados, pero si recordatorios y detalles imprescindibles. Un detalle extra sobre una historia nos puede hacer pensar erróneamente en la precisión adicional. Pero dichas especificaciones iniciales solo nos crearán complicaciones y más trabajo a futuro. El correcto funcionamiento de una historia de usuario debería de ser:

·         Una frase o dos que actúan como recordatorio para mantener una conversación entre equipo y cliente.

·         Notas sobre cuestiones que deben ser resueltas en dicha conversación.

Aquí surgirán detalles sobre las cuestiones a tener en cuenta, y dichos detalles se convierten tras las conversaciones en pruebas de la historia de usuario. Dichas pruebas son pruebas funcionales para demostrar si funciona como el cliente esperaba.

Valioso: El término valioso nos plantea muchos problemas, ¿Porqué?, Pues porque tenemos valores distintos, una historia puede ser valiosa para el equipo y no para el cliente, o puede ser valiosa para el cliente pero no para el usuario final. Hay que tratar siempre de evitar historias que solo sean valoradas por él equipo, puesto que el fin último es dar valor al cliente.

Hay que tratar de no tener historias técnicas como muestro en el siguiente ejemplo:

- Todas las conexiones a la base de datos son a través de un pool de conexiones.

- Hasta 50 usuarios deben ser capaces de utilizar la aplicación simultáneamente.

Tienen que ser más abstractas, no técnicas, para que el usuario pueda considerar correctamente el valor que le aporta. Hay que tratar de que sea el cliente el que escriba dichas historias, porque las escribirá en el lenguaje que a él le aportan valor. Los clientes se sentirán incómodos con esta nueva circunstancia porque pueden pensar que se les volverá en contra, situaciones del tipo, "bueno, el requisito no dijo ..". Hay que hacer que el cliente comience a sentirse cómodo con el concepto de que las historias son un recordatorio del que hablar más tarde, en lugar de compromisos formales o funcionalidad específica.

Estimable: Es importante que en el equipo sean capaces de estimar o al menos tener una pista de la complejidad de cada historia. Pero pueden surgir problemas cuando:

·         El equipo carece de conocimiento del dominio.

·         El equipo carece de conocimiento técnico.

·         La historia es demasiado grande.

Si el equipo carece del conocimiento del dominio, debería de discutir con el cliente que escribió la historia, aprender con el cliente. No es necesario conocer todos los detalles, pero si un conocimiento general de qué desea el cliente y porqué desea esa historia el cliente.

En segundo lugar, una historia puede tener problemas de estimación por una tecnología no conocida. Una forma de estimar este tipo de historias es dividirlas en dos, con una primera parte de la historia que sea de time box - caja de tiempo para aprender y comprender la tecnología y facilitar la estimación de la siguiente o siguientes historias que involucren a dicha tecnología. La primera historia sirve para reunir información rápidamente y la segunda historia sirve para hacer el trabajo realmente.

Por último, el equipo puede no ser capaz de estimar una historia demasiado grande. Para poder llegar  a estimar esta historia el equipo, deberá desglosar en más pequeñas.

Pequeño: El tamaño de la historia importa, historias demasiado grandes o demasiado pequeñas no se pueden utilizar en la planificación. Las historias grandes como las épicas son difíciles de trabajar. La determinación final del tamaño se basa en el equipo, sus capacidades y las tecnologías utilizadas para realizarla. Una historia puede ser compuesta o compleja. La historia compuesta comprende varias historias que son visibles.

Compleja: La historia compleja, a diferencia de compuesta, es muy grande, y no puede fácilmente ser dividida. Si hay mucha incertidumbre genera complejidad. En este caso dichas historias pueden ser divididas en una parte de investigación y otra de desarrollo.

Combinables: A veces las historias son demasiado pequeñas. Cuando el equipo dice que una historia no necesita ser escrita o estimada por ser muy pequeña existe un problema. Puede generar problemas posteriores y no estar documentada. Con lo cual dichas historias pequeñas habrá que combinarlas en historias más grandes para tener  constancia de ellas.

Comprobable:  Es importante que el resultado de las pruebas demuestre que la historia fue realizada con éxito. Si la historia no puede ser comprobada, ¿Cómo puede el equipo definir cuando ha terminado la historia?. Historias que no se pueden comprobar atienden a requisitos no funcionales, tales como "El software debe ser fácil de usar". "El usuario no tiene que esperar mucho tiempo para que aparezca su pantalla de acceso".

Debemos de tratar, además, de que dichas pruebas sean automatizadas. Se puede automatizar más de lo que se creé. Cuando se desarrolla un producto incremental, las cosas cambian muy rápidamente, y algo realizado ayer puede dejar de funcionar hoy, lo que se denominan "fallos colaterales". Con esas pruebas automatizadas encontrará dicho fallo lo antes posible.

Hay una muy pequeña parte de las pruebas que no se pueden automatizar, seamos realizas, pero habremos cubierto posiblemente más del 90% de la funcionalidad de modo automático.

A modo de conclusión, no siempre realizar todo esto es posible, pero es una meta lean, a tratar de alcanzar, pero ante todo las historias son negociables entre usuario y equipo, y como tal han de escribirse. Deben de ser escritas por el cliente con la ayuda del equipo. En la propia historia se pueden documentar casos de prueba que demuestren su realización correcta. Si son demasiado grandes, divide, tanto historias compuestas como complejas, por el contrario, si son demasiado pequeñas, agrúpalas para que den valor al cliente. Las historias son promesas para hablar, no especificaciones detalladas. Las historias técnicas o de infraestructura, hay que describirlas como necesidades en términos de valor aportados al cliente.