Mes: julio 2009

Métricas ágiles y valor – Resultados del sexto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • Se debe tener sólo las métricas realmente necesarias.
  • Deben estar “balanceadas”, para detectar si se está obteniendo unos resultados a costa de otros.
  • Las métricas ágiles más importantes son: el valor que se va entregando el cliente y la velocidad de desarrollo.
  • Las métricas se pueden ampliar cuando se quiere ver la evolución de un problema. Una vez solucionado, se dejan de recoger.
  • Los criterios básicos de planificación de objetivos/requisitos de proyecto son el valor y el coste, a los que se puede añadir: riesgo, integraciones y madurez.
  • La percepción del valor de los requisitos puede ir cambiando según avanza el proyecto. Esto se gestiona en la replanificación que se hace al inicio de cada iteración.

 

priorizacion-encuentro

 

Métricas básicas en un proyecto ágil
  • Se debe tener sólo las métricas realmente necesarias, dado el coste que implica tanto recoger como interpretar cualquier métrica.
  • Cuando se recoge una métrica, las personas intentan quedar bien respecto a esa métrica. Por ello, es conveniente disponer de un conjunto de métricas “balanceadas” que detecten si se está obteniendo unos resultados a costa de otros. Por ejemplo, puede ser que la productividad esté aumentando pero a expensas de un descenso de calidad.
  • Notar que las métricas también permiten tener una proactividad y detectar un posible problema antes de que se manifieste completamente.
  • Las métricas ágiles más importantes son:
    • El valor que se va entregando el cliente (Product Owner), que permite saber:
    • La velocidad de desarrollo del equipo, que permite:
      • Extrapolar la fecha de finalización del proyecto y/o saber de qué objetivo/requisitos se dispondrá en una fecha determinada.
      • Planificar un nuevo proyecto a partir de la historia anterior.
      • Medir le aprendizaje del equipo, ya que es una métrica que debería aumentar con el tiempo.
    • Métricas de calidad como el número de defectos.

graficos-velocidad-valor-coste

 
Ampliación de las métricas
  • El conjunto de métricas se pueden ampliar cuando aparece un problema a solucionar y se quiere ver su evolución. Por ejemplo:
  • Dado que la recolección e interpretación de métricas tiene un coste (no sirve de nada disponer de un gráfico de tendencia si no se hace un análisis causal de por qué se está dando esa tendencia), una vez solucionado el problema (cuando la métrica ya es estable o el equipo ya ha aprendido), estas métricas se dejan de recoger (a menos que su recolección sea automática y su observación fácilmente discriminable).
 
La métrica “valor”
 
