SlideShare una empresa de Scribd logo
1 de 69
Descargar para leer sin conexión
PRIORIZACIÓN DE
HISTORIAS DE USUARIO
intentando hacerlo bien!
Madrid Agile – 29 Enero 2014
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
¿Qué vengo a contar?
¿Qué vengo a contar?
¿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...
¿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...
Antes de preguntar…
Antes de preguntar…
He intentado aprender de los mejores


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

Y he buscado
información por la red
¿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...
Lo que yo he entendido de la
priorización…
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
Por qué priorizamos si todo es
importante?


Historias de usuario

Kent Beck

Mike Cohn

Bill Wake
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?
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?
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?
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
Cómo se planifica en agile?

La planificación consiste en

Priozar la historias de usuario

(Ordenar las tareas por orden de prioridad)
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
La priorización en el manifiesto ágil
La importancia del orden de
implementación de las funcionalidades
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…)
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…
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…
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)
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…
Y también priorizamos porque el desarrollo
software es un proceso con mucha
incertidumbre
Y también priorizamos porque el desarrollo
software es un proceso con mucha
incertidumbre
Cono de incertidumbre

tiempo
¿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...
Ya tenemos claro que hay que
priorizar…

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

¿Cómo se hace?
¿Cómo se prioriza?


Priorizar es ordenar las historias de usuario en base
a su…

valor

coste

riesgo

Es una cuestión de equilibrio
¿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
¿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
¿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
¿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
¿Cómo se prioriza?


Riesgo que se mitiga al
implementar (la HU)
¿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)
¿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...
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.
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
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?
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
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?
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
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?
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

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
¿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...
Las técnicas clásicas…





MoSCoW
Theme Scoring
Matriz de Priorización
Análisis de Kano
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
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
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%)
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
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
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
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
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
Análisis de Kano
Satisfacción del usuario

Asombrosas
Indiferencia
No implementada

Muy elaborada

Esenciales

Lineales

Insatisfacción del usuario
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
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
¿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…
Y hasta aquí puedo leer…

Yo no tengo mucho más que decir…

¿Hay algo importante que haya
pasado por alto?
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?
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” ?
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?
¿Hacemos un fishbowl para hablar sobre el tema?

Más contenido relacionado

La actualidad más candente

modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
Brihany Rossell
 
PROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWAREPROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWARE
Alejandro Leon
 
Metodología xp
Metodología xpMetodología xp
Metodología xp
Piskamen
 

La actualidad más candente (20)

Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
METODOS TRADICIONALES VS AGILES
METODOS TRADICIONALES VS AGILES METODOS TRADICIONALES VS AGILES
METODOS TRADICIONALES VS AGILES
 
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
Metodologías ágiles, Scrum, Kanban y eXtreme ProgrammingMetodologías ágiles, Scrum, Kanban y eXtreme Programming
Metodologías ágiles, Scrum, Kanban y eXtreme Programming
 
modelos del proceso del software
 modelos del proceso del software  modelos del proceso del software
modelos del proceso del software
 
Conceptos sobre Gestión de Proyectos de Software
Conceptos sobre Gestión de Proyectos de Software Conceptos sobre Gestión de Proyectos de Software
Conceptos sobre Gestión de Proyectos de Software
 
Introduccion a Scrum con caso práctico
Introduccion a Scrum  con caso prácticoIntroduccion a Scrum  con caso práctico
Introduccion a Scrum con caso práctico
 
Presentación de Scrum
Presentación de ScrumPresentación de Scrum
Presentación de Scrum
 
Lean Inception & PBB: Cómo integrar ambas técnicas para construir el Backlog ...
Lean Inception & PBB: Cómo integrar ambas técnicas para construir el Backlog ...Lean Inception & PBB: Cómo integrar ambas técnicas para construir el Backlog ...
Lean Inception & PBB: Cómo integrar ambas técnicas para construir el Backlog ...
 
PROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWAREPROCESOS DE CALIDAD DE SOFTWARE
PROCESOS DE CALIDAD DE SOFTWARE
 
Historias de usuario y la especificación de requisitos
Historias de usuario y la especificación de requisitosHistorias de usuario y la especificación de requisitos
Historias de usuario y la especificación de requisitos
 
La transformacion DevOps
La transformacion DevOpsLa transformacion DevOps
La transformacion DevOps
 
