En el desarrollo tradicional de software se busca especificar los requisitos en una etapa bien definida y además que se pueda describir las características del producto en una documentación detalla, lo que debería servir como especificaciones invariables durante el desarrollo del software. Sin embargo ante la dinámica en la que actúan hoy en día las empresas, se ha visto que los requerimientos también van cambiando demostrando así la necesidad de que los requisitos también sean adaptables. Ante esta situación el desarrollo ágil se muestra como una alternativa, ya que, en base a la generación de entregables en iteraciones cortas es posible garantizar la generación del valor para los usuarios. En ese sentido es necesario adaptar alguna otra alternativa para obtener los requisitos, es así, que las historias de usuario se muestran adecuadas para cumplir esta tarea permitiendo mejorar la colaboración del equipo con todos los implicados del proyecto y generando la posibilidad de la tolerancia al cambio.

1. Sesiones de agilismo
Historias de usuario
y la especificación de requisitos
Marco Avendaño
Agile La Paz

2. Expositor
 Marco Avendaño
 Fundador de Agile La Paz
 @agilelapaz
 agilelapaz@gmail.com
 www.facebook.com/agilelapaz/

3. Introducción

4. Desarrollo de software
Negocio Desarrollo

5. Desarrollo tradicional

6. Work Breakdown Structure (WBS)
Descomposición del trabajo

7.  Obligatorio, fijo, difícil de
cambiar.
 Centrada en las
característica, en lugar del
valor.
 Especifica el qué, en lugar
del por qué.
 Costoso.
Los requerimientos

8. Alternativa

9. Alternativa a WBS
Definir el plan del proyecto en términos de lo que será entregado en lugar de qué pasos de trabajo se llevará a
cabo.

10. Opciones
Use Cases Requirements Stories
Goal capture a behavior
establish a
contract
generate
conversation
Scope
a process
"day in the life"
everything a single activity
Format numbered bullets specifications a single sentence
Completeness
locked, changes
may
impact entire
process
locked, require
scope
change and
approvals
open for
negotiation
and refinements
Language structured, flows precise, technical
simple,
comprehensible

11.  Requisitos por escrito
 Pueden ser pensados, revisados y editados.
 Proporciona un registro permanente.
 Se comparten más fácilmente con grupos de personas.
 Consume mucho tiempo para producirlos.
 Pueden ser mal interpretados.
 Requisitos verbales
 Retroalimentación instantánea y clarificación.
 Intercambio de información.
 Más fácil de aclarar y obtener un entendimiento común.
 Más fácilmente adaptado a cualquier nueva información conocida en el
momento.
 Puede generar ideas sobre problemas y oportunidades.
Requerimientos y la comunicación

12. Modelo de comunicación
Agile Software Development: Communicating, Cooperating Teams
By Alistair Cockburn - Aug 10, 2009

13. Agilismo

14. Manifiesto ágil

15. Triangulo de hierro

16. Entrega de valor

17. Scrum

18. Componentes

19. Framework

20. ¿Cómo se genera el Product
Backlog?
Sprint Backlog

21. Items del Product Backlog

22.  Una lista de todos los trabajos deseados en el proyecto “los
requisitos“.
 Propiedad, administrado y priorizado por el Product Owner.
 Items son estimados por el equipo.
 Se pueden volver a priorizados al inicio de cada iteración.
 Expresados de tal manera que cada ítem tiene valor para los
usuarios o clientes del producto.
 Algunos equipos también optan por incluir mejoras en los
procesos, bugs y correcciones de la deuda técnica.
Product Backlog

23. Moderador
Estima Coste
Estima Valor
Roles y estimación

24. Historias de
usuario

25. Historias, ¿Qué son?

26. Los “papelitos”

27.  Proporcionan un “enfoque
ligero” para gestionar los
requisitos de un sistema.
 Es una pequeña pieza de
funcionalidad que adiciona
valor al negocio.
 Es una promesa para
entablar conversación..
¿Qué son?

