Historias de usuarios en la elicitacion de requerimientos de software
En este post hablare de las historias de usuarios o User stories como le se conoce en ingles, en el tema de ingeniería de software.
Una de las principales características de la programación ágil es que los miembros del equipo del proyecto no suelen tener el lujo de tiempo para documentar los requisitos de manera exhaustiva. También es imperativo recopilar comentarios de los usuarios lo antes posible en el ciclo de vida del proyecto, de ahí la preferencia por los requisitos concisos conocidos como historias de usuarios. La historia del usuario no es todo el requisito, sino una sinopsis.
Escribir una historia de usuario es una forma encantadora de agregar un toque de rapidez a sus proyectos. Una historia de usuario puede describirse como una declaración de alto nivel de un requisito que no entra en detalles excesivos. Describe la funcionalidad o característica que se espera que un producto entregue al usuario. Las historias fomentan el desarrollo iterativo y pueden refinarse tantas veces como sea posible para llegar a un acuerdo y entendimiento entre las partes interesadas.
Las historias de los usuarios pueden expresarse presentando el rol, el objetivo o el valor primero. BAs sin embargo. elija el formato que sea mejor para expresar sus requisitos considerando el contexto.
La historia del usuario se coloca como texto en una tarjeta de índice y se utiliza como recordatorio de la conversación entre el cliente y el desarrollador. Por lo general, se expresa como: nombre + breve narrativa + criterios de aceptación.
¿Cuál es el formato de las historias de usuarios?
"Como función (w), quiero que la funcionalidad (x) logre el objetivo comercial (y)". Este enfoque para escribir historias de usuarios se considera como el enfoque de voz del cliente. Por ejemplo “Yo como planificar de demanda, quiero ver el historial de ventas para así poder mejorar los planes e incrementar las ventas”.
Características de las historias de usuarios
- Las historias normalmente se escriben en tarjetas de notas, que contienen estimaciones, notas o especificaciones sobre cómo debe comportarse el software.
- Los detalles de la historia generalmente provienen de conversaciones con los propietarios del producto. La escritura de historias requiere trabajo en equipo. La creatividad de todo el equipo debe aprovecharse en su desarrollo.
- Las historias generan discusiones importantes que revelan los requisitos. Pegue carteles de historias de usuarios en la pared para mantenerlos visibles y desencadenar la discusión.
- Los criterios de aceptación son una forma de verificar la historia: son las condiciones de satisfacción de los usuarios añadidas a la historia del usuario y luego utilizadas para probar el software.
- Los talleres de redacción de historias generalmente se organizan para incluir desarrolladores, usuarios, clientes, etc. Los participantes intercambian ideas para generar ideas de historias.
- Las historias de usuario siempre se escriben desde la perspectiva del usuario.
- Las historias de usuario generalmente se priorizan para cada iteración. Las historias priorizadas se guardan en lo que se conoce como cartera de pedidos de productos. Las prioridades se pueden cambiar según sea necesario.
- Las historias se pueden descomponer a partir de historias grandes / orientadas a objetivos (épicas) y descomponerse en historias más pequeñas o más cortas. También pueden organizarse utilizando temas (agrupando historias relacionadas entre sí).
Errores que se deben evitar si queremos hacer unas buenas historias de usuario
- No suponga que solo hay un usuario. Los usuarios pueden variar y pueden no tener los mismos objetivos al usar un sistema. Cuando se utilizan roles, los usuarios se vuelven más tangibles y es más fácil distinguir entre las diferentes categorías de usuarios.
- En lugar de preguntar a los usuarios cuáles son sus historias, invítelos a crear un entorno de diseño participativo; esto tiene beneficios significativos.
- No todo lo que tiene que ver con el desarrollo del sistema debe capturarse en forma de una historia de usuario. Por ejemplo, los defectos y las ideas de diseño no necesitan expresarse como historias de usuarios.