Gestion de formularios php
Gestion de formularios phpGestion de formularios php
Gestion de formularios php
 
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa CondeProceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
Proceso para el desarrollo de software Ponencia M.C.Ivet Espinosa Conde
 
Metodologia XP
Metodologia XPMetodologia XP
Metodologia XP
 
Metodología xp
Metodología xpMetodología xp
Metodología xp
 
Modelo evolutivo
Modelo evolutivoModelo evolutivo
Modelo evolutivo
 
Modelo rup
Modelo rupModelo rup
Modelo rup
 
Modelo CMMI
Modelo CMMIModelo CMMI
Modelo CMMI
 
Etapas de proyectos de software.ppt
Etapas de proyectos de software.pptEtapas de proyectos de software.ppt
Etapas de proyectos de software.ppt
 
La Calidad de Software
La Calidad de SoftwareLa Calidad de Software
La Calidad de Software
 

Destacado

Destacado (14)

GRASP con PR para el SRFLP en el MAEB 2016
GRASP con PR para el SRFLP en el MAEB 2016GRASP con PR para el SRFLP en el MAEB 2016
GRASP con PR para el SRFLP en el MAEB 2016
 
TypeScript para Javeros. Por fin un lenguaje 'de verdad' en el browser
TypeScript para Javeros. Por fin un lenguaje 'de verdad' en el browserTypeScript para Javeros. Por fin un lenguaje 'de verdad' en el browser
TypeScript para Javeros. Por fin un lenguaje 'de verdad' en el browser
 
Tema 1: ¿Qué es la web? (Desarrollo Aplicaciones Web)
Tema 1: ¿Qué es la web? (Desarrollo Aplicaciones Web)Tema 1: ¿Qué es la web? (Desarrollo Aplicaciones Web)
Tema 1: ¿Qué es la web? (Desarrollo Aplicaciones Web)
 
Desarrollo web front-end con TypeScript, Angular 2 e Ionic
Desarrollo web front-end con TypeScript, Angular 2 e IonicDesarrollo web front-end con TypeScript, Angular 2 e Ionic
Desarrollo web front-end con TypeScript, Angular 2 e Ionic
 
TypeScript - Angular 2 - ionic 2
TypeScript - Angular 2 - ionic 2TypeScript - Angular 2 - ionic 2
TypeScript - Angular 2 - ionic 2
 
El mundo real en el aula, con la ayuda del profesor
El mundo real en el aula, con la ayuda del profesorEl mundo real en el aula, con la ayuda del profesor
El mundo real en el aula, con la ayuda del profesor
 
WebRTC y Kurento en el T3cgFest 2015
WebRTC y Kurento en el T3cgFest 2015WebRTC y Kurento en el T3cgFest 2015
WebRTC y Kurento en el T3cgFest 2015
 
TypeScript para Javeros: Cómo programar web front-end y sentirse como en casa
TypeScript para Javeros: Cómo programar web front-end y sentirse como en casaTypeScript para Javeros: Cómo programar web front-end y sentirse como en casa
TypeScript para Javeros: Cómo programar web front-end y sentirse como en casa
 
Docker para Data Scientist - Master en Data Science URJC
Docker para Data Scientist - Master en Data Science URJCDocker para Data Scientist - Master en Data Science URJC
Docker para Data Scientist - Master en Data Science URJC
 
Tema 3: Despliegue de aplicaciones web (Desarrollo Aplicaciones Web)
Tema 3: Despliegue de aplicaciones web (Desarrollo Aplicaciones Web)Tema 3: Despliegue de aplicaciones web (Desarrollo Aplicaciones Web)
Tema 3: Despliegue de aplicaciones web (Desarrollo Aplicaciones Web)
 
JavaScript para Javeros. ¿Cómo ser moderno y no morir en el intento?
JavaScript para Javeros. ¿Cómo ser moderno y no morir en el intento?JavaScript para Javeros. ¿Cómo ser moderno y no morir en el intento?
JavaScript para Javeros. ¿Cómo ser moderno y no morir en el intento?
 
Angular 2 Campus Madrid Septiembre 2016
Angular 2 Campus Madrid Septiembre 2016Angular 2 Campus Madrid Septiembre 2016
Angular 2 Campus Madrid Septiembre 2016
 
