Formación 'user stories' biko - mayo 2011

5,544 views
5,298 views

Published on

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

Published in: Technology

Formación 'user stories' biko - mayo 2011

  1. 1. Historias de Usuario<br />
  2. 2. ¿Por qué las “historias de usuario”?<br />Comunicación<br />Entendimiento compartido del problema-solución <br /><ul><li> << Software requirements is a comunication problem >>(User Stories Applied, Cap. 1)</li></ul>Registrar funcionalidad a medias<br />Enfatizar la comunicación verbal<br />Lenguaje comprensible (libre de jerga técnica)<br />
  3. 3. ¿Por qué las “historias de usuario”?<br />Requisitos<br />Los RQs no están nunca definidos todos de antemano. Aunque lo estuviesen, NO podrían recogerse de manera PER-FEC-TA. <br />Enfoque en los aspectos relevantes del momento, aplazando los detalles al momento oportuno.<br />Promoción del desarrollo oportunista (RQs emergentes).<br />
  4. 4. ¿Por qué las “historias de usuario”?<br />Planificación<br />Los proyectos de SW no son perfectamente predecibles<br />Separación de la estimación del tamaño (puntos) de la del tiempo (horas).<br />Buen tamaño para planificar<br />Funcionan bien para el trabajo iterativo<br />
  5. 5. ¿Qué son las historias de usuario? (y qué no son)<br />La historias de usuario…<br />son la descripción de la funcionalidad de un software,<br />expresada de forma valiosa para las partes involucradas y útil para la gestión de proyectos de elevada incertidumbre.<br />
  6. 6. Ejemplos de historias de usuario<br /><ul><li>Un usuario puede buscar un libro insertando cualquier combinación de título e autor.
  7. 7. Un usuario puede poner los libros en el carrito y sucesivamente comprarlos.
  8. 8. Un usuario puede escoger acompañar el envío de un libro con un billete y su propio mensaje
  9. 9. Un supervisor puede ver un informe de las ventas realizadas en el día.
  10. 10. Un usuario puede enviar información acerca de un trabajo a una amiga vía mail.</li></li></ul><li>Recuerdos de unaconversación<br />
  11. 11. Como presidente de España<br />Necesito atacar Irak<br />Para encontrar las armas de destrucción masiva<br />
  12. 12. NO ODIES AL USUARIO<br />debemos determinar por quélo necesitan<br />COLABORACIÓN<br />
  13. 13. Ejemplo: “Como…” y “Para” son determinantes<br />Como…<br />Quiero…<br />Para…<br />salir en el Guinnes<br />un buen pescado<br />Compartirlo en una cenita romántica<br />sacar una gran nota en mi examen<br />
  14. 14. Agile Inception: cómo nacen las historias<br />Las historias deben ser resultado de la colaboración máxima entre cliente y equipo<br />Evolucionan a lo largo de la vida del proyecto.<br />
  15. 15. Principales características<br />Las historias de usuario incluyen:<br />Card. Una breve descripción escrita, como recordatorio<br />Conversation. Una valiosa conversación, para asegurar el entendimiento y acordar el objetivo <br />Confirmation. Unos tests funcionales, para fijar algún detalle relevante y limitar el alcance <br />
  16. 16. Título, descripciónCard, Conversation, Confirmation<br />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.<br />Es habitual emplear el siguiente formato:<br />Como [rol], <br />quiero [característica], <br />para [valor de negocio].<br />Formato útil, pero no garantiza que se estén elaborando historias de calidad.<br />Buscar un buen título estimula la conversación y ayuda a cuestionarse.<br />Modelado de los roles de usuario, “personajes”, etc.<br />
  17. 17. Ejemplos<br /><ul><li>COMO gestor del Portal de Navarra, QUIERO poder trabajar en el back-end del CMS con IE8
  18. 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
  19. 19. COMO gestor del PNa, QUIERO medir la mejora SEO producida al resolver el problema de "páginas duplicadas“ del CMS, PARA convencerme de la necesidad de acometer otras mejoras similares</li></li></ul><li>Elementos de conversaciónCard, Conversation, Confirmation<br />Datos, elementos hablados con el cliente<br />Diálogos<br />Notas, apuntes<br />Prototipos, documentación aportada<br />Explicitar qué no se incluye<br />Correcto entendimiento. Visión compartida. Sincronizar las “imágenes mentales” <br />
  20. 20. Glosario<br />¿sería buena idea tener una lista de términos de negocio, explicados y accesibles?<br />
  21. 21. Pruebas de aceptaciónCard, Conversation, Confirmation<br />Tienen una doble función según se consideren como:<br />requerimientos, contribuyen a definir el alcance al expresar algún detalle relevante surgido de la conversación;<br />test, demuestran la correcta implementación.<br />Forman parte mínima del Definition of Done<br /><ul><li>No son una descripción exhaustiva de todo RQ o test. No sustituyen la habilidad personal y el buen entendimiento del dominio/circunstancias.
  22. 22. Se pueden añadir/mejorar sobre la marcha, aunque mejor antes de codificar. </li></ul>given … when … then … ¿!se podrá automatizar?! ;)<br />
  23. 23. Ejemplo<br /><ul><li>COMO comercial, QUIERO poderbuscar un cliente, PARA ver los detalles de sucuenta.
  24. 24. Cuandobusque un identificador de cuentaválido, la cuenta se muestra.
  25. 25. Cuandobusquepornumero de SS y nombreválido, la cuenta se muestra.
  26. 26. Si no se encuentranresultados, mostrar el mensajeadecuado</li></li></ul><li>Ejemplo<br />Historia de usuario<br />Una empresa anunciadora, puede pagar la publicación de un anuncio de trabajo en la web BigMoneyJobs mediante carta de crédito.<br />Pruebas de aceptación<br /><ul><li>Verificar con Visa, MasterCard (pass).
  27. 27. Verificar con American Express (fail).
  28. 28. Verificar con números de carta buenos, malos y parciales.
  29. 29. Verificar con una carta caducada.
  30. 30. Verificar un importe mayor de lo máximo permitido por la carta.
  31. 31. …</li></li></ul><li>Qué no son las historias de usuario<br />Descripciones técnicas, para eso ya está el equipo<br />No representan un contrato de alcance cerrado y formal<br />Una definición exhaustiva de los RQs.<br />Una descripción completa del sistema.<br />
  32. 32. Creando las historias de usuarioI.N.V.E.S.T.<br />Las historias de usuario bien planteadas tienen las siguientes características: <br />Independent (independiente)<br />Negotiable (negociable)<br />Valuable (valiosa)<br />Estimatable (estimable)<br />Small (pequeña)<br />Testable (comprobable)<br />
  33. 33. Creando las historias de usuarioI.N.V.E.S.T.<br />Independent (independiente)<br />Cada historia es (lo más posible) independiente de otras.<br />Cada historia es coherente y tiene una alta cohesión.<br />Problemas?<br /><ul><li>Las dependencias dificultan planificar, priorizar y estimar.
  34. 34. Combinar historias
  35. 35. Partir historias de manera diferente (más “vertical”)</li></li></ul><li>Creando las historias de usuarioI.N.V.E.S.T.<br />Negotiable (negociable)<br />La "tarjeta" de la historia es tan sólo una descripción corta, un recordatorio, sin detalles ni pretensión de exhaustividad. <br />Se negocia el objetivo y alcance mediante la “conversación“.<br />Problemas?<br /><ul><li>Historias largas y detalladas crean una falsa sensación de seguridad.
  36. 36. Sabes que el cliente lo va a cambiar cuando lo vea</li></li></ul><li>Creando las historias de usuarioI.N.V.E.S.T.<br />Valuable (valiosa)<br />Cada historia tiene un valor comprensible y tangible para el cliente (posible estimación del ROI – Return Of Investment).<br />Cada historia añade valor a la aplicación.<br />Problemas?<br />Escribir las historias con el cliente. Éste se sentirá cómodo cuando vea que no es un contrato cerrado.<br />Enfocar los user’sgoal. Evitar los detalles de interfaz.<br />Usar el lenguaje del dominio. Prescindir de los tecnicismos. <br />
  37. 37. Creando las historias de usuarioI.N.V.E.S.T.<br />Estimatable (estimable)<br />El equipo puede manejarse con el alcance de la historia de usuario y proveer una estimación<br />La estimación permite priorizar la pila de producto y planificar<br />Problemas?<br />Mejorar el conocimiento del dominio (ej.: más conversación)<br />Mejorar los conocimientos técnicos (ej.: “Spike”)<br />Reducir la complejidad (dividir una historia muy grande)<br />
  38. 38. Creando las historias de usuarioI.N.V.E.S.T.<br />Small (pequeña)<br />La justa medida<br />para poder comprender, estimar y planificar;<br />Según la dimensión y habilidad del equipo, las tecnologías, etc.<br />una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo. <br />Problemas?<br />Dividir la historia. Una historia que es más grande va a tener más errores asociados a la estimación y alcance.<br />
  39. 39. Creando las historias de usuarioI.N.V.E.S.T.<br />Testeable<br />Necesitamos saber cuando terminamos una historia. <br />No desarrollemos aquello que no podemos probar.<br />Problemas?<br />Dividir en historias más pequeñas.<br />Pensar en las pruebas de aceptación.<br />
  40. 40. “Malos ejemplos de historias” Ejercicio 1<br />Ejercicio<br />Objetivo. Aprender a analizar de forma crítica una historia de usuario, sobre la base de los atributos INVEST.<br />
  41. 41. “Malos ejemplos” de historias Ejercicio 1<br /><ul><li>COMO usuario, QUIERO que la interfaz del sistema sea intuitiva, PARA dominar su funcionamientorápidamente.
  42. 42. Un usuario puedo añadir/editar/borrar múltiples CV.
  43. 43. El proceso de desarrollo producirá documentación CMMI nivel 2.
  44. 44. QUIERO desarrollar la capa de negocio de la aplicación de venta de entradas, PARA luego conectarla con la BBDD.
  45. 45. Como usuario de BigMoneyJobs, QUIERO encontrar un trabajo.</li></li></ul><li>“Malos ejemplos” de historias Ejercicio 1<br />Solución<br />Objetivo. Aprender a analizar de forma crítica una historia de usuario, sobre la base de los atributos INVEST.<br />
  46. 46. “Malos ejemplos” de historias Ejercicio 1<br /><ul><li>COMO usuario, QUIERO que la interfaz del sistema sea intuitiva, PARA dominar su funcionamientorápidamente.
  47. 47. ¿Cómo comprobarlo? Hay conceptos muy ambiguos.
  48. 48. No es independienteporquela interfaz abarca el sistema entero.
  49. 49. Un usuario puede añadir/editar/borrar múltiples CV.
  50. 50. Fácilmente divisible en funcionalidades independientes más pequeñas.
  51. 51. El proceso de desarrollo producirá documentación CMMI nivel 3.
  52. 52. Es un requerimiento no funcional
  53. 53. QUIERO desarrollar la capa de negocio de la aplicación de venta de entradas, PARA luego conectarla con la BBDD.
  54. 54. No aporta valor al usuario.
  55. 55. No permite una entrega incremental de funcionalidad disponible para el usuario. En general: historia ≠ capa de software.
  56. 56. Como usuario de BigMoneyJobs, QUIERO encontrar un trabajo.
  57. 57. Es una funcionalidad valiosa, pero de tamaño excesivo. Incluye múltiples tareas/pasos/objetivos intermedios.</li></li></ul><li>“Independent” user-stories Ejercicio 2<br />Ejercicio<br />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.<br />
  58. 58. “Independent” user-storiesEjercicio 2<br />Card<br />Conversation<br />...<br />(Épica)COMO empresa anunciadora, QUIERO pagar un anuncio de trabajo vía web, PARA que quede inmediatamente publicado<br />Confirmation<br /><ul><li> Puedo pagar con tarjetas tradicionales (VISA, Mastercard, American Express), o PayPal.
  59. 59. Ahhh… también con electrónicas (VISA electron)
  60. 60. Emplear el TPV de mi banco.
  61. 61. …</li></li></ul><li>Ejemplo de dependencia Ejercicio 2<br />Posible planteamiento en historias de usuario<br /> La empresa puede pagar un anuncio con Mastercard.<br /> La empresa puede pagar un anuncio con VISA.<br /> La empresa puede pagar un anuncio con American Express.<br /> La empresa puede pagar un anuncio con una carta VISA Electron.<br /> La empresa puede pagar un anuncio con PayPal.<br /> etc.<br />Problema de dependencia entre las historias de usuario planteadas<br /><ul><li> La estimación de las historias depende del orden de ejecución
  62. 62. algunas historias dependen del uso del mismo TPV
  63. 63. << La primera me costará más, no he usado nunca un TPV… >></li></ul>Muy similar<br />Mismo TPV<br />
  64. 64. “Independent” user-stories Ejercicio 2<br />Solución<br />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.<br />
  65. 65. Soluciones a la dependencia Ejercicio 2<br />Algunas posibles estrategias para resolver los problemas de dependencia:<br />Combinar las historias dependientes en una única historia independiente<br /> La empresa puede pagar un anuncio con las cartas de crédito tradicionales (VISA, Mastercard, American Express).<br />Separar las historias de otra manera<br />Separar las historias introduciendo un “spike”<br /> Investigar el uso del nuevo TPV. <br />Separar las historias bajo otro punto de vista<br /> La empresa puede pagar un anuncio con una carta de crédito (ej.: VISA).<br /> La empresa puede pagar un anuncio con otras cartas adicionales (ej.: Mastercard, American Express).<br /> Hacer una doble estimación de las historias de usuario dependientes.<br />
  66. 66. “Valuable” user-stories Ejercicio 3<br />Ejercicio<br />Objetivo. Aprender a expresar los conceptos y las necesidades técnicas de una forma más comprensible y valiosa para el cliente.<br />
  67. 67. “Valuable” user-storiesEjercicio 3<br />Ejemplos con problemas<br /><ul><li> Las conexiones a la BBDD serán mediadas por un connection pool.
  68. 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. 69. Como usuario, quiero disponer de un API para hacer búsquedas
  70. 70. Como usuario, quiero tener un gadget de escritorio para buscar por nombre</li></ul>¿Cómo podríamos darle la vuelta?<br />
  71. 71. “Valuable” user-stories Ejercicio 3<br />Solución<br />Objetivo. Aprender a expresar los conceptos y las necesidades técnicas de una forma más comprensible y valiosa para el cliente.<br />
  72. 72. “Valuable” user-storiesEjercicio 3<br />Ejemplos de posibles solución<br />Las conexiones a la BBDD serán mediadas por un connection pool.<br />La aplicación podrá ser usada de forma concurrente por 15 usuarios con una licencia de BBDD de 5 usuarios.<br />
  73. 73. “Valuable” user-storiesEjercicio 3<br />Ejemplos de posible solución<br />La gestión de los errores y del logging se llevarán a cabo mediante un conjunto de clases comunes a todo el portal.<br />Los mensajes de error serán presentados al usuario y registrados para posteriores análisis de una forma coherente. <br />
  74. 74. Casos particulares: épicas<br />Las épicas son historias de usuario “grandes”, por su tamaño (puntos) y/o dedicación (horas).<br />Proporcionan una visión de alto nivel.<br />Valiosas para la planificación inicial del sistema.<br />Generalmente incluyen trabajo para varias iteraciones.<br />Deben ser divididas en más pequeñas.<br />
  75. 75. Ejemplos:<br />“Que la aplicación sea bonita”<br />“Que el rendimiento sea bueno”<br /> ¿ Llevarlo al DoD de las historias?<br /> ¿ Realizar tareas independientes?<br />Casos particulares: RQs no funcionales<br />
  76. 76. Casos particulares: RQs técnicos<br />El equipo de desarrollo puede necesitar definir trabajos no funcionales<br />¿rendimiento?<br />¿desarrollos estructurales?<br />Muchas veces son tareas necesarias, ¿por qué trabajarlas como historia?<br />“Necesito configurar el maven<br />con la integración continua”<br />
  77. 77. Historias de usuario y Scrum<br />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”.<br />Reunión de “planificación de producto”<br />Conversación con el cliente, visión del proyecto, valorar alternativas, esbozar soluciones, etc.<br />Se crean épicas/historias (Card, Conversation, Confirmation).<br />Reunión de “planificacion de sprint”<br />Planificas en base a historias estimadas<br />Definition of Done (DoD)<br />Deberá pasar los test de aceptación<br />
  78. 78. Propiedades<br />Prioridad<br />Dependencias<br />Backlog plano, o mapa(http://www.agileproductdesign.com/blog/the_new_backlog.html)<br />Valor de negocio (¿ROI?)<br />
  79. 79. Historias: alineadas con el Manifiesto Ágil<br />Manifiesto por el Desarrollo Ágil de Software<br />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:<br />Individuos e interacciones, sobre procesos y herramientas<br />Software que funciona, sobre documentación exhaustiva<br />Colaboración con el cliente, sobre negociación de contratos<br />Responder ante el cambio, sobre seguimiento de un plan <br />Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda.<br />
  80. 80.
  81. 81. “Twitter. Historias de Usuario” Ejercicio 4<br />Ejercicio<br />Objetivo. Practicar la técnica de las historias de usuario sobre un caso real. Crear ocasión de debate. <br />
  82. 82. Relación entre historias, alcance y disciplinas<br /><ul><li>En general: historia ≠ capa de software
  83. 83. Focusonthedelivery of features
  84. 84. << customersget no valuefromthecompletion of activities >>(Agile Estimating and Planning, p. 12)</li></li></ul><li>División de una historia en tareas<br />H = ∑ T1+T2+…+Tn+DoD+∆<br /><< no garanteethatthesum of theseperfectspartsis a perfectwhole >> (UserStoriesApplied, p.147)<br />Comprobación DoD (delta a sumar a las tareas de una historia)<br />Grafica de coste vs. detalle<br />Historia ≠ ∑ tareas<br />
  85. 85. Indicadores<br />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: <br />M – Must, se debe completar este requerimiento para finalizar el proyecto<br />S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él.<br />C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto.<br />W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)<br />
  86. 86. Historias de usuario vs. casos de uso<br />

×