El documento aborda los patrones en la toma de requisitos en proyectos ágiles, enfocándose en la metodología Scrum y la categorización de requisitos según el modelo FURPS+. Se describen técnicas para descomponer historias de usuario y la importancia de criterios de aceptación, así como la identificación de riesgos y la mejora continua en las prácticas ágiles. Finalmente, se enfatiza la necesidad de personalizar los procesos y reflexionar sobre los resultados en las retrospectivas para optimizar la gestión de proyectos.

1. Patrones en la toma de
requisitos en proyectos
ágiles
Roberto Canales Mora
@rcanalesmora
CAS2013 / Octubre 2013
1

3. Autentia
• > de 10 años
• < 25 personas
• Objetivo:
– Disfrutar del camino.
– Transformar el sector.
3

4. Un todo
4
www.autentia.com

5. Si he logrado ver más lejos es porque me apoyo en
hombros de gigantes. Isaac Newton
6
www.autentia.com

6. Modelo rápido de Scrum
7
www.autentia.com

7. Historias de usuario
• 3 C´s: Card, Conversation, confirmation.
• As {role} I want {what} so {benefit}
• Yo como usuario quiero poder encontrar viajes
por origen/destino y fechas a mi gusto y así
poder comparar las condiciones con otras
ofertas ajenas a este sistema.
Épica
Chore
Spike
Historia
Tema
8
www.autentia.com

8. Categorización de requisitos
• Larman define los requisitos FURPS+:
–
–
–
–
–
Funcionalidad - ¿qué debe hacer el sistema?
Usabilidad - ¿qué facilidades proporcionará?
Fiabilidad (Reliability) - ¿cómo tolerará fallos?
Rendimiento - ¿qué carga soportará?
Soporte - ¿qué capacidades de mantenimiento tendrá?
– + (otros requisitos)
•
•
•
•
•
Implementación - ¿cómo debe hacerse?
Interfaz - ¿cómo interactuará con otros sistemas?
Operaciones - ¿cómo se pondrá en marcha?
Empaquetamiento - ¿cómo se distribuirá?. Portabilidad.
Legales - ¿qué comprometemos con su puesta en marcha?
UML y Patrones: Graig Larman
9
www.autentia.com

9. Requisitos en ejecución: DONE
• Incluye más tareas que
puramente funcionales
http://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference
10
www.autentia.com

10. BDD en circulo TDD
11
www.autentia.com

11. DSLs de BDD
Feature: Aquí es donde indicamos el nombre de la característica a probar.
Scenario: Esta "keyword" describe los distintos escenarios que van a probar las diferentes
posibilidades.
Given (Dado) : El propósito de los "Dado" es el de poner al sistema en el estado deseado para pasar
los test deseados, antes de que el usuario ( o un sistema externo ), interactúe con el sistema.
When ( Cuando ) : En este caso el propósito de los "Cuando" es el describir la acción que realiza el
usuario, la cual vamos a probar.
Then ( Entonces ) : El propósito de los "Entonces" es observar los resultados, estas observaciones
han de ser realizadas desde el punto de vista de negocio y el valor para el usuario. Estas
observaciones también deben de estar en algún sitio visible para el usuario, no en una base de
datos o capas inferiores del sistema.
And, But ( Y, Pero ): Estas "keywords" están destinadas a aumentar la legibilidad y pueden ser
usadas en vez de definir repetidas veces cualquiera de las anteriores.
12
www.autentia.com

12. Técnicas y Pruebas
13
www.autentia.com

13. Pero algo no funciona
14
www.autentia.com

14. 15
www.autentia.com

15. Construcción de métodos
16
www.autentia.com

16. Construcción de métodos
17
www.autentia.com

17. 18
www.autentia.com

18. 19
www.autentia.com

19. 20
www.autentia.com

20. Construcción de métodos
21
www.autentia.com

21. Construcción de métodos
22
www.autentia.com

22. Agrupación por bloques
• Demasiadas historias agobia y hace perder perspectiva.
23
www.autentia.com

23. Matices: Puzzles VS Misterios
– Puzzle: Un puzzle se puede resolver con suficiente capacidad analítica e
información.
– Misterio: no tienen una única respuesta correcta. Hasta que no demos
con ella no sabremos que es válida.
24
www.autentia.com

24. Agrupación por bloques
• Por ventanas de tiempo.
• Limitaciones por estado en historias delegadas.
25
www.autentia.com

25. Identificación de Spikes
26
www.autentia.com

26. Acotando Funcionalidad por estado
27
www.autentia.com

27. Patrón de tratamiento de historias
28
www.autentia.com

28. Patrones de descomposición
• Las historias deben tener un tamaño similar.
• Podemos utilizar patrones para descomponer las historias.
• Patrones sencillos:
– historias de usuario con conjunciones y conectores.
– historias de usuario con palabras genéricas.
– historias de usuario con criterios de aceptación.
– historias de usuario con análisis de timeline.
http://www.agilelearninglabs.com/2013/05/new-quick-reference-guide-for-splitting-user-stories/
29
www.autentia.com