Using Docker to build and test in your laptop and Jenkins
Using Docker to build and test in your laptop and JenkinsUsing Docker to build and test in your laptop and Jenkins
Using Docker to build and test in your laptop and Jenkins
 
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
Tema2: Tecnologías de desarrollo web (Desarrollo Aplicaciones Web)
 

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

Agile4Teams Dossier (ES)
Agile4Teams Dossier (ES)Agile4Teams Dossier (ES)
Agile4Teams Dossier (ES)
Rafael Igual
 
Sprint_ScrumFundamentos_JM_Agosto21_vA.pdf
Sprint_ScrumFundamentos_JM_Agosto21_vA.pdfSprint_ScrumFundamentos_JM_Agosto21_vA.pdf
Sprint_ScrumFundamentos_JM_Agosto21_vA.pdf
valverdeisaac69
 
Qué metodología será más adecuada para mi proyecto software
Qué metodología será más adecuada para mi proyecto softwareQué metodología será más adecuada para mi proyecto software
Qué metodología será más adecuada para mi proyecto software
LeanSight Consulting
 
La Alternativa Ágil 1.0
La Alternativa Ágil 1.0La Alternativa Ágil 1.0
La Alternativa Ágil 1.0
Agile Spain
 

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

Gestión basada en Metodologías Ágiles
Gestión basada en Metodologías ÁgilesGestión basada en Metodologías Ágiles
Gestión basada en Metodologías Ágiles
 
Las SinCuenta Sombras de Scrum
Las SinCuenta Sombras de ScrumLas SinCuenta Sombras de Scrum
Las SinCuenta Sombras de Scrum
 
Agile4Teams Dossier (ES)
Agile4Teams Dossier (ES)Agile4Teams Dossier (ES)
Agile4Teams Dossier (ES)
 
Sprint_ScrumFundamentos_JM_Agosto21_vA.pdf
Sprint_ScrumFundamentos_JM_Agosto21_vA.pdfSprint_ScrumFundamentos_JM_Agosto21_vA.pdf
Sprint_ScrumFundamentos_JM_Agosto21_vA.pdf
 
Métodos de Integración Lean, Agile & Design Thinking
Métodos de Integración Lean, Agile & Design ThinkingMétodos de Integración Lean, Agile & Design Thinking
Métodos de Integración Lean, Agile & Design Thinking
 
Qué metodología será más adecuada para mi proyecto software
Qué metodología será más adecuada para mi proyecto softwareQué metodología será más adecuada para mi proyecto software
Qué metodología será más adecuada para mi proyecto software
 
Un poco más de Agile y Scrum à la Pablo
Un poco más de Agile y Scrum à la PabloUn poco más de Agile y Scrum à la Pablo
Un poco más de Agile y Scrum à la Pablo
 
Seminario de metodologías ágiles, bloque I
Seminario de metodologías ágiles, bloque ISeminario de metodologías ágiles, bloque I
Seminario de metodologías ágiles, bloque I
 
UXN 04-31 - El origen mítico del Product Backlog
UXN 04-31 - El origen mítico del Product BacklogUXN 04-31 - El origen mítico del Product Backlog
UXN 04-31 - El origen mítico del Product Backlog
 
Introducción a Técnicas Agiles y Scrum : Dia 1
Introducción a Técnicas Agiles y Scrum  : Dia 1Introducción a Técnicas Agiles y Scrum  : Dia 1
Introducción a Técnicas Agiles y Scrum : Dia 1
 
Programacion Extrema
Programacion ExtremaProgramacion Extrema
Programacion Extrema
 
Personal Software Process / Sesion 01
Personal Software Process / Sesion 01Personal Software Process / Sesion 01
Personal Software Process / Sesion 01
 
Curso Introducción a Agile
Curso Introducción a AgileCurso Introducción a Agile
Curso Introducción a Agile
 
La Alternativa Ágil 1.0
La Alternativa Ágil 1.0La Alternativa Ágil 1.0
La Alternativa Ágil 1.0
 
Principios ágiles
Principios ágilesPrincipios ágiles
Principios ágiles
 
Metodologias
MetodologiasMetodologias
Metodologias
 
METODOLOGIAS AGILES
METODOLOGIAS AGILESMETODOLOGIAS AGILES
METODOLOGIAS AGILES
 
