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
 

Comments

Noto con interés que distinguieron "valor entregado" de "velocidad de desarrollo".
Se discutió como llegar a esta distinción? Hablaron de como calcular valor de negocios en forma independiente al tamaño de la historia?
(disclaimer: el comentario anterior fue originalmente posteado en la lista Agile-Spain)

La distinción entre valor entregado y velocidad de desarrollo sería la siguiente:

- Valor entregado: es el beneficio que un ítem del backlog proprociona al cliente (por ejemplo en forma de retorno de inversión).

- Velocidad de desarrollo: la capacidad productiva de un equipo, es decir, cuantos elementos del backlog (contados como puntos de historia o tamaño en días ideales) es capaz de completar en una iteración.

No hay relación entre los dos indicadores ;) Veamos el siguiente ejemplo de manera extrema: una web o red social donde es necesario que el usuario se registre:

- Podríamos llegar a decir que la historia "un usuario se deberá registrar para después poder guardar información propia" apenas aporta valor (aun teniendo un coste de desarrollo importante) puesto todas estas webs ya tienen y necesitan de este proceso de registro.

- Una historia de usuario que permita que una tercera empresa incruste juegos de pago en la web (y que proporcione un porcentaje de beneficios al Product Owner de esta red social) podría tener un coste de desarrollo semejante al caso anterior pero un cambio un valor enorme.

Con la misma velocidad de desarrollo (mismo coste), en el primer caso el Product Owner no obtiene nada diferencial.

Tu comentario nos ayuda a enriquecer el articulo

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <strike> <caption>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
Este formulario es para impedir el abuso de spambots.
Image CAPTCHA
Copy the image characters keeping the upper/lower case.