Aunque el cliente (Product Owner) es el responsable de determinar el valor de cada objetivo (requisito, funcionalidad, feature o historia de usuario), en el encuentro también se apuntó que el equipo (o empresa ejecutora del proyecto) también valora qué le aporta el proyecto. Por ejemplo, unos objetivos determinados (o un proyecto entero) pueden tener relativamente poco retorno de inversión para el cliente, pero mucho valor para el equipo, ya que le permite adquirir conocimiento, experimentar con nuevas tecnologías, ganar algún premio o reconocimiento, etc.
En el encuentro se mencionaron diversos ejemplos sobre cómo el cliente puede indicar el valor de cada objetivo:
  • Si no se conoce suficientemente cual va a ser el retorno de inversión, para cada objetivo el cliente indica en forma de dinero el valor que le aportará o lo que pagaría por él, por ejemplo: 1500 €, 1000 €, 750 €, 750 €, 500 €, 500 €, 500 €, etc.
    • De esta manera queda de manifiesto el orden de desarrollo que necesitaría el cliente (en Scrum se planifica el proyecto a partir del valor y del coste de desarrollo de cada objetivo, construyendo la lista de objetivos priorizada o Product Backlog) y qué objetivos tienen para el cliente un valor semejante.
    • Otros criterios de planificación que también se mencionaron fueron los riesgos asociados a cada requisito, las integraciones a realizar con otros equipos y la madurez de cada requisito (de manera que se aprovechase el tiempo del proyecto para que el cliente fuese conociendo más el producto e ir aclarando los requisitos menos maduros).
    • Las metodologías ágiles hacen explícito el balance entre valor y coste de desarrollo, hace más difícil que el cliente priorice igual requisitos que tienen el mismo coste pero valor muy diferente. Por ejemplo, en una web de contenidos multimedia no priorizará igual poder reproducir vídeos (funcionalidad que dispara el número de usuarios) que poner documentos (funcionalidad que con un coste similar que apenas incrementa el número de usuarios).
  • Otra posible medida de valor es cómo se espera que cada funcionalidad contribuya a conseguir una meta de la empresa. En el encuentro se comentó que en Google se mide el valor de nuevas features o aplicaciones en función del número de usuarios que se espera que las vayan a utilizar. Para conseguir la mejor aplicación posible, así como el compromiso y la aportación de los miembros del equipo, se cobra una bonificación en función del cumplimiento de este objetivo.
  • Se mencionaron técnicas de planificación como el Priority Poker (como el Planning Poker pero con cartas del 1 al 9) y el Kano Model con la clasificación de requisitos según sean:
    • Mandatory – Requisitos necesarios que por ellos mismos no aportan valor (por ejemplo que un móvil pueda realizar llamadas).
    • Lineal – Cuantos mejor es el resultado del requisito, más valor tiene el producto (por ejemplo la duración de una batería de móvil).
    • Exciter – El usuario se encuentra con una funcionalidad que no esperaba pero que le gusta mucho.
  • En casos de priorización más complejos y/o con un número de stakeholders alto, puede ser conveniente combinar varias técnicas de priorización por valor. En este caso, puede ser conveniente minimizar el número de stakeholders que intervienen, dado que si sus intereses son demasiado diferentes harían que todos los requisitos acabasen teniendo un grado de prioridad semejante [en Scrum sólo puede haber un único representante de todos los stakeholders, el Product Owner].
El cliente debe poner los medios para ir midiendo el valor que realmente va aportando el proyecto y de esta manera ir aprendiendo cómo asignar valor en próximos proyectos.
 
Hay que notar que la percepción del valor de los requisitos puede ir cambiando según avanza el proyecto (el cliente entiende mejor qué es lo que realmente necesita, la competencia ha sacado una nueva feature al mercado que hay que desarrollar, etc.), lo cual se gestiona en la replanificación que se hace al inicio de cada iteración.
 
Se mencionó la dificultad del trabajo de Product Owner dado que debe predecir cuanto y cómo se consumirá un producto, así como tener ideas brillantes y rompedoras. Esta predicción del futuro consumo (aunque se sirva de técnicas de investigación de mercado y competencia, focus groups, etc.), en principio parece más difícil que gestionar una reunión para que sea productiva (trabajo del Facilitador o Scrum Master) o sea desarrollar una pieza del producto (trabajo del equipo). Si no hay concepto de producto, no hay inversión. Y sin dinero no hay proyecto.
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, la transmisión en directo del encuentro, los snacks y las bebidas.
 
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
Para saber más
 

Estimación y planificación ágil – Resultados del quinto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • Gestión de dependencias entre objetivos de proyecto.
  • Estimación del proyecto por parte de todo el equipo, utilizando días ideales o bien puntos de historia de usuario.
  • Planning Poker para hacer una estimación inicial del proyecto rápida y fiable.
  • Uso de la velocidad de desarrollo para ir proyectando el final del proyecto.
  • Pruebas de concepto para realizar estimaciones.
  • Estimación y planificación de iteración basada en compromiso.
  • La estimación ágil ayuda a crear “conciencia de equipo”