Resumen sobre Marco de trabajo SCRUM
Resumen sobre Marco de trabajo SCRUMResumen sobre Marco de trabajo SCRUM
Resumen sobre Marco de trabajo SCRUM
 
Ingeniería de Software, Agilidad y Tecnología
Ingeniería de Software, Agilidad y TecnologíaIngeniería de Software, Agilidad y Tecnología
Ingeniería de Software, Agilidad y Tecnología
 
El dilema del product owner delivery vs disovery
El dilema del product owner delivery vs disovery El dilema del product owner delivery vs disovery
El dilema del product owner delivery vs disovery
 

Más de Micael Gallego

Más de Micael Gallego (19)

Software libre para videoconferencias
Software libre para videoconferenciasSoftware libre para videoconferencias
Software libre para videoconferencias
 
La evaluación con realimentación y posibilidad de recuperación para evitar el...
La evaluación con realimentación y posibilidad de recuperación para evitar el...La evaluación con realimentación y posibilidad de recuperación para evitar el...
La evaluación con realimentación y posibilidad de recuperación para evitar el...
 
WebRTC en tu web con OpenVidu
WebRTC en tu web con OpenViduWebRTC en tu web con OpenVidu
WebRTC en tu web con OpenVidu
 
¿Cómo poner software de calidad en manos del usuario de forma rápida?
¿Cómo poner software de calidad en manos del usuario de forma rápida?¿Cómo poner software de calidad en manos del usuario de forma rápida?
¿Cómo poner software de calidad en manos del usuario de forma rápida?
 
Curso Angular 9 - CodeURJC - Marzo 2020
Curso Angular 9 - CodeURJC - Marzo 2020Curso Angular 9 - CodeURJC - Marzo 2020
Curso Angular 9 - CodeURJC - Marzo 2020
 
Concurrencia y asincronía: Lenguajes, modelos y rendimiento: GDG Toledo Enero...
Concurrencia y asincronía: Lenguajes, modelos y rendimiento: GDG Toledo Enero...Concurrencia y asincronía: Lenguajes, modelos y rendimiento: GDG Toledo Enero...
Concurrencia y asincronía: Lenguajes, modelos y rendimiento: GDG Toledo Enero...
 
Herramientas y plugins para el desarrollo de aplicaciones cloud native para K...
Herramientas y plugins para el desarrollo de aplicaciones cloud native para K...Herramientas y plugins para el desarrollo de aplicaciones cloud native para K...
Herramientas y plugins para el desarrollo de aplicaciones cloud native para K...
 
Dev Tools para Kubernetes - Codemotion 2019
Dev Tools para Kubernetes - Codemotion 2019Dev Tools para Kubernetes - Codemotion 2019
Dev Tools para Kubernetes - Codemotion 2019
 
Testing cloud and kubernetes applications - ElasTest
Testing cloud and kubernetes applications - ElasTestTesting cloud and kubernetes applications - ElasTest
Testing cloud and kubernetes applications - ElasTest
 
Curso Kubernetes CodeURJC
Curso Kubernetes CodeURJCCurso Kubernetes CodeURJC
Curso Kubernetes CodeURJC
 
Testeando aplicaciones Kubernetes: escalabilidad y tolerancia a fallos
Testeando aplicaciones Kubernetes: escalabilidad y tolerancia a fallosTesteando aplicaciones Kubernetes: escalabilidad y tolerancia a fallos
Testeando aplicaciones Kubernetes: escalabilidad y tolerancia a fallos
 
OpenVidu Commitconf 2018
OpenVidu Commitconf 2018 OpenVidu Commitconf 2018
OpenVidu Commitconf 2018
 
Introducción a las Pruebas Software
Introducción a las Pruebas SoftwareIntroducción a las Pruebas Software
Introducción a las Pruebas Software
 
Node para Javeros: Conoce a tu enemigo
Node para Javeros: Conoce a tu enemigoNode para Javeros: Conoce a tu enemigo
Node para Javeros: Conoce a tu enemigo
 
Testing fácil con Docker: Gestiona dependencias y unifica entornos
Testing fácil con Docker: Gestiona dependencias y unifica entornosTesting fácil con Docker: Gestiona dependencias y unifica entornos
Testing fácil con Docker: Gestiona dependencias y unifica entornos
 
