Diferencia entre revisiones de «Velocidad Trabajo Tiempo»

Revisión del 14:54 14 mar 2009

Tomado de Midiendo velocidad, trabajo y tiempo en gestión ágil de Navegapolis (Derechos (c))

Velocidad, 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 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 total 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” si se trabaja con tiempo ideal, y eficiencia si se hace con tiempo real.

Ver también

Graficos Scrum