La priorización de historias de usuario (versión ampliada)

1. PRIORIZACIÓN DE HISTORIAS DE USUARIO intentando hacerlo bien! Madrid Agile – 29 Enero 2014

2. Quién soy   Desarrollador desde hace unos años He hecho mis pinitos como Scrum Máster:  Me certifiqué con los mejores (Ariel Ber y Xavier Quesada)  Jose Manuel Beas me ayudó con las historias de usuario   Intento enseñar lo poco que sé a mis alumnos de la Universidad Rey Juan Carlos y el IEBS También monté una startup, pero salió mal ;) @micael_gallego micael.gallego@gmail.com http://micaelgallego.github.io

3. ¿Qué vengo a contar?

4. ¿Qué vengo a contar?

5. ¿Cómo priorizar las historias de usuario?      Por qué priorizamos si todo es importante? Qué factores hay que tener en cuenta para priorizar? Cómo combinamos esos factores? Y las técnicas “clásicas”, se usan en agile? Y hasta aquí puedo leer...

7. Antes de preguntar…

8. Antes de preguntar…

9. He intentado aprender de los mejores  Y he buscado información por la red

10. He intentado aprender de los mejores  Y he buscado información por la red

12. Lo que yo he entendido de la priorización…

13. Por qué priorizamos si todo es importante?  Historias de usuario  Las historias de usuario describen las funcionalidades de un sistema software que se pretende desarrollar  Kent Beck introdujo el término historias de usuario como parte de Extreme Programming para fomentar una manera informal de toma de requisitos  Bill Wake inventó el acrónimo INVEST para describir las características que debe tener una buena historia de usuario Valiosa Pequeña Estimable Negociable Testeable Independiente

14. Por qué priorizamos si todo es importante?  Historias de usuario Kent Beck Mike Cohn Bill Wake

15. Por qué priorizamos si todo es importante?  Priorizamos para poder tener una mínima planificación  Cuánto tiempo tardaremos en tener listo un producto con aproximadamente las siguientes funcionalidades?  Cuánto costará este producto si lo queremos para esta fecha concreta?

18. Por qué priorizamos si todo es importante?   En las metodologías ágiles la planificación se realiza constantemente a lo largo del proyecto De esta forma se reacciona y se adapta al cambio, en vez se seguir un plan predefinido

19. Cómo se planifica en agile? La planificación consiste en Priozar la historias de usuario (Ordenar las tareas por orden de prioridad)

20. Cómo se planifica en agile?  No se asignan tareas a los miembros del equipo…  El equipo se auto-organiza y cada miembro elegirá aquella tarea que más prioritaria o ayudará a otros miembros a completar sus tareas  No se fijan fechas de entrega al cliente…  Al cliente se le enseña un producto funcional (y potencialmente entregable) al final de cada iteración

21. La priorización en el manifiesto ágil La importancia del orden de implementación de las funcionalidades

22. La priorización en el manifiesto ágil  Valor “Colaboración con el cliente sobre negociación contractual”  La mejor forma de involucrar al cliente es ofreciéndole software funcionando que le aporte valor lo antes posible  Así lo podrá probar y podrá dar una realimentación lo antes posible (reduciendo riesgo…)

23. La priorización en el manifiesto ágil  Valor “Respuesta ante el cambio sobre seguir un plan”  Para poder responder ante el cambio es necesario centrarse primero en lo más importante  De esa forma, hay tiempo de reacción y se pueden reorientar los objetivos del proyecto si el entorno cambia, la estimación no era adecuada, el cliente cambia…

24. La priorización en el manifiesto ágil  Principio “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor”  Cuanto más grande sea el valor que se entrega al principio, mucho más satisfecho estará el cliente Y se reducirán los riesgos lo antes posible…

25. La priorización en el manifiesto ágil  Principio “Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo”  Si el equipo se centra en implementar las funcionalidades más importantes al principio, el cliente podrá cambiar de opinión sobre las menos prioritarias (que todavía no se han implementado)