Desarrollo centrado en tareas en Eclipse con Mylyn 2009
Desarrollo centrado en tareas en Eclipse con Mylyn 2009Desarrollo centrado en tareas en Eclipse con Mylyn 2009
Desarrollo centrado en tareas en Eclipse con Mylyn 2009
 
Como ser mas productivo en el desarrollo de aplicaciones
Como ser mas productivo en el desarrollo de aplicacionesComo ser mas productivo en el desarrollo de aplicaciones
Como ser mas productivo en el desarrollo de aplicaciones
 
TypeScript: Un lenguaje aburrido para programadores torpes y tristes
TypeScript: Un lenguaje aburrido para programadores torpes y tristesTypeScript: Un lenguaje aburrido para programadores torpes y tristes
TypeScript: Un lenguaje aburrido para programadores torpes y tristes
 
El Aprendizaje Basado en Proyectos y la Clase Invertida para acercar el mundo...
El Aprendizaje Basado en Proyectos y la Clase Invertida para acercar el mundo...El Aprendizaje Basado en Proyectos y la Clase Invertida para acercar el mundo...
El Aprendizaje Basado en Proyectos y la Clase Invertida para acercar el mundo...
 

Último

editorial de informática de los sueños.docx
editorial de informática de los sueños.docxeditorial de informática de los sueños.docx
editorial de informática de los sueños.docx
ssusere34b451
 
Chat GPT para la educación Latinoamerica
Chat GPT para la educación LatinoamericaChat GPT para la educación Latinoamerica
Chat GPT para la educación Latinoamerica
EdwinGarca59
 

Último (20)

Actividad 6/Las TIC en la Vida Cotidiana.
Actividad 6/Las TIC en la Vida Cotidiana.Actividad 6/Las TIC en la Vida Cotidiana.
Actividad 6/Las TIC en la Vida Cotidiana.
 
el uso de las TIC en la vida cotidiana.pptx
el uso de las TIC en la vida cotidiana.pptxel uso de las TIC en la vida cotidiana.pptx
el uso de las TIC en la vida cotidiana.pptx
 
Inteligencia Artificial para usuarios nivel inicial
Inteligencia Artificial para usuarios nivel inicialInteligencia Artificial para usuarios nivel inicial
Inteligencia Artificial para usuarios nivel inicial
 
editorial de informática de los sueños.docx
editorial de informática de los sueños.docxeditorial de informática de los sueños.docx
editorial de informática de los sueños.docx
 
Tipos de datos en Microsoft Access de Base de Datos
Tipos de datos en Microsoft Access de Base de DatosTipos de datos en Microsoft Access de Base de Datos
Tipos de datos en Microsoft Access de Base de Datos
 
Imágenes digitales: Calidad de la información
Imágenes digitales: Calidad de la informaciónImágenes digitales: Calidad de la información
Imágenes digitales: Calidad de la información
 
Chat GPT para la educación Latinoamerica
Chat GPT para la educación LatinoamericaChat GPT para la educación Latinoamerica
Chat GPT para la educación Latinoamerica
 
innovacion banking & warehouse 2024 blog
innovacion banking & warehouse 2024 bloginnovacion banking & warehouse 2024 blog
innovacion banking & warehouse 2024 blog
 
Navegadores de internet - Nuevas Tecnologías de la Información y la Comunicación
Navegadores de internet - Nuevas Tecnologías de la Información y la ComunicaciónNavegadores de internet - Nuevas Tecnologías de la Información y la Comunicación
Navegadores de internet - Nuevas Tecnologías de la Información y la Comunicación
 
NIVEL DE MADUREZ TECNOLÓGICA (TRL).pptx
NIVEL DE  MADUREZ TECNOLÓGICA (TRL).pptxNIVEL DE  MADUREZ TECNOLÓGICA (TRL).pptx
NIVEL DE MADUREZ TECNOLÓGICA (TRL).pptx
 
Electricidad Libro compendio de temas estudiados.docx
Electricidad Libro compendio de temas estudiados.docxElectricidad Libro compendio de temas estudiados.docx
Electricidad Libro compendio de temas estudiados.docx
 
PRÁCTICA Nº 4: “Análisis de secuencias del ADN con el software BioEdit y uso ...
PRÁCTICA Nº 4: “Análisis de secuencias del ADN con el software BioEdit y uso ...PRÁCTICA Nº 4: “Análisis de secuencias del ADN con el software BioEdit y uso ...
PRÁCTICA Nº 4: “Análisis de secuencias del ADN con el software BioEdit y uso ...
 
