Taller de Historias de Usuario, impartido en Biko. Teoría + práctica.

1. Historias de Usuario

3. ¿Por qué las “historias de usuario”? Requisitos Los RQs no están nunca definidos todos de antemano. Aunque lo estuviesen, NO podrían recogerse de manera PER-FEC-TA. Enfoque en los aspectos relevantes del momento, aplazando los detalles al momento oportuno. Promoción del desarrollo oportunista (RQs emergentes).

4. ¿Por qué las “historias de usuario”? Planificación Los proyectos de SW no son perfectamente predecibles Separación de la estimación del tamaño (puntos) de la del tiempo (horas). Buen tamaño para planificar Funcionan bien para el trabajo iterativo

5. ¿Qué son las historias de usuario? (y qué no son) La historias de usuario… son la descripción de la funcionalidad de un software, expresada de forma valiosa para las partes involucradas y útil para la gestión de proyectos de elevada incertidumbre.

7. Un usuario puede poner los libros en el carrito y sucesivamente comprarlos.

8. Un usuario puede escoger acompañar el envío de un libro con un billete y su propio mensaje

9. Un supervisor puede ver un informe de las ventas realizadas en el día.

11. Como presidente de España Necesito atacar Irak Para encontrar las armas de destrucción masiva

12. NO ODIES AL USUARIO debemos determinar por quélo necesitan COLABORACIÓN

13. Ejemplo: “Como…” y “Para” son determinantes Como… Quiero… Para… salir en el Guinnes un buen pescado Compartirlo en una cenita romántica sacar una gran nota en mi examen

14. Agile Inception: cómo nacen las historias Las historias deben ser resultado de la colaboración máxima entre cliente y equipo Evolucionan a lo largo de la vida del proyecto.

15. Principales características Las historias de usuario incluyen: Card. Una breve descripción escrita, como recordatorio Conversation. Una valiosa conversación, para asegurar el entendimiento y acordar el objetivo Confirmation. Unos tests funcionales, para fijar algún detalle relevante y limitar el alcance

16. Título, descripciónCard, Conversation, Confirmation El título (o descripción) de las historias de usuario es una breve frase que resume su principal objetivo y es útil como recordatorio de la correspondiente conversación. Es habitual emplear el siguiente formato: Como [rol], quiero [característica], para [valor de negocio]. Formato útil, pero no garantiza que se estén elaborando historias de calidad. Buscar un buen título estimula la conversación y ayuda a cuestionarse. Modelado de los roles de usuario, “personajes”, etc.

18. COMO periodista de la DGCOM de GN, QUIERO clasificar las noticias del TAV mediante un nuevo tema de la taxonomía, PARA mostrarlas automáticamente en la portada del portal del TAV

20. Glosario ¿sería buena idea tener una lista de términos de negocio, explicados y accesibles?

22. Se pueden añadir/mejorar sobre la marcha, aunque mejor antes de codificar. given … when … then … ¿!se podrá automatizar?! ;)

24. Cuandobusque un identificador de cuentaválido, la cuenta se muestra.

25. Cuandobusquepornumero de SS y nombreválido, la cuenta se muestra.

27. Verificar con American Express (fail).

28. Verificar con números de carta buenos, malos y parciales.

29. Verificar con una carta caducada.

30. Verificar un importe mayor de lo máximo permitido por la carta.

32. Creando las historias de usuarioI.N.V.E.S.T. Las historias de usuario bien planteadas tienen las siguientes características: Independent (independiente) Negotiable (negociable) Valuable (valiosa) Estimatable (estimable) Small (pequeña) Testable (comprobable)

34. Combinar historias

37. Creando las historias de usuarioI.N.V.E.S.T. Estimatable (estimable) El equipo puede manejarse con el alcance de la historia de usuario y proveer una estimación La estimación permite priorizar la pila de producto y planificar Problemas? Mejorar el conocimiento del dominio (ej.: más conversación) Mejorar los conocimientos técnicos (ej.: “Spike”) Reducir la complejidad (dividir una historia muy grande)

38. Creando las historias de usuarioI.N.V.E.S.T. Small (pequeña) La justa medida para poder comprender, estimar y planificar; Según la dimensión y habilidad del equipo, las tecnologías, etc. una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo. Problemas? Dividir la historia. Una historia que es más grande va a tener más errores asociados a la estimación y alcance.

39. Creando las historias de usuarioI.N.V.E.S.T. Testeable Necesitamos saber cuando terminamos una historia. No desarrollemos aquello que no podemos probar. Problemas? Dividir en historias más pequeñas. Pensar en las pruebas de aceptación.

40. “Malos ejemplos de historias” Ejercicio 1 Ejercicio Objetivo. Aprender a analizar de forma crítica una historia de usuario, sobre la base de los atributos INVEST.

42. Un usuario puedo añadir/editar/borrar múltiples CV.

43. El proceso de desarrollo producirá documentación CMMI nivel 2.

44. QUIERO desarrollar la capa de negocio de la aplicación de venta de entradas, PARA luego conectarla con la BBDD.

47. ¿Cómo comprobarlo? Hay conceptos muy ambiguos.

48. No es independienteporquela interfaz abarca el sistema entero.

49. Un usuario puede añadir/editar/borrar múltiples CV.

