1. PRIORIZACIN DE HISTORIAS DE USUARIO intentando hacerlo bien! Madrid Agile 29 Enero 2014

2. Quin soy Desarrollador desde hace unos aos He hecho mis pinitos como Scrum Mster: Mecertifiqu con los mejores (Ariel Ber y Xavier Quesada) Jose Manuel Beas me ayud con las historias de usuario Intento ensear lo poco que s a mis alumnos de la Universidad Rey Juan Carlos y el IEBS Tambin mont una startup, pero sali mal ;) @micael_gallegomicael.gallego@gmail.comhttp://micaelgallego.github.io 3. Qu vengo a contar? 4. Qu vengo a contar? 5. Cmo priorizar las historias de usuario? Por qu priorizamos si todo es importante? Qu factores hay que tener en cuenta para priorizar? Cmo combinamos esos factores? Y hasta aqu puedo leer... 6. Cmo priorizar las historias de usuario? Por qu priorizamos si todo es importante? Qu factores hay que tener en cuenta para priorizar? Cmo combinamos esos factores? Y hasta aqu puedo leer... 7. Antes de preguntar 8. Antes de preguntar 9. He intentado aprender de los mejores Y he buscado informacin por la red 10. He intentado aprender de los mejores Y he buscado informacin por la red 11. Cmo priorizar las historias de usuario? Por qu priorizamos si todo es importante? Qu factores hay que tener en cuenta para priorizar? Cmo combinamos esos factores? Y hasta aqu puedo leer... 12. Lo que yo he entendido de la priorizacin 13. Por qu priorizamos si todo es importante? Priorizamos para poder tener una mnima planificacin Cuntotiempo tardaremos en tener listo un producto con aproximadamente las siguientes funcionalidades? Cunto costar este producto si lo queremos para esta fecha concreta? 14. Por qu priorizamos si todo es importante? Priorizamos para poder tener una mnima planificacin Cuntotiempo tardaremos en tener listo un producto con aproximadamente las siguientes funcionalidades? Cunto costar este producto si lo queremos para esta fecha concreta? 15. Por qu priorizamos si todo es importante? En las metodologas giles la planificacin 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 16. Cmo se planifica en agile?La planificacin consiste enPriozar la historias de usuario(Ordenar las tareas por orden de prioridad) 17. Cmo se planifica en agile? No se asignan tareas a los miembros del equipo Elequipo se auto-organiza y cada miembro elegir aquella tarea que ms prioritaria o ayudar a otros miembros a completar sus tareasNo se fijan fechas de entrega al cliente Alcliente se le ensea un producto funcional (y potencialmente entregable) al final de cada iteracin 18. No slo hay que priorizar al principio del proyecto, hay que priorizar en cada iteracin El contexto cambia, la tecnologa cambia, el equipo cambia, el cliente cambia 19. Y tambin priorizamos porque el desarrollo software es un proceso con mucha incertidumbre 20. Y tambin priorizamos porque el desarrollo software es un proceso con mucha incertidumbre 21. Cono de incertidumbretiempo 22. Cmo priorizar las historias de usuario? Por qu priorizamos si todo es importante? Qu factores hay que tener en cuenta para priorizar? Cmo combinamos esos factores? Y hasta aqu puedo leer... 23. Ya tenemos claro que hay que priorizarCmo se hace? 24. Ya tenemos claro que hay que priorizarCmo se hace? 25. Cmo se prioriza? Priorizar es ordenar las historias de usuario en base a suvalorcosteriesgoEs una cuestin de equilibrio 26. Cmo se prioriza? Valor para el usuario (de la HU) Elobjetivo del equipo es maximizar el valor y la satisfaccin percibida por el usuario en cada iteracin, por eso es muy importante conocer cunto 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 decisin sobre el valor de cada historia 27. Cmo se prioriza? Coste de implementacin (de la HU) Comoel coste es muy difcil de saber con precisin, siempre se habla de estimacin del coste Elcoste se estima por el equipo usando tcnicas como el planning poker 28. Cmo se prioriza? Riesgo que se mitiga al implementar (la HU) Elriesgo es algo que todava no ha ocurrido pero que puede poner en peligro la realizacin del proyecto Hay muchos tipos de riesgos que amenazan a los proyectos software: nocumplir el plazo previsto inicialmente que la tecnologa 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 29. Cmo se prioriza? Riesgo que se mitiga al implementar (la HU) Elriesgo de cada historia de usuario es determinado normalmente tambin por el equipo Enbase a su experiencia y conocimiento (o desconocimiento) de la tecnologa y del dominio, pueden identificar el riesgo de cada HU 30. Cmo se prioriza? Riesgo que se mitiga al implementar (la HU) 31. Cmo se prioriza? Si slo tenemos en cuenta un criterio, todo es muy fcil: Valor: LasHU que ms valor aporten, las primeras. Coste: LasHU que menos cuesten, las primeras, as se podr ofrecer el mayor valor posible lo antes posible Riesgo: LasHU que mitiguen ms riesgo, las primeras. As habr margen de maniobra si algn riesgo se manifiesta (o al menos se podr fallar lo ms barato posible) 32. Cmo priorizar las historias de usuario? Por qu priorizamos si todo es importante? Qu factores hay que tener en cuenta para priorizar? Cmo combinamos esos factores? Y hasta aqu puedo leer... 33. Una metodologa para priorizar 1 2 3El 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 4Una historia con valor bajo y alto coste sera poco prioritaria Una historia con alto valor y poco coste sera muy prioritaria.Partiendo de esa priorizacin inicial se incorpora el riesgo Si hay una historia con una prioridad media, pero que mitiga muchos riesgos al implementarse, se debera hacer ms prioritaria. Eso hace que las historias que mitigan menos el riesgo bajen de prioridad. 34. Priorizar en situaciones tpicas Podemos identificar algunas situaciones tpicas, en las que ser fcil determinar cmo priorizar Valory coste (sin riesgo) Mucho riesgo tecnolgico Sector desconocido 35. Priorizando el riesgo Cuando el riesgo y el valor son los factores determinantes, se suele usar la siguiente grfica para priorizar ValorXBajo valor Alto riesgo1Alto valor Alto riesgoRiesgo3 Bajo valor Bajo riesgovalor 2 Bajo riesgo Alto 36. Cmo priorizar las historias de usuario? Por qu priorizamos si todo es importante? Qu factores hay que tener en cuenta para priorizar? Cmo combinamos esos factores? Y hasta aqu puedo leer... 37. Y hasta aqu puedo leerYo no tengo mucho ms que decirHay algo importante que haya pasado por alto? 38. Y hasta aqu puedo leer Todava me quedan algunas dudas Realmenteel coste se usa para priorizar? o se trata como un factor secundario para medir la velocidad del equipo y estimar fechas de entrega / alcance del producto? 39. Y hasta aqu puedo leer Todava me quedan algunas dudas Cmodebe afectar el riesgo a la priorizacin? Justifica cambiar la priorizacin del cliente (basada principalmente en valor) por el riesgo mitigado al implementar ciertas funcionalidades? Noincumple eso el principio del manifiesto gil Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor ? 40. Y hasta aqu puedo leer Todava me quedan algunas dudas Latecnologa a veces dificulta que las historias de usuario sean totalmente independientes y se crean priorizaciones forzadas. Conviene ser fiel a la priorizacin basada en valor pese a que eso aumente el coste global del proyecto? 41. Y hasta aqu puedo leer Todava me quedan algunas dudas Seusan alguna tcnica especfica para combinar los criterios (como Theme scoring, Matriz de prioridades) para priorizar? O la combinacin de los criterios se hace principalmente a ojo (basado en experiencia)? 42. Hacemos un fishbowl para hablar sobre el tema? 43. Bonus trackTcnicas especficas de priorizacin 44. Las tcnicas especficas MoSCoW Theme Scoring Matriz de Priorizacin Anlisis de Kano 45. MoSCoW MoSCoW es un pseudo-acrnimo formado por las cuatro categoras en las que se tienen que dividir todas las funcionalidades: M- Must have: Tiene que estar S - Should have: Debera estar si es posible C - Could have: Podra estar si no afecta a nada ms W - Wont have: No estar esta vez, pero estar en un futuro 46. MoSCoW MoSCoW es un pseudo-acrnimo formado por las cuatro categoras en las que se tienen que dividir todas las funcionalidades: M- Must have: Tiene que estar S - Should have: Debera estar si es posible C - Could have: Podra estar si no afecta a nada ms W - Wont have: No estar esta vez, pero estar en un futuro 47. Theme Scoring Tcnica para combinar criterios de las diferentes HU de forma analtica (media ponderada) Se definen una serie de criterios para cada HU Por ejemplo Aportavalor al cliente (40%) Afecta a la arquitectura del sistema (20%) Requiere integracin con terceros (30%) Lo tiene la competencia (10%) 48. Theme Scoring A cada HU se le asigna un valor entre 1 y 5 para cada una de estas caractersticas (por comparacin con una HU con esa caracterstica con valor medio) Se pondera la importancia de cada caracterstica Se calcula la media ponderada de las caractersticas Se obtiene una ordenacin de todas las HU 49. Matriz de priorizacin Es parecida al theme scoring pero ms elaborada El peso relativo de cada caracterstica se obtiene comparando cada caracterstica con todas las dems Eso permite obtener unos coeficientes con los que obtener la priorizacin total 50. Matriz de priorizacin Es parecida al theme scoring pero ms elaborada El peso relativo de cada caracterstica se obtiene comparando cada caracterstica con todas las dems Eso permite obtener unos coeficientes con los que obtener la priorizacin total 51. Anlisis de Kano Tcnica 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 52. Anlisis de Kano Esenciales Tienen que estar en el producto obligatoriamenteLineales Funcionalidades complementarias El valor al cliente aumenta en el grado que est implementada la funcionalidad (por eso se llaman lineales) Asombrosas Mejoran la satisfaccin del cliente en gran medida, aunque dicha estn poco elaboradas o no sea muy completas 53. Anlisis de Kano Satisfaccin del usuarioAsombrosas Indiferencia No implementadaMuy elaboradaEsencialesLinealesInsatisfaccin del usuario 54. Anlisis de Kano Satisfaccin del usuario El usuario no espera esta funcionalidad pero le gusta si est La satisfaccin aumenta mucho aunque la funcionalidad no est muy elaboradaAsombrosasIndiferencia No implementadaMuy elaboradaEsencialesLineales Por mi elaboradas que estn, no aumentan la satisfaccin del usuario. Si no estn, el usuario estar insatisfecho La satisfaccin aumenta cuanto ms elaborada est la funcionalidadInsatisfaccin del usuario 55. Anlisis de Kano Cuando tenemos dividas las historias de usuario en estos 3 tipos tenemos que priorizar Lo ms prioritario es incluir las caractersticas esenciales, porque la falta de alguna de ellas no sera aceptada por los usuarios Posteriormente, se incluiran: Funcionalidadesasombrosas, que el usuario no espera y que aportan un alto grado de satisfaccin Funcionalidades lineales, que tambin proporcionan satisfaccin al usuario en funcin de su desarrollo