Inicio arrow Artículos - apuntes arrow Midiendo velocidad, trabajo y tiempo en gestión ágil Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

Midiendo velocidad, trabajo y tiempo en gestión ágil
Valoración del artículo: / 13
MaloBueno 
07.05.2008

tiempoVelocidad, trabajo y tiempo son las tres magnitudes que mide la gestión de proyectos ágil. Las tres componen la fórmula de la velocidad, definiéndola  como cantidad de trabajo realizada en por unidad de tiempo.

Velocidad = Trabajo / Tiempo
Tiempo
En las métricas ágiles el tiempo se puede considerar de dos formas diferentes: como real o como ideal.
Ambas son válidas, y cada organización opta por la que considera más adecuada para ella.
Sea cual sea criterio, éste debe mantenerse de forma homogénea en todas las métricas y estimaciones.

Tiempo real
Tiempo efectivo de trabajo. Es equivalente a la jornada laboral. Para un equipo de cuatro personas con jornada laboral de ocho horas el tiempo real en una semana (cinco días laborables) es:

4 * 8 * 5 = 160 horas

El tiempo real de ese equipo en un sprint de 12 días de trabajo es:

4 * 8 * 12 = 384 horas

Tiempo ideal
Tiempo de trabajo en “condiciones ideales”, esto es, sin ninguna interrupción, pausa, distracción o atención a tareas ajenas a la tarea del sprint que se tiene asignada.
Es el concepto similar al que PSP  denomina “Delta Time”.

 

Trabajo
Medir el trabajo puede ser necesario por dos razones: para registrar el ya realizado, o para estimar anticipadamente, el que será necesario realizar.En ambos casos se necesita una unidad, y un criterio de cuantificación objetivo.

Trabajo ya realizado
Medir el trabajo ya realizado no entraña especial dificultad. Se puede hacer con unidades relativas al producto (p. ej. líneas de código) o a los recursos empleados (coste, tiempo de trabajo…)

Para medirlo basta con contabilizar las unidades que se empleen: líneas de código, horas trabajadas (reales o ideales)... 

Medir el trabajo realizado NO es una métrica Ágil.

LA GESTIÓN ÁGIL NO DETERMINA EL GRADO DE AVANCE DEL PROYECTO POR EL TRABAJO YA REALIZADO, SINO POR EL PENDIENTE DE REALIZAR


Es posible que otros procesos de la organización necesiten registrarlo y medirlo, pero no la gestión ágil de proyectos.

Trabajo pendiente de realizar
Scrum mide el trabajo pendiente para:

  • Estimar el esfuerzo y la duración prevista para cada tarea.
  • Determinar el avance del proyecto, y en especial de cada sprint.

Para Scrum Management, estimar con precisión, de forma cuantitativa y objetiva el trabajo que necesitará la construcción de un requisito, es un empeño más que cuestionable.

El trabajo de un requisito no se puede cuantificar de forma absoluta, porque las funcionalidades no son realidades de solución única.

La “cantidad de trabajo” que consumirá cada funcionalidad o cada historia de usuario no se puede calcular de forma absoluta y objetiva; y en el caso de que se pudiera, la complejidad de la medición haría que la métrica resultante fuera demasiado pesada para la gestión ágil.

Y si no resulta posible estimar con precisión la cantidad de trabajo que hay en un requisito, tampoco se puede saber cuánto tiempo costará, porque además de la incertidumbre del trabajo, se suman las inherentes al “tiempo”:

  • No es realista hablar de de la cantidad o de la calidad del trabajo que realiza una persona al día, o a la hora, porque hay diferencias muy grandes de estos resultados, según las personas.
  • Un misma tarea, realizada por las mismas personas consumirá diferentes tiempos reales en entornos de trabajo diferentes

Sobre estas tres premisas:

  • No es posible estimar con precisión, ni el trabajo de un requisito, ni el tiempo necesario para desarrollarlo.
  • La complejidad de las técnicas de estimación crece exponencialmente en la medida que:

        • Intentan incrementar la fiabilidad y precisión de los resultados.
        • Aumenta el tamaño de la tarea estimada.

    
La estrategia empleada por la gestión ágil es:

  • No empeñarse en estimaciones precisas.
  • Estimar con la técnica “juicio de expertos”
  • Descomponer las tareas de los sprints en sub-tareas más pequeñas, si las estimaciones superan los rangos de las 16-20 horas de de trabajo.


Unidades de trabajo
Las unidades para medir el trabajo pueden estar directamente relacionadas con el producto, como los tradicionales puntos de función de COCOMO, o a través del tiempo necesario para realizarlo.