50. Fácilmente divisible en funcionalidades independientes más pequeñas.

51. El proceso de desarrollo producirá documentación CMMI nivel 3.

52. Es un requerimiento no funcional

53. QUIERO desarrollar la capa de negocio de la aplicación de venta de entradas, PARA luego conectarla con la BBDD.

54. No aporta valor al usuario.

55. No permite una entrega incremental de funcionalidad disponible para el usuario. En general: historia ≠ capa de software.

56. Como usuario de BigMoneyJobs, QUIERO encontrar un trabajo.

59. Ahhh… también con electrónicas (VISA electron)

60. Emplear el TPV de mi banco.

62. algunas historias dependen del uso del mismo TPV

63. << La primera me costará más, no he usado nunca un TPV… >>Muy similar Mismo TPV

64. “Independent” user-stories Ejercicio 2 Solución Objetivo. Enfrentar un típico caso de dependencia entre historias de usuario. Aprender alguna estrategia para resolver este tipo de problemas. Debatir las implicaciones de abordar este problema de una forma u otra.

65. Soluciones a la dependencia Ejercicio 2 Algunas posibles estrategias para resolver los problemas de dependencia: Combinar las historias dependientes en una única historia independiente La empresa puede pagar un anuncio con las cartas de crédito tradicionales (VISA, Mastercard, American Express). Separar las historias de otra manera Separar las historias introduciendo un “spike” Investigar el uso del nuevo TPV. Separar las historias bajo otro punto de vista La empresa puede pagar un anuncio con una carta de crédito (ej.: VISA). La empresa puede pagar un anuncio con otras cartas adicionales (ej.: Mastercard, American Express). Hacer una doble estimación de las historias de usuario dependientes.

66. “Valuable” user-stories Ejercicio 3 Ejercicio Objetivo. Aprender a expresar los conceptos y las necesidades técnicas de una forma más comprensible y valiosa para el cliente.

68. La gestión de los errores y del logging se llevarán a cabo mediante un conjunto de clases comunes a todo el portal.

69. Como usuario, quiero disponer de un API para hacer búsquedas

70. Como usuario, quiero tener un gadget de escritorio para buscar por nombre¿Cómo podríamos darle la vuelta?

71. “Valuable” user-stories Ejercicio 3 Solución Objetivo. Aprender a expresar los conceptos y las necesidades técnicas de una forma más comprensible y valiosa para el cliente.

72. “Valuable” user-storiesEjercicio 3 Ejemplos de posibles solución Las conexiones a la BBDD serán mediadas por un connection pool. La aplicación podrá ser usada de forma concurrente por 15 usuarios con una licencia de BBDD de 5 usuarios.

73. “Valuable” user-storiesEjercicio 3 Ejemplos de posible solución La gestión de los errores y del logging se llevarán a cabo mediante un conjunto de clases comunes a todo el portal. Los mensajes de error serán presentados al usuario y registrados para posteriores análisis de una forma coherente.

74. Casos particulares: épicas Las épicas son historias de usuario “grandes”, por su tamaño (puntos) y/o dedicación (horas). Proporcionan una visión de alto nivel. Valiosas para la planificación inicial del sistema. Generalmente incluyen trabajo para varias iteraciones. Deben ser divididas en más pequeñas.

75. Ejemplos: “Que la aplicación sea bonita” “Que el rendimiento sea bueno” ¿ Llevarlo al DoD de las historias? ¿ Realizar tareas independientes? Casos particulares: RQs no funcionales

76. Casos particulares: RQs técnicos El equipo de desarrollo puede necesitar definir trabajos no funcionales ¿rendimiento? ¿desarrollos estructurales? Muchas veces son tareas necesarias, ¿por qué trabajarlas como historia? “Necesito configurar el maven con la integración continua”

77. Historias de usuario y Scrum La “userstories” son una herramienta surgida de Extreme Programming (XP). Se han vuelto un estándar de-facto para Scrum; aunque Scrum sólo exige una “pila de producto” compuesta de “tareas”. Reunión de “planificación de producto” Conversación con el cliente, visión del proyecto, valorar alternativas, esbozar soluciones, etc. Se crean épicas/historias (Card, Conversation, Confirmation). Reunión de “planificacion de sprint” Planificas en base a historias estimadas Definition of Done (DoD) Deberá pasar los test de aceptación

78. Propiedades Prioridad Dependencias Backlog plano, o mapa(http://www.agileproductdesign.com/blog/the_new_backlog.html) Valor de negocio (¿ROI?)

79. Historias: alineadas con el Manifiesto Ágil Manifiesto por el Desarrollo Ágil de Software Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar: Individuos e interacciones, sobre procesos y herramientas Software que funciona, sobre documentación exhaustiva Colaboración con el cliente, sobre negociación de contratos Responder ante el cambio, sobre seguimiento de un plan Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda.

81. “Twitter. Historias de Usuario” Ejercicio 4 Ejercicio Objetivo. Practicar la técnica de las historias de usuario sobre un caso real. Crear ocasión de debate.

83. Focusonthedelivery of features

85. Indicadores PRIORIDAD: Prioridad en la implementación de una historia de usuario respecto al resto. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW: M – Must, se debe completar este requerimiento para finalizar el proyecto S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él. C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto. W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)

86. Historias de usuario vs. casos de uso