Foto de grupo estimacion y planificacion agil
 

 
Estimación y planificación de proyecto
 
 
Dependencia entre objetivos del proyecto
 
  • Los objetivos (en forma de historias de usuario) que forman la lista de objetivos priorizada del proyecto (Product Backlog) deben ser lo más independientes posibles, para poder demostrarlas y enseñarlas al cliente con la seguridad de que están completadas. De esta manera, el cliente puede tomar decisiones objetivas basándose en los resultados que ya está obteniendo del proyecto y en la velocidad de desarrollo del equipo.
  • Si hay objetivos que son muy dependientes, se puede hacer varias cosas:
    • El objetivo que genera más dependencias se pone antes en el Product Backlog. Los objetivos dependientes se sitúan en algún punto por detrás.
    • En alguna situación puede ser interesante juntar varios objetivos dependientes en uno. Sin embargo, con objetivos excesivamente grandes es más difícil medir el progreso del proyecto y cuesta más tiempo completarlos, por lo que si hay un retraso se tarda más en que sea visible. Por ello, para observar un avance regular en el proyecto, es mejor que los objetivos tengan un tamaño similar y no sean demasiado grandes.
 
La estimación la lleva a cabo el equipo
 
  • La estimación no la realiza el cliente / Product Owner, por que no es él quien se va a “ensuciar las manos” y luchar por cumplir con fechas.
  • Todo el equipo realiza la estimación para:
    • Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
    • Reforzar el compromiso de cada miembro del equipo respecto al resto.
    • Hacer que todo el mundo se sienta oído.
  • La estimación se puede realizar utilizando alguna de las siguientes unidades:
    • Días ideales: los días necesarios para que el equipo pueda completar un objetivo, sin considerar interrupciones. Para pasar a días reales hay que aplicar un factor de corrección que puede ir del 60 % al 70 % de dedicación real al proyecto. Asimismo, habrá que tener en cuenta un margen para imprevistos como bajas por enfermedad, etc.
    • Puntos de historia de usuario: la complejidad que tiene cada historia de usuario. Un equipo en un proyecto determinado es capaz de completar un número semi-regular de puntos de historia cada iteración (“velocidad”).
 
Planning poker
 
La técnica de planning poker permite hacer una estimación inicial del proyecto rápida y fiable, dado que todos los miembros del equipo comparten sus diferentes informaciones y expresan su opinión sin sentirse condicionados por el resto.
A continuación se puede ver diferentes barajas de cartas de planning poker.
 
cartas-planning-poker
 
Cada número significa un peso / esfuerzo / complejidad para completar un objetivo (historia de usuario). La numeración de las cartas está basada en la sucesión de Fibonachi. La distancia entre números crece conforme se hacen mayores. De esta manera, se facilita la decisión sobre qué tamaño tiene un objetivo.
¿Es un 5 o un 8?. No vale la pena entretenerse en pensar si es un 5 o un 6, ni en el error por no intentar buscar esta precisión, dado que se compensará por encima y por debajo con el resto de estimaciones.
 
 
jugando-planning-poker.jpg
José Raya, Jordi Pradel y Alexis Roqué haciendo una demostración de Planning Poker
 
Planning Poker es un proceso iterativo de planificación. Funciona de la siguiente manera:
  • El cliente lee un objetivo (historia de usuario escrita en una tarjeta).
  • El equipo le hace preguntas para entender su alcance.
    • Las respuestas importantes se pueden apuntar en la propia tarjeta como detalles del objetivo o condiciones de satisfacción.
    • Pueden aparecer nuevas historias de usuario.
  • Cada miembro del equipo piensa en el esfuerzo necesario para completar el objetivo y todos muestran sus tarjetas simultáneamente, de manera que no están condicionados por las estimaciones de los otros.
  • Las personas que están más alejadas del consenso explican por qué su votación es más alta (hay algún problema en el que nadie más ha pensado o el resto no ha tenido en suficiente consideración) o más baja (conocen una manera sencilla de resolver el problema, resolvieron algo muy parecido en un proyecto anterior, etc.).
  • El equipo vuelve a votar, hasta que alcanza un acuerdo. No hay democracia, dado que todos deberán comprometerse a que ese objetivo se va a acabar con el esfuerzo acordado (se supone que no hay una persona que siempre vota de manera singular y a la que nunca se puede convencer).
Diversas personas manifestaron que con esta técnica el equipo ha ido mejorando mucho la precisión de sus estimaciones. De hecho, existen diversos estudios que concluyen que la sinergia que produce esta estimación conjunta es mucho mejor que la de una única persona por separado (típicamente la del jefe de proyecto o un senior en un proyecto tradicional).
 
Algunos consejos y trucos:
  • Elegir un objetivo de tamaño típico en el proyecto como patrón con el que comparar el resto de objetivos y asignarle una puntuación de carta también media (por ejemplo un 5).
  • Puede ser conveniente no jugar con las cartas más altas, ya que el error de estimación es mucho mayor (además, objetivos tan grandes dificultan ver el progreso y se tarda más en hacer visible si existen problemas en el proyecto). Notar que en la fotografía de las barajas se han apartado las cartas más altas para no jugar con ellas.
  • Dada la dificultad de empezar a trabajar con puntos de historia y no con esfuerzo en días ideales, para facilitar el empezar a utilizar Planning Poker se puede hacer el símil de que, por ejemplo, dos puntos de historia corresponden a un día ideal.
  • Comparar el tamaño que se va dando a cada objetivo respecto al de otros (triangulación). Ver ejemplo en [2].
 
Velocidad de desarrollo
 
Los puntos de historia permitirán medir la velocidad que tiene el equipo completando objetivos a lo largo e las iteraciones (puntos de historia por iteración) y de esta manera ir proyectando el final del proyecto.
  • Las 2-3 primeras iteraciones la velocidad es más inestable (debido a la complejidad propia de un proyecto: dominio/ requisitos nuevos, tecnología nueva, personas nuevas) y después se va estabilizando, con lo que ya es posible utilizarla para hacer predicciones. Si no se estabiliza, posiblemente es por que existen problemas subyacentes que lo impiden (en la organización, en la estabilidad del equipo, etc.) y que habrá que solucionar.
  • Las estimaciones (y la velocidad) se ven afectadas cuando se introducen nuevas tecnologías o conceptos de negocio en medio del proyecto, aunque después se vuelven a estabilizar.
 
 
Pruebas de concepto para realizar estimaciones
 
  • Si existe incertidumbre para realizar una estimación de un tipo de objetivos (historias de usuario), se puede hacer un spike o prueba de concepto extremo a extremo en una iteración anterior a su desarrollo. Esta investigación permite conocer el grado de dificultad de completar algo y poder estimar mejor las siguientes iteraciones, donde se desarrollarán las historias de usuario reales.
  • La prueba de concepto debe realizarse dentro de un timebox, para obligar a tomar decisiones y no dedicar un tiempo excesivamente largo a investigar.
 
 
Estimación y planificación de iteración basada en compromiso
 
En la reunión de planificación de iteración (Sprint Planning) el equipo va seleccionando objetivos del Product Backlog (historias de usuario) y descomponiéndolos en tareas. Escoge tantos objetivos como cree que es capaz de completar en una iteración (commitment driven sprint planning). La velocidad permite verificar (checkpoint) que el total de puntos de historia de la nueva iteración es congruente con las anteriores iteraciones, si están escogiendo demasiados objetivos o demasiado pocos.
Cada miembro del equipo que escoge una tarea hace su estimación en horas delante de todos, de manera que:
  • Se compromete respecto a sus compañeros.
  • Evita estimaciones demasiado optimistas (que comprometerían las fechas del proyecto) o demasiado pesimistas (que atentarían contra la competitividad de la empresa). De esta manera se disminuyen y ajustan los buffers.
 
La estimación ágil ayuda a crear “conciencia de equipo”
 
Como consecuencia de las técnicas descritas, la estimación ágil crea conciencia de equipo. Todos participan, tienen voz y voto. Cuando se produce una equivocación en una estimación, se ha equivocado todo el equipo. Por ello, no es para individualistas. No sirve que alguien diga “Yo he hecho mi parte de la historia de usuario”.
 
 
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.
 
Agradecer a Telefónica I+D, que también utiliza prácticas de Scrum y XP en sus proyectos, las barajas de cartas de Planning Poker que regaló a los asistentes.
 
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
 
Para saber más