La gestión ágil suele llamar a las unidades que emplea para medir el trabajo “puntos”, “puntos de funcionalidad” “puntos de historia”… pero se trata siempre de medición a través del tiempo, no del producto.

Así por ejemplo la unidad de medida “Story Point” de Extreme Programming define: la cantidad de trabajo que se realiza en un día de trabajo ideal.

Cada organización, según sus circunstancias y su criterio institucionaliza su métrica de trabajo definiendo el nombre y la definición de las unidades teniendo en cuenta que se basan en el tiempo necesario para ejecutarlo.

Pueden ser: puntos, puntos de función, puntos de historia, días, horas… y referirse a tiempo real o tiempo teórico.

Lo importante no es si emplea uno u otro nombre, si se refiere al trabajo realizado en cuatro o en ocho horas, o si éstas son reales o teóricas.
Lo importante es que la métrica empleada, su significado y la forma de aplicación sea consistente en todas las mediciones, en todos los proyectos de la organización y conocida por todas las personas:

Que se trate de un procedimiento de trabajo institucionalizado.


¿Velocidad, o eficiencia?
Los equipos que miden el trabajo con tiempo ideal, hablan de “Velocidad”.

En los que usan tiempo real se dice que es “eficiencia”.

Al decir, por ejemplo, que la velocidad del sprint ha sido de 23, se refieren a que han completado tareas que medían en toral 23 story points.

Si en el sprint siguiente consiguen una velocidad mayor, querrá decir que han logrado programar más story points en el mismo tiempo, o lo que es lo mismo que han conseguido aumentar el porcentaje de tiempo ideal en la jornada de trabajo: han reducido los tiempos de interrupciones, distracciones o dedicados a otras tareas.

Para los equipos que miden el trabajo con tiempo real, la fórmula de la velocidad, como concepto “velocidad” pierde sentido.

Velocidad = trabajo / tiempo
 
Como el trabajo en tiempo real, numerador y denominador emplean la misma cifra:

 

Velocidad = Trabajo que se puede realizar en la unidad de tiempo / tiempo
 
Estos equipos no incrementan la velocidad por dedicar más tiempo efectivo, puesto que no diferencian entre tiempo ideal y tiempo total.Para incrementar la velocidad, lo que deben hacer es conseguir realizar más trabajo en el mismo tiempo.
 
En realidad es el mismo perro con distinto collar
 
El objetivo en el primer caso es aumentar el porcentaje de tiempo ideal, y en el segundo aumentar los story points que se pueden realizar.Se le puede llamar velocidad o eficiencia, lo importante no son los nombres, ni merece la pena entrar en cuestiones bizantinas.Quizá sea más consecuente hablar de “velocidad” su se trabaja con tiempo ideal, y eficiencia si se hace con tiempo real.
 
 
Trackback(0)
Comentarios (3)Add Comment
Equipos compartidos
escrito por JM, May 08, 2008
Enhorabuena por el artículo, justo ahora estaba enfrascado en estos temas y me ha venido de perlas.

Mi gran duda viene del tema de las personas que no están a tiempo completo, pero tampoco se sabe a qué porcentaje están asignadas al proyecto. Por ejemplo: un proyecto en el que 2 personas están al 100%, pero otras 4 personas realizan tareas esporádicas (admin. de sistemas, testers, gestor de proyectos, etc). ¿Cómo se calcula el tiempo real en estas situaciones?

Un saludo

JM
Duda sobre el Tiempo
escrito por Javier Murillo, May 08, 2008
No se si yo me he liado la verdad, pero el tiempo que cuentas a jornada de 8 horas por persona no debería ser el tiempo teórico, mientras que el tiempo real sea el tiempo efectivo ?
...
escrito por Juan Palacio, May 08, 2008
Hola Javier,

Tienes razón, mejor llamarlo de una sola forma para evitar confusiones.
He retocado el artículo y al tiempo que unas veces llamaba teórico y otras ideal, mejor llamarlo siempre igual. He preferido dejar "ideal" por ser el concepto que emplea Extreme Programming (ideal time).
Tiempo ideal es el tiempo sin ninguna interrupción. Es el delta time del PSP.
Normalmente, si no se tienen datos de experiencia previa, no es ninguna locura suponer que el tiempo ideal pueda ser un 40-50% del tiempo real (de la jornada de trabajo).

Cuando el equipo va trabajando con mediciones ágiles, si emplea tiempo ideal, va conociendo cuál es su velocidad, por tanto el porcentaje que supone el tiempo ideal del tiempo real.

Un saludo.

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative