El documento presenta una introducción a las historias de usuario, describiéndolas como representaciones cortas de requisitos desde la perspectiva del cliente. Explica que son utilizadas en metodologías ágiles como Scrum para especificar requisitos de manera que permitan estimaciones de tiempo de desarrollo y entregas iterativas del producto. Además, incluye plantillas y lineamientos para la escritura efectiva de historias de usuario.

1. 1

2. Historias de Usuarios
 Israel Alexander Campoverde
 Eduardo Alexander León
 Josué Andrés Macas
 David Steven Pacheco
 Katty Jackeline Salinas
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Junio, 2020
Loja, Ecuador

3. Historias de Usuario
• Utilizadas en las metodologías de desarrollo ágiles para la
especificación de requisitos
• Representación de un requisito descrito de forma corta
• Escritas por el cliente utilizando un lenguaje común
• Descripciones cortas de lo que el sistema debe realizar
• Una Historia de Usuario es una carta de intención

4. Metodología XP (eXtreme Programming )
• Tiene un conjunto importante de reglas y prácticas.
Planificación
• Sustituyen a los documentos de especificación funcional, y a los “casos de
uso”
• Deben tener el detalle mínimo para una estimación poco riesgosa del
tiempo que llevará su desarrollo.
• Deben poder ser programadas en un tiempo entre una y tres semanas.

5. Metodología XP (eXtreme Programming )
Plan de entregas
• Cronograma de entregas para establecer qué historias de usuario serán
agrupadas para conformar una entrega y el orden
• Resultado de una reunión entre todos los actores del proyecto
Plan de iteraciones
• Cada historia de usuario se traduce en tareas especificas
• Para cada historia de usuario se establecen las pruebas de aceptación
• Las pruebas de aceptación que hayan fallado son analizadas para evaluar
su corrección

6. Reuniones diarias de seguimiento
(“Stand-up meeting”)
El objetivo de tener reuniones diarias es mantener la comunicación entre el
equipo, y compartir problemas y soluciones.

7. Scrum
Scrum es un proceso en el que se aplican de manera regular un conjunto de
buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto.

8. ¿Por qué crear historias de usuario?
Las historias mantienen el foco en el usuario
Las historias permiten la colaboración
Las historias impulsan soluciones creativas
Las historias crean impulso

9. Cómo escribir historias de usuario en Scrum
Ten en cuenta lo siguiente al escribir historias de usuario:
• Definición de "Hecho"
• Designa las subtareas o tareas
• Perfiles de usuario
• Pasos en orden
• comentarios
• Tiempo

10. Historias de Usuario
• Son requerimientos que expresan el problema que el sistema o producto
software debe resolver.
• Son un enfoque de requerimientos ágil que se focaliza en establecer
conversaciones acerca de las necesidades de los clientes.

11. Plantilla para realizar Historias de Usuario

12. Una historia de usuario sigue el siguiente
formato:
• Definir quién utilizara la funcionalidad a desarrollar
¿Para qué quiere usar la aplicación? ¿Qué problemas se le
presentan actualmente para resolver su necesidad?
• Especificar qué producto quiere el usuario
Se expresa en lenguaje natural y sencillo
• Para qué utilizará el producto
Definir el contexto donde surge la historia que se está creando
• Los criterios de aceptación
Qué salidas obtendremos cuando finalice el proceso de ejecución de
la funcionalidad
• Los comentarios

13. • Las Historias de Usuario son escritas a lo largo de todo el proyecto de
desarrollo
• Usualmente al comenzar un proyecto se lleva a cabo un workshop
• Los dueños del producto son responsables de que exista una pila de
producto compuesta de Historias de Usuario, pero no necesariamente son
ellos quienes deben escribirlas

14. Beneficios de las historias de usuario.
• Al ser muy corta, ésta representa requisitos del modelo de negocio que pueden
implementarse rápidamente
• Mantienen una relación cercana con el cliente
• Permite dividir los proyectos en pequeñas entregas
• Permite estimar fácilmente el esfuerzo de desarrollo
• Es adecuada para proyectos en los que los requisitos no están definidos con
claridad desde el principio.Necesitan poco mantenimiento

15. Modelo INVEST
(Independiente, Negociable, Verificable, Estimables, Pequeñas y Testeables)
INDEPENDIENTE
• Debe probarse y entregarse sin depender de otras funcionalidades
• Cuando dos historias son interdependientes se las puede unificar, siempre y
cuando sean historias pequeñas

16. Negociable
• Se establece conversaciones con el dueño del producto para convenir los
detalles de los requerimientos
• Deben ser lo suficientemente detalladas para que inviten a ser discutidas con
el usuario

17. 17
Valiosa: las historias de usuario deben aportar algún valor al usuario
final
Una forma muy eficaz de generar historias valiosas es hacer que el
cliente la escriba
Estimable: debes ser capaz de estimar los recursos necesarios para
completar cada historia de usuario. Los problemas que pueden
impedirle a los desarrolladores estimar una historia son:
falta de conocimiento del dominio, historia es muy grande

18. 18
Pequeña: Las historias de usuario deben ser simples, para que
puedan ser encargadas y priorizadas. Una buena historia debe ser
pequeña en esfuerzo, generalmente representando no más
de 2-3 personas/semana de trabajo
Verificable: Explica los criterios de verificación y aprobación, para que
el equipo los conozca y aplique cuando una historia esté completa. Si
una historia no puede ser verificada probablemente sea muy
compleja, o tenga muchas dependencias con otras historias

19. 19
Ventajas de las Historias de Usuario por sobre los documentos de
requerimientos tradicionales
 Enfatizan la comunicación verbal por sobre la escrita. El objetivo
es documentar lo menos posible en las historias de usuario.

20. 20
 Son entendidas por ambos, los clientes y/o usuarios y los equipos
de desarrollo

21. 21
 Poseen el tamaño necesario para efectuar las estimaciones

22. 22
 Sirven para trabajar en iteraciones, es decir, que no es necesario
escribir todas las historias antes de comenzar un proyecto

23. Conclusiones
• Las historias de Usuario es adecuada para proyectos en los cuales, los requisitos no
están definidos con claridad desde el principio.
• La historia de usuario es la forma que tienes de que el cliente te diga qué quiere, de
manera sencilla para que él lo exprese y tu equipo lo entienda. Se trata de una
herramienta muy eficaz para obtener el resultado deseado en la ejecución de tus
proyectos.
• Crea una estructura de entregas pequeñas del proyecto, frente a una entrega única y
total.
• Las historias de usuario nos permiten obtener y entender de una manera mas fácil
las necesidades de los clientes

24. 24
Cŕeditos
• Transparencias basadas por:
• Christopher Exposito Izquierdo & AiRam Exposito Marquez & otros
• Maria-Isabel, Sanchez Segura & Arturo, Mora-Soto

25. 25
Gracias