Rss Feed Tweeter button Facebook button Linkedin button

subscribe: Posts | Comments | Email

Métricas Ágiles (II)

1 comment
Métricas Ágiles (II)

Hay algo más que Burndowns.

El más conocido de los indicadores de seguimiento o métricas de estado de un proyecto ágil es el Burndown Chart. En él, se representa de manera muy sencilla el avance del Sprint o de todos los Sprints planificados en el proyecto (BurnUp).  Otro indicador habitual es la Velocidad del equipo. Hay muchas otras métricas ágiles que se pueden emplear, pero para empezar vamos a describir aqui lo que es más conocido por todo el mundo que usa Scrum.

Burndown Charts.

Mediante esta sencilla gráfica todo el equipo Scrum puede visualizar si el Sprint se dirige hacia el objetivo de entregar todos los puntos de historia planificados o si por el contrario hay algún impedimento que lo retrasará o más cantidad de trabajo para recoger del Product Backlog.

Pintarlo es fácil. Actualizarlo requiere disciplina. Disciplina para que tras cada reunión diaria del equipo, típicamente el Scrum Master se encargue de actualizar las estimaciones de trabajo restante para cada una de las historias o tareas que el equipo haya decidido acometer en el Sprint. Esa es la clave para su obtención, y también es la clave para obtener una métrica realista ( Agil es honestidad y transparencia, como mencioné en el artículo anterior ) basada en la información del que realmente está produciendo el SW, el programador. Un Project Manager que actualiza un GanttChar, por regla general no se basa en  esta información tan directa y diaria para actualizar los % de avance de las tareas. De ahi que el Burndown Chart sea una métrica de seguimiento de avance muy creíble y realista. En mi opinión mucho más realista que los % de avance de un Gantt.

Burndown chart

Velocidad del equipo.

Por otra parte, otro de los indicadores habituales es la métrica de velocidad. Se podría definir como el número de puntos de historia que el equipo es capaz terminar durante el Sprint. Es importante no confundir velocidad con productividad. La velocidad es una medida de la capacidad del equipo, no de lo buenos, malos o poco productivos que sean.  Derivar la métrica de la velocidad hacia la productividad de un equipo es una torpe decisión ya que hay multitud de factores externos que pueden afectar a la productividad y que muchas veces no son culpa del equipo ( malas prácticas de gestión, cambio continuo de tareas, falta de conocimientos de algún miembro del equipo, ineficacia del Product Owner, etc etc).

Esta métrica tiene su utilidad para poder saber a  cuantos puntos de historia se podrá comprometer el equipo para cada iteración conociendo la velocidad a la que es capaz de trabajar.

Se basa en la tendencia, y se obtiene el dato bueno  normalmente tras el tercer o cuarto Sprint. Al principio, el equipo suele ser más optimista y selecciona más puntos de historia de los que puede terminar. Al segundo Sprint , ocurre al contrario, peca de pesimista. Al tercero, va a justando a la realidad de los proyectos ( impedimentos, retrabajo, cambio de prioridades…. ) y ya en el cuarto suele obtener una medida más o menos realista que puede conducirnos, por extrapolación respecto al total de puntos de historia del proyecto y al total de Sprints planificados, a obtener una tendencia que nos indicará si seremos capaces de conseguir los objetivos definidos.

Un equipo maduro y que viene trabajando de manera conjunta desde hace tiempo , parte de una situación de ventaja pues la velocidad es conocida al inicio del proyecto. Sin embargo, normalmente  muchos equipos se deshacen  al finalizar los proyectos , o lo que es peor y también muy habitual, se producen entradas y salidas de miembros del equipo. Todas estas situaciones contribuyen a que no podamos poner el “control de crucero de la velocidad” y más bien vamos a ir a acelerones hasta conseguir cohesión de todos los componentes.

Su cálculo es muy sencillo :

Velocidad = ( nº desarrolladores del equipo *dias de duración del Sprint )  *  Factor de Foco %

Donde

Factor de Foco  ( FF%) es el % del dia que las personas del equipo son plenamente productivas y pueden estar dedicadas al 100% a la producción de Software , sin verse afectados por otros impedimentos, reuniones o  tareas auxiliares.  Suele fijarse de partida entre el 60% y el 70 %, dependiendo de la madurez del equipo, y se va recalculando iteración tras iteración.

Por ejemplo:

Supongamos los siguientes datos de partida.

  • Nº de desarrolladores del equipo.  = 4
  • Factor de Foco inicial (FF) =  70 %
  • Dias de duración del Sprint = 15

SPRINT 1

Velocidad = (4*15)*70% = 42