28.  No es un documento de
requerimientos.
 No es un caso de uso.
 No es un documento de
diseño técnico.
 No son escenarios.
 No es reporte de bugs.
¿Qué NO son?

29.  El software está escrito en
C++.
 La base de datos tendrá un
pool de conexiones.
Las anti historias

30.  Centrado en el usuario: lo que es importante para el cliente.
 Historia: El Poder de la Narrativa.
 Prestamos más atención a las historias que a los hechos.
 Una historia dibuja una imagen, y una imagen vale mas que
mil palabras.
 Centrado en el beneficio, el valor, lo importante:
 Define Criterios de Aceptación ANTES de implementar.
 Apoya la "extracción" de información según sea necesario.
 Desarrollo iterativo.
Características

31. Propiciando la colaboración

32. 1. Card
• Escrito en una tarjeta
(Card).
2. Conversation
• Detalles capturados en
las conversaciones.
3. Confirmation
• Los criterios de
aceptación confirman
que la historia esta
realizada (Done).
Las 3 C’s
Como usuario, puedo acceder a
la intranet, para colaborar con
toda la organización.
¿Qué hay de las
cuentas expiradas?
¿Cuántos intentos
se tiene para
ingresar?
• Cuentas expiradas no acceden.
• Después de 3 intentos la
cuenta es bloqueada.

33. Estructura
Como lector del Blog
Quiero suscribirme al Blog
Para poder realizar
comentarios a las entradas de
mi interés
Rol de usuario,
Persona ¿Quien?
Función deseada
¿Qué?
Resultado final ¿Para
qué?

34.  Definen los límites de la historia.
 Ayudan al Product Owner a responder lo que se necesita para
que esta característica proporcione valor.
 Ayudar al equipo a obtener un entendimiento compartido de la
historia.
 Ayuda a los desarrolladores y testers a obtener pruebas.
 Ayuda a los desarrolladores a saber cuándo dejar de agregar
más funcionalidad a una historia.
Criterios de aceptación

35. ¿Las historias son requerimientos?

36. INVEST

37.  Debe ser autónoma, de tal
manera que no haya una
dependencia inherente a
otra historia de usuario.
Independent
As a user
I want to pay bills online
So that I don’t have to write
checks

38.  Las historias de usuarios,
hasta que forman parte de
un Sprint, siempre se
pueden cambiar y volver a
escribir.
Negotiable
As a driver
I want to get directions to
conveniently located stores
So that I get there quickly
Acceptance Criteria:
Show locations on map
Show locations on Google
Maps

39.  Debe proporcionar valor al
usuario final y al negocio.
Valuable
As a customer
I want 75% off all purchases
So I can save money
Claramente existe valor
para el usuario, pero
existe valor para el
Negocio?

40.  Siempre se debe ser capaz
de estimar el tamaño de una
historia de usuario.
Estimable

41.  Debe ser pequeña en
esfuerzo, generalmente
representando no más de 2-
3 personas/semana de
trabajo.
 Una historia que es más
grande va a tener más
errores asociados a la
estimación y alcance.
Small

42.  Su descripción debe
proporcionar la información
necesaria para hacer posible
el desarrollo de pruebas.
Testable

43. Historias
grandes

44. Epics, Features, Stories

45. Demasiado grandes

46.  No todos los items del
Backlog son historias de
usuario, pero todas las
historias de usuario deberían
ser “tajadas verticales”.
Slice

47. Proceso de planificación

48. Niveles de planificación

49. Planificación de la Iteración
• El equipo selecciona historias del Product Backlog s que pueden
comprometerse a completar.
• Se crea el Sprint Backlog:
• Se identifican tareas y cada una es estimada en horas.
• Las tareas y sus estimaciones se realizan de manera
colaborativa.

50. Referencias bibliográficas
 User Stories Applied, Mike
Cohn.

51. Sesiones de agilismo
Historias de usuario
y la especificación de requisitos
Marco Avendaño
Agile La Paz