JORNADA INTELIGENCIA ARTIFICIAL Y REALIDAD VIRTUAL
JORNADA INTELIGENCIA ARTIFICIAL Y REALIDAD VIRTUALJORNADA INTELIGENCIA ARTIFICIAL Y REALIDAD VIRTUAL
JORNADA INTELIGENCIA ARTIFICIAL Y REALIDAD VIRTUAL
 
VelderrainPerez_Paola_M1C1G63-097.pptx. LAS TiC
VelderrainPerez_Paola_M1C1G63-097.pptx. LAS TiCVelderrainPerez_Paola_M1C1G63-097.pptx. LAS TiC
VelderrainPerez_Paola_M1C1G63-097.pptx. LAS TiC
 
Tipos de Datos de Microsoft Access-JOEL GARCIA.pptx
Tipos de Datos de Microsoft Access-JOEL GARCIA.pptxTipos de Datos de Microsoft Access-JOEL GARCIA.pptx
Tipos de Datos de Microsoft Access-JOEL GARCIA.pptx
 
Desarrollo del Dominio del Internet - Estrada
Desarrollo del Dominio del Internet - EstradaDesarrollo del Dominio del Internet - Estrada
Desarrollo del Dominio del Internet - Estrada
 
Uso de las TIC en la vida cotidiana .
Uso de las TIC en la vida cotidiana       .Uso de las TIC en la vida cotidiana       .
Uso de las TIC en la vida cotidiana .
 
BUSCADORES DE INTERNET (Universidad de Sonora).
BUSCADORES DE INTERNET (Universidad de Sonora).BUSCADORES DE INTERNET (Universidad de Sonora).
BUSCADORES DE INTERNET (Universidad de Sonora).
 
De Olmos Santiago_Dolores _ M1S3AI6.pptx
De Olmos Santiago_Dolores _ M1S3AI6.pptxDe Olmos Santiago_Dolores _ M1S3AI6.pptx
De Olmos Santiago_Dolores _ M1S3AI6.pptx
 
Ejercicio 1 periodo 2 de Tecnología 2024
Ejercicio 1 periodo 2 de Tecnología 2024Ejercicio 1 periodo 2 de Tecnología 2024
Ejercicio 1 periodo 2 de Tecnología 2024
 

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...
  • 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 las técnicas “clásicas”, se usan en agile? Y hasta aquí puedo leer...
  • 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 las técnicas “clásicas”, se usan en agile? Y hasta aquí puedo leer...
  • 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?
  • 16. 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?
  • 17. 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
  • 30.
  • 31. ¿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...
  • 32. Ya tenemos claro que hay que priorizar… ¿Cómo se hace?
  • 33. Ya tenemos claro que hay que priorizar… ¿Cómo se hace?
  • 34. ¿Cómo se prioriza?  Priorizar es ordenar las historias de usuario en base a su… valor coste riesgo Es una cuestión de equilibrio
  • 35. ¿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
  • 36. ¿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
  • 37. ¿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
  • 38. ¿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
  • 39. ¿Cómo se prioriza?  Riesgo que se mitiga al implementar (la HU)
  • 40. ¿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. ¿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...
  • 42. 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.
  • 43. 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
  • 44. 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?
  • 45. 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
  • 46. 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?
  • 47. 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
  • 48. 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?
  • 49. 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 
  • 50. 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. ¿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...
  • 52. Las técnicas clásicas…     MoSCoW Theme Scoring Matriz de Priorización Análisis de Kano
  • 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. 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
  • 55. 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%)
  • 56. 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
  • 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. 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
  • 59. 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
  • 60. 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
  • 61. Análisis de Kano Satisfacción del usuario Asombrosas Indiferencia No implementada Muy elaborada Esenciales Lineales Insatisfacción del usuario
  • 62. 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
  • 63. 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
  • 64. ¿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…
  • 65. Y hasta aquí puedo leer… Yo no tengo mucho más que decir… ¿Hay algo importante que haya pasado por alto?
  • 66. 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?
  • 67. 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” ?
  • 68. 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?
  • 69. ¿Hacemos un fishbowl para hablar sobre el tema?