Historias de usuario

umh2818-TADS

Vericables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente son
vericables. Cuando sea posible, la vericacin debe automatizarse, de manera que pueda ser vericada en cada entrega del proyecto.

Una historia de usuario es una representacin de un

requisito escrito en una o dos frases utilizando el lenguaje comn del usuario. Las historias de usuario son utilizadas en las metodologas de desarrollo giles para la
especicacin de requisitos (acompaadas de las discusiones con los usuarios y las pruebas de validacin). Cada
historia de usuario debe ser limitada, sta debera poderse escribir sobre una nota adhesiva pequea. Dentro de la
metodologa XP las historias de usuario deben ser escritas
por los clientes.

Las iniciales de estas caractersticas, con sus nombres en

ingls, forman la palabra INVEST, que signica inversin. Esto es porque toda Historia de Usuario es, si se
construye adecuadamente, una buena inversin.

Las historias de usuario son una forma rpida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir 2 Uso
de mucho tiempo para administrarlos. Las historias de
usuario permiten responder rpidamente a los requisitos Las historias de usuario conforman la parte central de
cambiantes.
muchas metodologas de desarrollo gil, tales como XP;
Estas denen lo que se debe construir en el proyecto de
software, tienen una prioridad asociada denida por el
cliente de manera de indicar cuales son las ms impor1 Caractersticas
tantes para el resultado nal, sern divididas en tareas y
su tiempo ser estimado por los desarrolladores. GeneLas historias de usuario deben ser:
ralmente se espera que la estimacin de tiempo de cada
historia de usuario se site entre unas 10 horas y un par
Independientes unas de otras: De ser necesario, de semanas. Estimaciones mayores a dos semanas son incombinar las historias dependientes o buscar otra dicativo de que la historia es muy compleja y debe ser
forma de dividir las historias de manera que resulten dividida en varias historias.
independientes.
Al momento de implementar las historias, los desarro Negociables: La historia en si misma no es lo su- lladores deben tener la posibilidad de discutirlas con los
cientemente explcita como para considerarse un clientes. El estilo sucinto de las historias podra dicultar
contrato, la discusin con los usuarios debe permitir su interpretacin, podra requerir conocimientos de base
esclarecer su alcance y ste debe dejarse explcito sobre el modelo o podra haber cambiado desde que fue
bajo la forma de pruebas de validacin.
escrita.
Valoradas por los clientes o usuarios: Los intereses
de los clientes y de los usuarios no siempre coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos ms que para el desarrollador.

Cada historia de usuario debe tener en algn momento

pruebas de validacin asociadas, lo que permitir al desarrollador, y ms tarde al cliente, vericar si la historia ha
sido completada. Como no se dispone de una formulacin
de requisitos precisa, la ausencia de pruebas de validacin
concertadas abre la posibilidad de discusiones largas y no
Estimables: Un resultado de la discusin de una his- constructivas al momento de la entrega del producto.
toria de usuario es la estimacin del tiempo que tomar completarla. Esto permite estimar el tiempo Si bien el estilo puede ser libre, la historia de usuario debe
responder a tres preguntas: Quin se benecia?, qu se
total del proyecto.
quiere? y cul es el benecio? Por ello, algunos autores[1]
Pequeas: Las historias muy largas son difciles de recomiendan redactar las historias de usuario segn el
estimar e imponen restricciones sobre la planica- formato:
cin de un desarrollo iterativo. Generalmente se reComo (rol) quiero (algo) para poder (benecomienda la consolidacin de historias muy cortas
cio).
en una sola historia.
1

Benecios
Al ser muy corta, sta representa requisitos del modelo de negocio que pueden implementarse rpidamente (das o semanas)
Necesitan poco mantenimiento
Mantienen una relacin cercana con el cliente
Permite dividir los proyectos en pequeas entregas
Permite estimar fcilmente el esfuerzo de desarrollo
Es ideal para proyectos con requisitos voltiles o no
muy claros

Limitaciones
Sin pruebas de validacin pueden quedar abiertas a
distintas interpretaciones haciendo difcil utilizarlas
como base para un contrato
Se requiere un contacto permanente con el cliente
durante el proyecto lo cual puede ser difcil o costoso
Pueden resultar difciles las pruebas de usuario, que
slo se ven en las metodologas SCRUM para escalar a proyectos grandes
Requiere desarrolladores muy competentes

Referencias

[1] Mike Cohn, User Stories Applied, 2004, Addison Wesley, ISBN 0-321-20568-5

Bibliografa
Daniel H. Steinberg and Daniel W. Palmer: Extreme Software Engineering, Pearson Education, Inc.,
ISBN 0-13-047381-2
Mike Cohn: Agile Estimating and Planning, 2006,
Prentice Hall, ISBN 0-13-147941-5

Vase tambin
Programacin extrema
Scrum
Ingeniera de software

VASE TAMBIN

Origen del texto y las imgenes, colaboradores y licencias

8.1

Texto

Historias de usuario Fuente: https://es.wikipedia.org/wiki/Historias_de_usuario?oldid=86131971 Colaboradores: Ascnder, CEM-bot,

Pablotortorella, Juan.palacio, TXiKiBoT, VolkovBot, Ezarate, Luckas-bot, Sirgui, Jkbw, SassoBot, PatruBOT, Dinamik-bot, EmausBot,
ZroBot, WikitanvirBot, KLBot2, Jarould y Annimos: 18

8.2

Imgenes

8.3

Licencia del contenido

Creative Commons Attribution-Share Alike 3.0