Patrones de toma de requisitos en proyectos ágiles en la Cas2013

3,355 views

Published on

En esta charla pretendía comentar cómo nos habíamos dado cuenta, en una empresa de 25 empleados, de que éramos poco homogéneos a la hora de proporcionar servicios, sobre todo en uno de los puntos vitales: definir y estimar un proyecto en base a historias y minimizar riesgos.

Un modo de conseguirlo es crear métodos para que todo el mundo vaya adquiriendo los conocimientos.

Se describieron los elementos fundamentales: épicas, historias, chores, temas, spikes, etc.

También la técnica para estimar proyectos grandes:
- Conseguir todas las historias.
- Descomponerlas en ventanas por prioridad.
- Estudiar en detalle a primera ventana (de pongamos 25).
- Estimar la primera ventana.
- Asegurarse que no hay historias (que no tenemos capacidad de detallar y estimar) que se desmadren, estudiando los posibles estados del sistema y viendo el riesgo técnico/funcional.

Para descomponer historias de usuario existen numerosos patrones que sería interesante conocer.

Otro asunto vital es "mirar el todo" y estudiar los riesgos. Describimos un método que hemos llamado Risk Evaluation Machine (REM) para hacer una gestión visual de riesgos:

Área de definición.
- Definir los riesgos entre los compañeros.
- Agruparlos por categoría (para ver solapes y los que faltan).
- Sugerir otras categorías para encontrar otros riesgos que no tenemos en la cabeza.

Máquina (área central de estudio que tiene que terminar limpia)
- Se estudia la probabilidad e impacto.
- Se cualifican y descartan los menos importantes.
- Se estudia en detalle los vitales (gran probabilidad e impacto)
- Se hacen preguntas (5 por que´s) para encontrar las causas primeras y sugerir soluciones.

Área resumen de proyecto
- Se estructuran los riesgos en un panel para cada proyecto.
- Usaremos este panel como elemento de comunicación incluso con técnicas originales como pegar globos o luces en él para que nadie ignore los riesgos.

Esta charla fue curiosa porque como lo conté no tube apenas feedback sobre el contenido pero si sobre el jefismo que transmití (no hice el discleimer inicial) :-) A nadie pareció gustarle el concepto de disciplina en un evento ágil...

Parece que la gente no entiende que nada es blanco ni es negro sino que todo tiene matices.

Me gusta la frase: Esto es Esparta haciendo referencia a la película 300: Un grupo pequeño, de élite, tiene cada miembro una gran capacidad pero tiene una gran disciplina colectiva, que es lo que les da el poder. Si entras en los SWAT ya tendrás grandes destrezas que seguro que mejoraras. Por muy bueno que sea el grupo será mejor cuanto más compenetrados estén. Todo el mundo asumirá que hay una disciplina. Los mismos métodos que se usan el un grupo de élite (donde alguien voluntariamente ha querido entrar) no se pueden usar en otros contextos.

Obviamente hay que adaptar el comportamiento al contexto.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,355
On SlideShare
0
From Embeds
0
Number of Embeds
1,265
Actions
Shares
0
Downloads
1
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Patrones de toma de requisitos en proyectos ágiles en la Cas2013

  1. 1. Patrones en la toma de requisitos en proyectos ágiles Roberto Canales Mora @rcanalesmora CAS2013 / Octubre 2013 1
  2. 2. Autentia • > de 10 años • < 25 personas • Objetivo: – Disfrutar del camino. – Transformar el sector. 3
  3. 3. Un todo 4 www.autentia.com
  4. 4. Si he logrado ver más lejos es porque me apoyo en hombros de gigantes. Isaac Newton 6 www.autentia.com
  5. 5. Modelo rápido de Scrum 7 www.autentia.com
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. BDD en circulo TDD 11 www.autentia.com
  10. 10. 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
  11. 11. Técnicas y Pruebas 13 www.autentia.com
  12. 12. Pero algo no funciona 14 www.autentia.com
  13. 13. 15 www.autentia.com
  14. 14. Construcción de métodos 16 www.autentia.com
  15. 15. Construcción de métodos 17 www.autentia.com
  16. 16. 18 www.autentia.com
  17. 17. 19 www.autentia.com
  18. 18. 20 www.autentia.com
  19. 19. Construcción de métodos 21 www.autentia.com
  20. 20. Construcción de métodos 22 www.autentia.com
  21. 21. Agrupación por bloques • Demasiadas historias agobia y hace perder perspectiva. 23 www.autentia.com
  22. 22. 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
  23. 23. Agrupación por bloques • Por ventanas de tiempo. • Limitaciones por estado en historias delegadas. 25 www.autentia.com
  24. 24. Identificación de Spikes 26 www.autentia.com
  25. 25. Acotando Funcionalidad por estado 27 www.autentia.com
  26. 26. Patrón de tratamiento de historias 28 www.autentia.com
  27. 27. 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
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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
  33. 33. Otras técnicas de descomposición http://trailridgeconsulting.com/files/user-story-primer.pdf 36 www.autentia.com
  34. 34. 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
  35. 35. 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
  36. 36. REM: re-aprovechamiento 39 www.autentia.com
  37. 37. 40 www.autentia.com
  38. 38. 41 www.autentia.com
  39. 39. Visión cuantitativa y cualitativa 42 www.autentia.com
  40. 40. 43 www.autentia.com
  41. 41. 44 www.autentia.com
  42. 42. 45 www.autentia.com
  43. 43. Los 5 por qué´s 46 www.autentia.com
  44. 44. REM: Visibilidad 47 www.autentia.com
  45. 45. REM: Visibilidad 48 www.autentia.com
  46. 46. REM: Todo junto • Repetir en cada retrospectiva. • Personalizar a la necesidad de cada organización. 49 www.autentia.com
  47. 47. Resultados por proyecto 50 www.autentia.com
  48. 48. Turno de preguntas 51
  49. 49. Muchas gracias !!! 52

×