26. No sólo hay que priorizar al principio del proyecto, hay que priorizar en cada iteración El contexto cambia, la tecnología cambia, el equipo cambia, el cliente cambia…

27. Y también priorizamos porque el desarrollo software es un proceso con mucha incertidumbre

28. Y también priorizamos porque el desarrollo software es un proceso con mucha incertidumbre

29. Cono de incertidumbre tiempo

31. Ya tenemos claro que hay que priorizar… ¿Cómo se hace?

32. Ya tenemos claro que hay que priorizar… ¿Cómo se hace?

33. ¿Cómo se prioriza?  Priorizar es ordenar las historias de usuario en base a su… valor coste riesgo Es una cuestión de equilibrio

34. ¿Cómo se prioriza?  Valor para el usuario (de la HU)  El objetivo del equipo es maximizar el valor y la satisfacción percibida por el usuario en cada iteración, por eso es muy importante conocer cuánto valor le aporta cada historia al usuario  El Product Owner se encarga de valorar cada historia de usuario  El equipo lo puede intuir (por su experiencia), pero el PO tomará la decisión sobre el valor de cada historia

35. ¿Cómo se prioriza?  Coste de implementación (de la HU)  Como el coste es muy difícil de saber con precisión, siempre se habla de estimación del coste  El coste se estima por el equipo usando técnicas como el planning poker

36. ¿Cómo se prioriza?  Riesgo que se mitiga al implementar (la HU)  El riesgo es algo que todavía no ha ocurrido pero que puede poner en peligro la realización del proyecto  Hay muchos tipos de riesgos que amenazan a los proyectos software:  no cumplir el plazo previsto inicialmente  que la tecnología que se ha seleccionado cumpla con las expectativas  que el producto que finalmente se ha desarrollado no es el que los clientes/usuarios quieren, etc

37. ¿Cómo se prioriza?  Riesgo que se mitiga al implementar (la HU)  El riesgo de cada historia de usuario es determinado normalmente también por el equipo  En base a su experiencia y conocimiento (o desconocimiento) de la tecnología y del dominio, pueden identificar el riesgo de cada HU

38. ¿Cómo se prioriza?  Riesgo que se mitiga al implementar (la HU)

39. ¿Cómo se prioriza?  Si sólo tenemos en cuenta un criterio, todo es muy fácil:  Valor:  Las HU que más valor aporten, las primeras.  Coste:  Las HU que menos cuesten, las primeras, así se podrá ofrecer el mayor valor posible lo antes posible  Riesgo:  Las HU que mitiguen más riesgo, las primeras. Así habrá margen de maniobra si algún riesgo se manifiesta (o al menos se podrá fallar lo más barato posible)

41. Una metodología para priorizar  1  2  3 El product owner y el cliente deciden el valor que aporta cada historia de usuario El equipo de desarrollo estima el coste de implementarlas Se ordenan las historias de usuario en base al ratio entre el coste y el valor de cada una de ellas    4 Una historia con valor bajo y alto coste sería poco prioritaria Una historia con alto valor y poco coste sería muy prioritaria. Partiendo de esa priorización inicial se incorpora el riesgo   Si hay una historia con una prioridad media, pero que mitiga muchos riesgos al implementarse, se debería hacer más prioritaria. Eso hace que las historias que mitigan menos el riesgo bajen de prioridad.

42. Priorizar en situaciones típicas…  Podemos identificar algunas situaciones típicas, en las que será fácil determinar cómo priorizar  Valor y coste (sin riesgo)  Mucho riesgo tecnológico  Sector desconocido

43. Priorizar en situaciones típicas…  Valor y coste (sin riesgo)  El cliente quiere una tienda online  El equipo de desarrollo tiene mucha experiencia en el dominio de las tiendas on-line  Ha realizado varios proyectos en el pasado  Tiene bastante experiencia con la tecnología con la que se va a implementar  El equipo es estable y tiene contacto directo con el cliente ¿Cómo priorizar en este caso?

