Son una técnica
de levantamiento de requerimientos utilizada principalmente por las
metodologías agiles, como es el caso de XP o SCRUM, en general se puede definir
como una descripción, corta y sencilla de una funcionalidad desde el punto de
vista del cliente.
Las historias de
usuario son definiciones de alto nivel de un requerimiento, el usuario describe
todas las funcionalidades que considera necesarias con el fin de cumplir con
sus necesidades de negocio, en general presentan una estructura narrativa.
Las historias de
usuario cuentan con tres componentes principales:
- Ficha (Index card)
Dentro de la ficha se especifica de forma muy concisa el
requerimiento del cliente, de esta forma permite generar un acuerdo entre los
aspectos básicos del requerimiento, mantener un recuento de los requerimientos
recopilados y priorizar los requerimientos de acuerdo a su relevancia.
Nombre del proyecto
|
ID
Ficha
|
Descripción:
|
|
Prioridad
|
Estimación
|
Tabla 1 Parte frontal ficha. Fuente: (Kavhita & Sunitha, 2011, p. 126)
Test de
aceptación:
|
Test
1:
Test
2:
Test 3:
|
Tabla 2 Parte posterior
ficha. Fuente: (Kavhita & Sunitha, 2011, p. 126)
- Conversación
El foco de la historia de usuario se ubica en la discusión directa
con el cliente con el fin de clarificar e identificar las funcionalidades
requeridas para satisfacer sus necesidades y expectativas
- Confirmación:
Se deben especificar las diferentes pruebas que permitan verificar
que la historia de usuario fue completamente desarrollada y el resultado se
ajusta a las necesidades del cliente.
Las historias
de usuario deben centrarse en la identificación de los puntos o criterios de
validación, desde un principio se debe hacer hincapié en definir las pruebas
que permitirán validar que la historia de usuario fue desarrollada acorde a los
requerimientos del cliente.
Con el fin de
asegurar la validez y efectividad de una historia de usuario es conveniente seguir
el modelo INVEST, según este modelo una historia de usuario debe ser:
·
Independiente
Se debe evitar la dependencia entre diferentes historias, debe ser
posible abordar una historia de usuario determinada de forma independiente de
las otras historias existentes.
·
Negociable
Dado que la descripción de la historia de usuario es concisa, los
detalles de la definición son negociables, en la fase de conversación se
requiere que las partes discutan y negocien la implementación de las
funcionalidades listadas y generen acuerdos.
·
Valiosa
La historia de usuario debe presentar valor para los clientes y
usuarios involucrados, se debe evitar especificar historias de usuario
relacionadas con aspectos puntuales de la tecnología de la solución, el foco
debe mantenerse en las funcionalidades y las necesidades de los clientes.
·
Estimable
La historia de usuario debe ser especificada de forma tal que el
equipo de desarrolladores pueda estimar, aunque sea de forma muy general, el
tiempo requerido para la implementación de la historia.
·
Corta
La historia de usuario debe tener un tamaño que le permita ser
implementada de forma eficiente, historias demasiado extensas deben ser
divididas en historias más pequeñas, se debe evitar definir historias demasiado
cortas que dificulten su implementación.
·
Verificable
Las historias deben contar con pruebas que permitan validar su
completo y correcto desarrollo.
Las historias de usuario ofrecen múltiples ventajas para los equipos de desarrollo que enfocan sus proyectos en ofrecer soluciones enfocadas en la participación de los usuarios, con el objetivo de lograr resultados alineados plenamente con las necesidades del negocio. El éxito de los proyectos es alcanzado al hacer hincapié en la comunicación constante y el apoyo entre desarrollado y cliente.
[1] Kavitha, C. R., & Sunitha, M. T.
(2011). Requirement gathering for small projects using agile methods. IJCA
Special Issue on “Computational Science - New Dimensions & Perspectives”
, 122 - 128. Recuperado el 05 de mayo de 2014 de la pagina web: http://citeseerx.ist.psu.edu/viewdoc/download?rep=rep1&type=pdf&doi=10.1.1.206.5005
[3] Cohn, M. User stories applied for agile software development. Addison- Wesley. 17 –
28.
No hay comentarios:
Publicar un comentario