Las historias de usuario forman parte de un enfoque ágil que ayuda a cambiar el enfoque de escribir sobre los requisitos a hablar sobre ellos. Todas las historias de usuario ágiles incluyen una o dos frases escritas y, lo que es más importante, una serie de conversaciones sobre la funcionalidad deseada.
CONTENIDOS
¿Qué es una Historia de Usuario?
Las historias de usuario son descripciones breves y sencillas de una característica del producto contadas desde la perspectiva de la persona que desea ese nuevo requisito normalmente un usuario o cliente del sistema. Suelen seguir una plantilla sencilla:
Las historias de usuario suelen escribirse en fichas o notas adhesivas, se guardan en una caja de zapatos y se colocan en paredes o mesas para facilitar la planificación y el debate. Como tales, cambian fuertemente el enfoque de escribir sobre las características a discutirlas. De hecho, estas discusiones son más importantes que cualquier texto que se escriba.
¿Cómo se escribe una historia de usuario?
Una de las ventajas de las historias de usuario ágiles es que pueden escribirse con distintos niveles de detalle. Podemos escribir una historia de usuario que cubra grandes cantidades de funcionalidad. Estas grandes historias de usuario se conocen generalmente como épicas.
He aquí un ejemplo de una épica de un producto de copia de seguridad de escritorio:
Como una historia épica suele ser demasiado grande para que un equipo la complete en una sola iteración, se divide en varias historias de usuario más pequeñas antes de trabajar en ella. La épica anterior podría dividirse en docenas (o posiblemente cientos), incluyendo estas dos:
¿Qué nivel de detalle debe tener una historia de usuario?
Los detalles pueden añadirse a las historias de usuario de dos maneras:
- Dividiendo la historia de usuario en varias historias de usuario más pequeñas.
- Añadiendo «Criterios de Aceptación.
Cuando una historia relativamente grande se divide en varias historias de usuario ágiles más pequeñas, es natural suponer que se han añadido detalles. Después de todo, se ha escrito más. Los criterios de acpetación son simplemente una prueba de aceptación de alto nivel que se cumplirá después de que la historia de usuario ágil esté completa.
¿Quién escribe historias de usuario?
Cualquiera puede escribir historias de usuario. Es responsabilidad del propietario del producto o Product Owner asegurarse de que existe un backlog de historias de usuario ágiles, pero eso no significa que el propietario del producto sea quien las escriba. En el transcurso de la evolución del producto, deberías esperar tener ejemplos de historias de usuario escritas por cada miembro del equipo.
Además, tenga en cuenta que quién escribe una historia de usuario es mucho menos importante que quién participa en las discusiones de la misma.
¿Cuándo se escriben las historias de usuario?
Las historias de usuario se escriben a lo largo del desarrollo del producto. Normalmente, se lleva a cabo un taller de redacción de historias cerca del inicio del desarrollo del producto. Todos los miembros del equipo participan con el objetivo de crear un backlog del producto que describa por completo la funcionalidad que se añadirá a lo largo del ciclo de vida del producto o de un ciclo de lanzamiento de tres a seis meses dentro del mismo.
Algunas de estas historias de usuario ágiles serán sin duda épicas. Las historias épicas se descompondrán posteriormente en historias más pequeñas que encajen más fácilmente en una sola iteración. Además, se pueden escribir nuevas historias y añadirlas al backlog del producto en cualquier momento y por cualquier persona.
¿Sustituyen las historias de usuario a un documento de requisitos?
Los equipos ágiles, especialmente los de Scrum, utilizan un backlog de producto, que es una lista priorizada de las funcionalidades a desarrollar en un producto o servicio. Aunque los elementos del backlog del producto pueden ser lo que el equipo desee, las historias de usuario han surgido como la mejor y más popular forma de elementos del backlog del producto.
Aunque se puede considerar que un backlog de producto sustituye al documento de requisitos de un proyecto tradicional, es importante recordar que la parte escrita de una historia de usuario ágil («Como usuario, quiero…») está incompleta hasta que se producen las discusiones sobre esa historia.
A menudo es mejor pensar en la parte escrita como un indicador del requisito real. Las historias de usuario pueden apuntar a un diagrama que represente un flujo de trabajo, una hoja de cálculo que muestre cómo realizar un cálculo o cualquier otro artefacto que el propietario del producto o el equipo desee.