44. Priorizar en situaciones típicas…  Valor y coste (sin riesgo)  Se puede considerar que los riesgos del proyecto son bastante bajos  El riesgo no será un factor a tener en cuenta al priorizar las historias de usuario  Los factores a tener en cuenta son únicamente el coste y el valor Las funcionalidades que aporten más valor y tengan menor coste de implementación serán las más prioritarias

45. Priorizar en situaciones típicas…  Mucho riesgo tecnológico  Proyectos en los que se está probando una nueva tecnología y el uso de dicha tecnología es el valor diferencial del producto  Por ejemplo, un proyecto con Oculus Rift o Google Glass ¿Cómo priorizar en este caso?

46. Priorizar en situaciones típicas…  Mucho riesgo tecnológico  Lo más prioritario es mitigar los riesgos de implementar aplicaciones para esa nueva tecnología  Posiblemente el tiempo de desarrollo también sea un factor determinante porque lo prioritario es terminar el producto cuanto antes (para obtener una ventaja competitiva)  En este contexto, quizás se decida reducir el número/completitud de las funcionalidades

47. Priorizar en situaciones típicas…  Sector desconocido  En los proyectos con tecnologías maduras la incertidumbre tecnológica es menor  No obstante, es posible que el sector del proyecto sea totalmente desconocido para el equipo  Por ejemplo, si un equipo nunca ha trabajado en el sector de la banca y quiere realizar un proyecto en ese sector, habrá mucho más riesgo que si el equipo tiene una amplia experiencia ¿Cómo priorizar en este caso?

48. Priorizar en situaciones típicas…  Sector desconocido Cuando el sector se desconoce, es importante mitigar cuanto antes el riesgo sobre el conocimiento del producto  En estos proyectos suelen ser más prioritarias aquellas funcionalidades que permitan una retroalimentación rápida de los usuarios  Estas historias suelen ser las relacionadas con el interfaz de usuario porque los usuarios pueden validar la funcionalidad antes de que esté implementada 

49. Priorizando el riesgo  Cuando el riesgo y el valor son los factores determinantes, se suele usar la siguiente gráfica para priorizar Valor X Bajo valor Alto riesgo 1º Alto valor Alto riesgo Riesgo 3º Bajo valor Bajo riesgo valor 2º Bajo riesgo Alto

51. Las técnicas clásicas…     MoSCoW Theme Scoring Matriz de Priorización Análisis de Kano

52. MoSCoW  MoSCoW es un pseudo-acrónimo formado por las cuatro categorías en las que se tienen que dividir todas las funcionalidades: M - Must have: Tiene que estar  S - Should have: Debería estar si es posible  C - Could have: Podría estar si no afecta a nada más  W - Won’t have: No estará esta vez, pero estará en un futuro

53. MoSCoW  MoSCoW es un pseudo-acrónimo formado por las cuatro categorías en las que se tienen que dividir todas las funcionalidades: M - Must have: Tiene que estar  S - Should have: Debería estar si es posible  C - Could have: Podría estar si no afecta a nada más  W - Won’t have: No estará esta vez, pero estará en un futuro

54. Theme Scoring    Técnica para combinar criterios de las diferentes HU de forma analítica (media ponderada) Se definen una serie de criterios para cada HU Por ejemplo  Aporta valor al cliente (40%)  Afecta a la arquitectura del sistema (20%)  Requiere integración con terceros (30%)  Lo tiene la competencia (10%)

55. Theme Scoring     A cada HU se le asigna un valor entre 1 y 5 para cada una de estas características (por comparación con una HU con esa característica con valor medio) Se pondera la importancia de cada característica Se calcula la media ponderada de las características Se obtiene una ordenación de todas las HU