29. Conjunciones y conectores
• "Como usuario anónimo quiero poder encontrar tutoriales y artículos para poder aplicarlos a
mi crecimiento tecnológico".
• Vemos que existe una conjunción "y" por lo que dicha historia se podría dividir en dos:
– "Como usuario anónimo quiero poder encontrar tutoriales para poder resolver
dudas tecnológicas"
– "Como usuario anónimo quiero poder encontrar artículos para poder ampliar
mi conocimiento tecnológico"
30
www.autentia.com

30. Uso de palabras genéricas
• "Como usuario anónimo quiero poder encontrar información para poder aplicarlos a mi
crecimiento tecnológico".
• Estas palabras genéricas “como información” se deberán poder dividir en varias palabras o
términos más específicos como por ejemplo, tutoriales y artículos:
– "Como usuario anónimo quiero poder encontrar tutoriales para poder
resolver dudas tecnológicas"
– "Como usuario anónimo quiero poder encontrar artículos para poder ampliar
mi conocimiento tecnológico".
31
www.autentia.com

31. Con criterios de aceptación
• "Como usuario anónimo quiero poder encontrar artículos a través de un buscador para poder
y así ampliar mi conocimiento tecnológico".
• Se pueden definir una serie de criterios de aceptación como por ejemplo:
– Tienen que poder filtrarse en inglés y español.
– Tienen que estar categorizados como técnico o negocio.
• Con estos criterios de aceptación ya definidos se podría dividir la historia en varias más
sencillas quedando de esta forma:
– "Como usuario anónimo quiero poder encontrar artículos por idioma".
– "Como usuario anónimo quiero poder encontrar artículos por categoría".
32
www.autentia.com

32. Por análisis de TimeLine
•
Ver cada historia de usuario como un escenario a modo de workflow donde el actor puede "pasar" por
varios estados o realizar diferentes acciones.
•
Cada una de estas acciones/estados, que dependen cronológicamente unos de otros, se pueden
considerar como historias más sencillas y son sensibles a división.
– "Como usuario anónimo quiero poder encontrar tutoriales para poder resolver dudas
tecnológicas.
Se pueden extraer:
– Como usuario quiero poder identificarme en el sistema para poder descargarme el
código fuente del tutorial.
– Como usuario quiero descargarme el tutorial en pdf para imprimirlo".
33
www.autentia.com

33. Ejemplo: por análisis de TimeLine
•
•
•
•
•
•
•
•
Yo como usuario quiero poder encontrar viajes por origen/destino y fechas a mi gusto y así poder comparar las
condiciones con otras ofertas ajenas a este sistema.
Yo como usuario quiero poder filtrar los viajes por precio y así intentar encontrar fácilmente el más acorde a mi
economía.
Yo como usuario quiero poder registrarme en el sistema y así simplificar los pasos de mi compra futura.
Yo como usuario quiero poder formalizar mi pedido siendo capaz de aportar mis datos en el momento de la compra y
así no tener que registrarme si no quiero comprar.
Yo como usuario quiero poder guardar la búsqueda en mis favoritos y así no tener que introducirla repetidamente en
distintos días hasta encontrar un precio de oferta.
Yo como usuario quiero poder formalizar mi pedido y pagarlo con Visa y así utilizar mi medio de pago común.
Yo como usuario quiero poder formalizar mi pedido y dejarlo pendiente de pago en oficina física y así no tener que
utilizar un medio de pago que me da miedo.
Yo como usuario quiero poder recuperar la documentación de mi viaje en un momento distinto al formalizado para
tener copia de documentos o imprimirlos cuando me apetezca.
34
www.autentia.com

34. Otras técnicas de descomposición
http://trailridgeconsulting.com/files/user-story-primer.pdf
36
www.autentia.com

35. Malos olores
•
•
•
•
•
•
•
Cambio de formulación actor humano – actor sistema.
La estimación de una historia depende de otra.
Dedicar más tiempo a escribir una historia que a hablar sobre ella.
Detallar historias muy lejanas en el tiempo.
Añadir funcionalidad (desarrolladores) que no está incluida en los criterios de aceptación.
Reuniones diarias donde la actividad de la persona no está guiada por una historia.
No querer jerarquizar la prioridad de historias.
37
www.autentia.com

36. Definición de riesgos
•
•
•
•
Definición de riesgos base.
Agrupación en categorías.
Descripción de criterios cualitativos.
Utilización de métricas cuantitativas
para estimar.
• Búsqueda de contramedidas en
puntos vitales.
38
www.autentia.com

37. REM: re-aprovechamiento
39
www.autentia.com

38. 40
www.autentia.com

39. 41
www.autentia.com

40. Visión cuantitativa y cualitativa
42
www.autentia.com

41. 43
www.autentia.com

42. 44
www.autentia.com

43. 45
www.autentia.com

44. Los 5 por qué´s
46
www.autentia.com

45. REM: Visibilidad
47
www.autentia.com

46. REM: Visibilidad
48
www.autentia.com

47. REM: Todo junto
• Repetir en cada retrospectiva.
• Personalizar a la necesidad de cada organización.
49
www.autentia.com

48. Resultados por proyecto
50
www.autentia.com

49. Turno de preguntas
51

50. Muchas gracias !!!
52