El equipo podrá cojer historias del Product Backlog que entre todas sumen un máximo de 42 puntos de historia. Cogen 42, pero no terminan todo. Solo entregan por 35.

 Velocidad ideal = nº desarrolladores *  dias ideales.

Si el equipo se quedó en 35 puntos de historia entregados al final del Sprint, hay que recalcular la velocidad para el siguiente Sprint.

Velocidad ideal = 4*15 = 60

Velocidad real = 35

Ffoco=35/60 = 0,58% (significa que la capacidad estaba sobreestimada por el equipo)

 SPRINT 2

Recalculamos la velocidad

Velocidad =(4*15)*0,58 = 34,8 (redondeo a 35) puntos de historia que el equipo podrá abordar para el siguiente Sprint.

Cogen 34, y además de cumplirlo, cogen más historias por 10 puntos más

 Velocidad ideal = nº desarrolladores * dias ideales.

Velocidad ideal = 4*15 = 60

Velocidad real = 34+10 = 44

Ffoco=v.real/v.ideal 44/60 = 0,73.

SPRINT 3

Recalculamos la velocidad teniendo en cuenta que hay que recalcular el FF para el Sprint 3, como la media del FFinicial  y el FFreal

FF para Sprint 3 = (0,58+0,73)/2 = 0,65.

 Velocidad =(4*15)*0,65 = 39 puntos de historia que el equipo podrá abordar para el Sprint 3.

El equipo se encuentra con un impedimento y solo puede entregar 20 puntos de historia.

Velocidad ideal = nº desarrolladores * dias ideales.

Velocidad ideal = 4*15 = 60

Velocidad real = 20

Ffoco=v.real/v.ideal 20/60 = 0,33.

SPRINT 4

 Recalculamos la velocidad teniendo en cuenta que hay que recalcular el FF para el Sprint 4, como la Media del FF inicial  y el FF real     :

FF para Sprint 3 = (0,65+0,33)/2 = 0,49.

 Velocidad =(4*15)*0,49 = 29,4 puntos de historia que el equipo podrá abordar para el Sprint 4.

 

Analizando la tendencia :

  • Sprint 1 –  Velocidad inicial  = 42    Velocidad Real = 35     No llego a todo
  • Sprint 2 –  Velocidad inicial  = 35    Velocidad Real = 44      Llego y cojo más
  • Sprint 3 –  Velocidad inicial  = 39    Velocidad Real = 20      Impedimento
  • Sprint 4 –  Velocidad inicial  = 29    …………

 

CONCLUSIONES.

Total Sprints planificados = 8

Total puntos historia comprometidos en el total del proyecto = 310

Con 3 sprints hemos sido capades de entregar  99  puntos.

La Velocidad Media por Sprint es de 33 puntos de historia.

 

Luego, si proyectamos estos resultados :

Proyección = 8 Sprints * 33 puntos de media por cada uno =  264.

 

ALGO NO VA BIEN EN EL PROYECTO : nos vamos a quedar lejos de entregar todo lo que se había definido. Podremos entonces adoptar medidas tempranas para minimizar los riesgos y lo más importante, en poco tiempo seremos capaces de ver esta situación y actuar para evitarla.  Se representa gráficamente con una gráfica similar a la que podéis ver abajo :en el eje de las Y se representa el total de puntos de historia y en el eje de las X se representa cada Sprint del proyecto.

Pero como dice el título del artículo : Hay algo más que Burndows, como por ejemplo :

  • Número de Test de caracterísiticas pasados (RTF – Running Tested Features )
  • Valor de Negocio entregado – Business Value Burn-up.
  • Resultados de los Test  unitarios y de aceptación – una medida de la calidad
  • Recuento de bugs- una medida de la calidad
  • Defectos provocados post-Sprint
  • Defectos resueltos. (indicador rezagado)
  • Deuda Técnica y su tendencia.
  • WTF`s x minuto.  ( ¿que será esto?… Sigue la serie y lo descubrirás….. 😉
  • El trabajo en proceso – una métrica de productividad Lean.
  • Lead Time.
  • Cycle Time.
  • Touch Time

 

Pero todo esto os lo contaré ya en el tercer artículo de la serie.

  1. Interesante y claro. Pero me surge una duda de cara a la utilización de dichas métricas para el control del desarrollo interno del proyecto:

    Si no he entendido mal, se parte de la utilización en el desarrollo de metodologías ágiles, pero si esto no es así y se esta utilizando metodologías más “clásicas” basadas en ciclos de vidas más tradicionales como un ciclo de vida en cascada o secuencial ¿Se podrían aplicar de igual forma las métricas referenciadas en el articulo o se tendría que hacer ciertas actuaciones previas paralelas a la gestión del proyecto?. ¿Incidiría mucho la fase de requisitos?.

    Gracias y un saludo?.

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *


*