56. Matriz de priorización    Es parecida al theme scoring pero más elaborada El peso relativo de cada característica se obtiene comparando cada característica con todas las demás Eso permite obtener unos coeficientes con los que obtener la priorización total

57. Matriz de priorización    Es parecida al theme scoring pero más elaborada El peso relativo de cada característica se obtiene comparando cada característica con todas las demás Eso permite obtener unos coeficientes con los que obtener la priorización total

58. Análisis de Kano     Técnica desarrollada por Noriaki Kano Su objetivo es determinar el valor ofrecido por cada funcionalidad con encuestas a los potenciales usuarios Mide las espectativas de los usuarios Divide las funcionalidades en:  Esenciales  Lineales  Asombrosas

59. Análisis de Kano  Esenciales   Tienen que estar en el producto obligatoriamente Lineales Funcionalidades complementarias  El valor al cliente aumenta en el grado que está implementada la funcionalidad (por eso se llaman lineales)   Asombrosas  Mejoran la satisfacción del cliente en gran medida, aunque dicha estén poco elaboradas o no sea muy completas

60. Análisis de Kano Satisfacción del usuario Asombrosas Indiferencia No implementada Muy elaborada Esenciales Lineales Insatisfacción del usuario

61. Análisis de Kano Satisfacción del usuario • El usuario no espera esta funcionalidad pero le gusta si está • La satisfacción aumenta mucho aunque la funcionalidad no esté muy elaborada Asombrosas Indiferencia No implementada Muy elaborada Esenciales Lineales • Por mi elaboradas que estén, no aumentan la satisfacción del usuario. • Si no están, el usuario estará insatisfecho • La satisfacción aumenta cuanto más elaborada está la funcionalidad Insatisfacción del usuario

62. Análisis de Kano    Cuando tenemos dividas las historias de usuario en estos 3 tipos tenemos que priorizar Lo más prioritario es incluir las características esenciales, porque la falta de alguna de ellas no sería aceptada por los usuarios Posteriormente, se incluirían:  Funcionalidades asombrosas, que el usuario no espera y que aportan un alto grado de satisfacción  Funcionalidades lineales, que también proporcionan satisfacción al usuario en función de su desarrollo

63. ¿Cómo priorizar las historias de usuario?      Por qué priorizamos si todo es importante? Qué factores hay que tener en cuenta para priorizar? Cómo combinamos esos factores? Y las técnicas “clásicas”, se usan en agile? Y hasta aquí puedo leer…

64. Y hasta aquí puedo leer… Yo no tengo mucho más que decir… ¿Hay algo importante que haya pasado por alto?

65. Y hasta aquí puedo leer…  Todavía me quedan algunas dudas…  Se usan las técnicas “clásicas” para priorizar? O la combinación de los criterios se hace “a ojo”?  Realmente el coste se usa para priorizar? o únicamente para medir la velocidad del equipo y estimar fechas de entrega / alcance del producto?

66. Y hasta aquí puedo leer…  Todavía me quedan algunas dudas…  Cómo debe afectar el riesgo a la priorización? Justifica cambiar la priorización del cliente (basada principalmente en valor) por el riesgo de implementar ciertas funcionalidades?  No incumple eso el principio del manifiesto ágil “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor” ?

67. Y hasta aquí puedo leer…  Todavía me quedan algunas dudas…  La tecnología a veces dificulta que las historias de usuario sean independientes y se crean priorizaciones forzadas. Conviene ser fiel a la priorización basada en valor pese a que eso aumente el coste global del proyecto?

68. ¿Hacemos un fishbowl para hablar sobre el tema?

La priorización de historias de usuario (versión ampliada)

You are reading a preview.

Check these out next

La priorización de historias de usuario (versión ampliada)

More Related Content

Slideshows for you (20)

Viewers also liked (14)

Similar to La priorización de historias de usuario (versión ampliada) (20)

More from Micael Gallego (19)

Recently uploaded (20)