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.
