Your SlideShare is downloading. ×
  • Like
La priorización de historias de usuario (versión reducida)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 618 views
Published

Presentación del meetup de Madrid Ágil del 29 de Enero de 2014. …

Presentación del meetup de Madrid Ágil del 29 de Enero de 2014.

Tenéis una versión ampliada en: https://www.slideshare.net/micaelgallego/la-priorizacin-de-historias-de-usuario2

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
618
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
22
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 hasta aquí puedo leer...
  • 6. ¿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 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
  • 11. ¿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 hasta aquí puedo leer...
  • 12. Lo que yo he entendido de la priorización…
  • 13. 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?
  • 14. 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?
  • 15. 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
  • 16. Cómo se planifica en agile? La planificación consiste en Priozar la historias de usuario (Ordenar las tareas por orden de prioridad)
  • 17. 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
  • 18. 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…
  • 19. Y también priorizamos porque el desarrollo software es un proceso con mucha incertidumbre
  • 20. Y también priorizamos porque el desarrollo software es un proceso con mucha incertidumbre
  • 21. Cono de incertidumbre tiempo
  • 22. ¿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 hasta aquí puedo leer...
  • 23. Ya tenemos claro que hay que priorizar… ¿Cómo se hace?
  • 24. Ya tenemos claro que hay que priorizar… ¿Cómo se hace?
  • 25. ¿Cómo se prioriza?  Priorizar es ordenar las historias de usuario en base a su… valor coste riesgo Es una cuestión de equilibrio
  • 26. ¿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
  • 27. ¿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
  • 28. ¿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
  • 29. ¿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
  • 30. ¿Cómo se prioriza?  Riesgo que se mitiga al implementar (la HU)
  • 31. ¿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)
  • 32. ¿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 hasta aquí puedo leer...
  • 33. 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.
  • 34. 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
  • 35. 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
  • 36. ¿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 hasta aquí puedo leer...
  • 37. Y hasta aquí puedo leer… Yo no tengo mucho más que decir… ¿Hay algo importante que haya pasado por alto?
  • 38. Y hasta aquí puedo leer…  Todavía me quedan algunas dudas…  Realmente el 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…  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 mitigado al 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” ?
  • 40. Y hasta aquí puedo leer…  Todavía me quedan algunas dudas…  La tecnología a veces dificulta que las historias de usuario sean totalmente 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?
  • 41. Y hasta aquí puedo leer…  Todavía me quedan algunas dudas…  Se usan alguna técnica específica para combinar los criterios (como Theme scoring, Matriz de prioridades…) para priorizar?  O la combinación de los criterios se hace principalmente “a ojo” (basado en experiencia)?
  • 42. ¿Hacemos un fishbowl para hablar sobre el tema?
  • 43. Bonus track… Técnicas específicas de priorización
  • 44. Las técnicas específicas…     MoSCoW Theme Scoring Matriz de Priorización Análisis de Kano
  • 45. 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
  • 46. 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
  • 47. 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%)
  • 48. 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
  • 49. 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
  • 50. 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
  • 51. 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
  • 52. 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
  • 53. Análisis de Kano Satisfacción del usuario Asombrosas Indiferencia No implementada Muy elaborada Esenciales Lineales Insatisfacción del usuario
  • 54. 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
  • 55. 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