Historias de usuarios
Agile 101
Historias de usuarios: Qué son, por qué y cómo utilizarlas
What Is a User Story?
¿Qué es una historia de usuario?
En Agile, una historia de usuario es una descripción breve, informal y en lenguaje sencillo de lo que un usuario quiere hacer dentro de un producto de software para obtener algo que le resulte valioso.
Las historias de usuario suelen seguir el patrón (o plantilla) rol-función-beneficio:
-
Como [tipo de usuario],
-
quiero [una acción]
-
para que [un beneficio/valor]
Como unidad de trabajo más pequeña en un entorno ágil, las historias de usuario son una herramienta clave en el desarrollo incremental.
¿Por qué utilizar historias de usuarios? ¿Cuáles son sus beneficios?
Con las historias de usuario se pone a los usuarios en el centro de la conversación sobre lo que hay que añadir o cambiar en un producto de software. Son la encarnación del primer principio del Manifiesto Ágil (el énfasis es mío):
Con las historias de usuario se da al equipo de desarrollo el contexto y el porqué de lo que están creando. Esto les ayuda a entender cómo están aportando valor a la empresa y a mantener al usuario/cliente como prioridad.
Las historias de usuario proporcionan la esencia necesaria para priorizarlas.
No es necesario añadir detalles como los requisitos hasta que se decida que es el momento de ponerlos en práctica. Aparte quizás de lo que Mike Cohn llama condiciones de satisfacción con las que un usuario puede ampliar y explicar conceptos. Se añaden otros detalles a medida que se acerca el momento de implementar la historia. Por ejemplo, durante la fase de exploración en el Desarrollo Dirigido por el Comportamiento (BDD).
La brevedad te permite cambiar de opinión hasta el último momento posible (responsable) sin tirar mucho esfuerzo. Esto te ayuda con el segundo principio del Manifiesto Ágil:
«Acoge los requisitos cambiantes, incluso en las últimas fases del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente».
La naturaleza concisa y el enfoque en el usuario de las historias de usuario también ayuda a separar quién se ocupa de lo que vas a hacer (el cliente o el gestor de productos) y quién se ocupa de cómo lo vas a hacer (los desarrolladores).
Y, por último, como las historias de usuario son pequeñas unidades de trabajo autónomas, disfrutarás de muchas pequeñas victorias a medida que vayas completando una tras otra. Eso es bueno para coger impulso.
¿Cómo no beneficiarse de las historias de usuario – Errores comunes?
-
Partir de un documento de requisitos creado de forma no ágil y acabar con historias artificiales.
-
Añadir detalles y requisitos demasiado pronto. Las historias que están a punto de ser implementadas necesitan el mayor nivel de detalle y claridad. Las historias a punto de ser implementadas pueden hacerlo con menos. Y las historias a más de 2 o 3 iteraciones no necesitan ninguno.
-
No tener una conversación sobre la historia con todos los implicados, clientes, usuarios, desarrolladores, probadores, profesionales de la empresa, antes de empezar la implementación. Esta conversación es esencial para añadir de forma colaborativa los detalles, los criterios de aceptación, que evitarán la repetición del trabajo.
¿Qué es una buena historia de usuario?
-
Independientes. Desea que las historias de usuario sean independientes entre sí para poder moverlas libremente por el backlog del producto a medida que cambian las prioridades.
-
Negociables. Los detalles de una historia de usuario se establecen en colaboración entre el cliente y el equipo que la implementará. Esta colaboración incluye la negociación del alcance: qué incluirá y qué no incluirá la implementación.
-
Valiosa. Una buena historia de usuario tiene valor para el cliente (que puede ser un usuario interno). Sin ese valor, no tiene sentido dedicar ningún esfuerzo a la historia.
-
Estimable. Si no puede estimar una historia, significa que aún no entiende el alcance lo suficientemente bien, o que el alcance es demasiado grande para estimarlo fácilmente. No necesita estimaciones exactas, pero cuando puedes estimar una historia también es más negociable. Además, podrás diferenciar entre las historias valiosas de bajo esfuerzo y las no tan valiosas de alto esfuerzo.
-
Pequeño. El esfuerzo para implementar una historia de usuario debe ser pequeño. Como máximo, unas pocas semanas (por una persona), aunque muchos equipos utilizan «unos pocos días» como límite. Las historias pequeñas son más fáciles de estimar. Las historias grandes son más difíciles de estimar y, por tanto, menos negociables.
-
Comprobables. Si su cliente, en colaboración con el equipo de ejecución y con la ayuda de éste, no puede decirle cómo verificar que ha implementado lo que quiere, todavía no ha creado suficiente claridad sobre la historia. Escribir los criterios de aceptación, también conocidos como especificación por ejemplo en BDD, antes de implementar la historia, hace que un equipo sea más productivo al evitar el retrabajo como resultado de malentendidos.
Escribir historias de usuario no es el objetivo
Cómo escribir una historia de usuario en 4 sencillos pasos
-
1. Empezar por el final
-
2. Trabajar hacia atrás
Con el usuario y el objetivo final claramente en mente, se elaboran los pasos que un usuario tendría que dar para alcanzar su objetivo.
Intentar averiguar cuál es el primer paso para alcanzar un objetivo es difícil. Simplemente hay demasiadas opciones para elegir y no hay manera de elegir una sobre otra..
La salida es trabajar hacia atrás desde el objetivo.
Digamos que su objetivo es disfrutar de un batido de fresas. Así que se empieza por ahí: un batido de fresas terminado, listo para ser disfrutado.
¿Qué necesita para ello? Obviamente, un vaso, una pajita, un batido y todo lo necesario para ello.
- conseguir un vaso
- conseguir una pajita gruesa
- prepara el batido
- verter el batido en el vaso
- introducir la pajita en el batido
Tiene un vaso adecuado, pero le faltan pajitas gruesas, así que
- comprar pajitas gruesas
Nunca ha hecho un batido, pero sabe que necesita una licuadora, así que
- sacar la batidora
- seguir a receta
Para seguir una receta, es necesario
- encontrar una receta
- comprar los ingredientes especificados en la receta
-
3. Pequeño es Hermoso
-
4. Pluma y papelTarjetas
Ejemplos de historias de usuario
Aquí hay algunos ejemplos de historias de usuario para que todo sea más concreto.
-
Como gestor de productos con un equipo remoto, quiero poner las historias de usuario en un tablero digital, para que todos podamos ver la que estamos discutiendo en una reunión en línea.
-
Como gestor de productos con un equipo remoto, quiero invitar a los miembros de mi equipo y a un máximo de 10 personas más a una reunión en línea, para que podamos colaborar para detallar las historias de usuario que se implementarán pronto.
-
Como gestor de productos con un equipo remoto, quiero crear y editar una lista con los miembros de mi equipo, para añadirlos a todos a una invitación sin tener que añadirlos individualmente.
Cómo desarrollar software a partir de historias de usuarios
Las historias de usuario son narraciones de alto nivel que carecen de los detalles que necesitan los desarrolladores y probadores.
Por lo tanto, cuando una historia de usuario se va a implementar pronto, hay que añadir los detalles que mantendrán a todo el mundo en el camino y evitarán el (re)trabajo innecesario.
Ron Jeffries ideó las 3Cs, aspectos críticos, de trabajar y desarrollar software empezando por las historias de usuario.
¿Cuáles son las 3 C’s en las historias de usuario?
-
Tarjeta
-
Conversación
Se llevan a cabo conversaciones, discusiones abiertas, entre el cliente y las personas que participan en la aplicación para llegar a los requisitos específicos y proporcionar la claridad necesaria para la aplicación.
Los ejemplos concretos son la mejor manera de aportar claridad. Y los ejemplos ejecutables le dan…
-
Confirmación

