Velocidad, trabajo y tiempo

From Scrum Manager BoK
Revision as of 20:24, 29 May 2013 by Smanager (talk | contribs) (Created page with "__NOTOC__ ==Velocidad, trabajo y tiempo== Velocidad, trabajo y tiempo son las tres magnitudes que mide la gestión de proyectos ágil, y componen la fórmula de la velocidad,...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Velocidad, trabajo y tiempo

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

Velocidad = Trabajo / Tiempo

Así, por ejemplo, se puede decir que la velocidad de un equipo de 4 miembros es de "20 puntos por semana" o de "80 puntos por sprint".

Tiempo

Para mantener un ritmo de avance continuo, el desarrollo ágil emplea dos tácticas posibles: incremento iterativo, o incremento continuo.

 

El avance a través de incrementos iterativos mantiene un ritmo continuo basado en pulsos de sprints. Por esta razón emplea normalmente el sprint como unidad de tiempo, expresando la velocidad como trabajo o tareas realizadas en un sprint.

Nota En Scrum académico esta es la definición de velocidad, porque el marco académico de scrum emplea únicamente incremento iterativo (sprints).

El avance a través de un incremento continuo ajusta un flujo regular de trabajo evitando puntos muertos y cuellos de botella. En este caso, para medir el tiempo se emplean días, semanas o meses, de forma que para expresar la velocidad se habla de trabajo (tareas, puntos…) por semana (o por día, mes…)

Tiempo real y tiempo ideal

Antes de continuar, una observación: la diferencia que se hace en la gestión ágil al hablar de tiempo, entre tiempo “real” y tiempo “ideal”.

Tiempo real, es el efectivo de trabajo. Equivale 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

Sin embargo el término “tiempo ideal” no se emplea para medir tiempo, sino trabajo o esfuerzo necesario, y normalmente en estimaciones, porque se refiere al tiempo que “en condiciones ideales” haría falta para completar una tarea, considerando condiciones ideales: sin ninguna pausa por distracción interrupción o atención a tareas ajenas al trabajo.

Así para determinar el trabajo que se estima, necesario para realizar una tarea se puede hablar de x horas ideales.

Es un concepto similar al que PSP denomina “Delta Time” como la parte del tiempo laboral que es realmente tiempo efectivo de trabajo.

“Tiempo ideal” no se emplea como unidad de tiempo sino de trabajo o esfuerzo necesario.

Trabajo

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

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 contabilizar lo ya realizado con la unidad empleada: líneas de código, puntos de función, horas trabajadas, etc.

Medir el trabajo realizado para estimar el porcentaje de 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, y por lo tanto sea necesario su registro, pero no debe emplearse para calcular el avance del proyecto.


Trabajo pendiente de realizar

Scrum mide el trabajo pendiente para:

  • Estimar el esfuerzo y la duración prevista para completar el trabajo (tareas, historias de usuario o epics).
  • Determinar el avance del proyecto, y en especial en 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 necesario para realizar de un requisito o una historia de usuario no se puede predecir de forma absoluta, porque las funcionalidades no son realidades de solución única, 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á llevarlo a cabo, porque además de la incertidumbre del trabajo, se suman las inherentes al “tiempo”:

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

Sobre estas 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 relacionadas directamente con el producto, como los tradicionales puntos de función de COCOMO; o indirectamente, 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”… 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 las unidades.

Puede basarse en

  • Estimación del tamaño relativo y emplear puntos
  • Estimación del tiempo ideal estimado como necesario para realizar la tarea que se mide.

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

Velocidad es la magnitud determinada por la cantidad de trabajo realizada en un periodo de tiempo

Velocidad en un marco académico de Scrum es la cantidad de trabajo realizada por el equipo en un sprint. Así por ejemplo una velocidad de 150 puntos indica que el equipo realiza 150 puntos de trabajo en cada sprint.

Al trabajar con incremento continuo o en implantaciones flexibles de scrum, que pueden tener sprints de diferentes duraciones o no siempre con el mismo número de miembros en el equipo, la velocidad se expresa indicando la unidad de tiempo y en su caso también si se refiere a la total del equipo, o media por persona. Así por ejemplo: “La velocidad media del equipo es de 100 puntos por semana.” “La velocidad media de una persona del equipo es de 5 puntos por día.”