Velocidad, trabajo y tiempo: Difference between revisions

From Scrum Manager BoK
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,..."
 
 
(27 intermediate revisions by 2 users not shown)
Line 1: Line 1:
__NOTOC__
__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, definiéndola como: cantidad de trabajo realizada por unidad de tiempo.
{{Párrafo_enmarcado|texto=Velocidad = Trabajo / Tiempo}}
{{Párrafo_enmarcado|texto=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".
'''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.
 
===Tiempo===
 
Para mantener un ritmo de avance continuo, el desarrollo ágil emplea dos tácticas posibles: incremento iterativo, o incremento continuo.
 
[[File:Incremento iterativo incremento continuo.png|650px|thumb|center]]
 
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, [[Punto de historia|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.
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''.
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
==Tiempo==
Para mantener un ritmo de avance continuo, el desarrollo ágil emplea dos tácticas posibles: '''incremento iterativo''' o '''incremento continuo''':
*'''Incremento iterativo.''' El avance a través de incrementos iterativos '''mantiene el ritmo apoyándose en pulsos de sprints'''. Por esta razón emplea normalmente el ''sprint'' como unidad de tiempo, y expresa la velocidad como trabajo o tareas realizadas en un ''sprint''. Scrum técnico usa incremento iterativo, y por tanto define la velocidad como la cantidad de trabajo realizado en un ''sprint''.
*'''Incremento continuo.''' El avance a través de un incremento continuo '''mantiene un flujo de avance constante sin puntos muertos ni cuellos de botella'''. No hay ''sprints'', y por tanto las unidades de tiempo son días, semanas o meses, de forma que que la la velocidad se expresa en “puntos” (cantidad de trabajo) por semana, día, o mes.
<br>
[[File:Marco incremento iterativo continuo.png|700px|center]]
</br>
===Tiempo real y tiempo ideal===
Es importante conocer la diferencia entre tiempo “real” y tiempo “ideal”.
====Tiempo real====
Es el tiempo de trabajo. '''Equivale a la jornada laboral.'''


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.  
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.


Así para determinar el trabajo que se estima, necesario para realizar una tarea se puede hablar de x horas ideales.
====Tiempo ideal====
Se refiere sin embargo al tiempo de trabajo en condiciones ideales, esto es, eliminando todo lo que no es estrictamente “trabajo”, suponiendo que no hay ninguna pausa por interrupción o atención de cuestiones ajenas a la tarea y que la persona se encuentra en buenas condiciones de concentración y disponibilidad.


Es un concepto similar al que PSP  denomina “Delta Time” como la parte del tiempo laboral que es realmente tiempo efectivo de trabajo.
El tiempo ideal se emplea normalmente en estimaciones, como '''unidad de trabajo o esfuerzo necesario'''. Por ejemplo: “Esa tarea tiene un tamaño de 3 horas ideales”.


{{Párrafo_enmarcado|texto=“Tiempo ideal” no se emplea como unidad de tiempo sino de trabajo o esfuerzo necesario.}}
Es un concepto similar al que PSP denomina “Delta Time” como la parte del tiempo laboral que es realmente tiempo efectivo de trabajo.


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


====Trabajo ya realizado====
===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 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…). Basta con 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.'''
Sin embargo, la gestión de proyectos ágil no mide el esfuerzo realizado para calcular el avance del trabajo. Es decir, '''no determina el grado de avance del proyecto por el trabajo realizado, sino por el pendiente de realizar'''.


{{Párrafo_enmarcado|texto=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 registrar el esfuerzo invertido, y por lo tanto sea necesario su registro, pero no debe emplearse para calcular el avance del proyecto.


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===
 
 
====Trabajo pendiente de realizar====


Scrum mide el trabajo pendiente para:
Scrum mide el trabajo pendiente para:
* Estimar esfuerzo y tiempo previsto para realizar un trabajo (tareas, [[Historia de usuario|historias de usuario]] o [[Epic|epics]]).
* Determinar el avance del proyecto, y en especial en cada ''sprint''.


* Estimar el esfuerzo y la duración prevista para completar el trabajo (tareas, historias de usuario o epics).
Determinar con precisión, de forma cuantitativa y objetiva el trabajo que necesitará la construcción de un requisito es un empeño cuestionable.
* 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 prever 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 una métrica demasiado pesada para la gestión ágil.


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 necesitará, 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 unidad de tiempo, porque son muy grandes las diferencias de unas personas a otras.
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”:  
*Una misma tarea, realizada por una misma personar requerirá diferentes tiempos en o situaciones distintas.
 
* 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:
Sobre estas premisas:
 
*No es posible estimar con precisión, ni el trabajo de un requisito, ni el tiempo necesario para desarrollarlo.
* 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:
* 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.
**Intentan incrementar la fiabilidad y precisión de los resultados.
**Aumenta el tamaño de la tarea estimada.
**Aumenta el tamaño del trabajo estimado.


La estrategia empleada por la gestión ágil es:
La estrategia empleada por la gestión ágil es:
*Trabajar con estimaciones aproximadas.
*Estimar con la técnica “juicio de expertos.
*Descomponer las tareas en subtareas más pequeñas, si las estimaciones superan rangos de medio, o un día de tiempo real.


*No empeñarse en estimaciones precisas.
===Unidades de trabajo===
*Estimar con la técnica “juicio de expertos”
Un trabajo puede dimensionarse midiendo el producto que se construye, como los tradicionales puntos de función de COCOMO; o el tiempo que cuesta realizarlo.
*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.
En gestión ágil se suelen emplear “puntos” como unidad de trabajo, empleando denominaciones como “puntos de historia” o simplemente “puntos”. 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
Puede definir su “punto”:
*Estimación del tamaño relativo y emplear puntos
*Como tamaño relativo de tareas conocidas que normalmente emplea.
*Estimación del tiempo ideal estimado como necesario para realizar la tarea que se mide.
**'''Ejemplo:''' el equipo de un sistema de venta por internet, podría determinar que un “punto” representara el tamaño tiene un “listado de las facturas de un usuario”.
*En base al tiempo tiempo ideal necesario para realizar el trabajo.
**'''Ejemplo:''' un equipo puede determinar que un “punto” es el trabajo realizado en 4 horas ideales.


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:
Es importante que la métrica empleada, su significado y la forma de aplicación sea consistente en todas las mediciones de la organización, y conocida por todas las personas: '''Que se trate de un procedimiento de trabajo institucionalizado'''.


Que se trate de un procedimiento de trabajo institucionalizado.
==Velocidad==


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


Velocidad es la magnitud determinada por la cantidad de trabajo realizada en un periodo de tiempo
[[File:Velocidad.png|300px|center]]


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.
Velocidad en scrum técnico 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 en implantaciones de scrum pragmático, que pueden realizar ''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 a la 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.


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.”
==Véase también==
*[[Velocidad]].
*[[Sprint]].
*[[Incremento iterativo]].
*[[Incremento continuo]].
*[[Tiempo ideal]].
*[[Tiempo de producción]].
*[[PSP]].
[[Category:Standard scrum]]
[[Category:Glosario de términos]]

Latest revision as of 12:57, 22 December 2023

Velocidad = Trabajo / 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.

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:

  • Incremento iterativo. El avance a través de incrementos iterativos mantiene el ritmo apoyándose en pulsos de sprints. Por esta razón emplea normalmente el sprint como unidad de tiempo, y expresa la velocidad como trabajo o tareas realizadas en un sprint. Scrum técnico usa incremento iterativo, y por tanto define la velocidad como la cantidad de trabajo realizado en un sprint.
  • Incremento continuo. El avance a través de un incremento continuo mantiene un flujo de avance constante sin puntos muertos ni cuellos de botella. No hay sprints, y por tanto las unidades de tiempo son días, semanas o meses, de forma que que la la velocidad se expresa en “puntos” (cantidad de trabajo) por semana, día, o mes.



Tiempo real y tiempo ideal

Es importante conocer la diferencia entre tiempo “real” y tiempo “ideal”.

Tiempo real

Es el tiempo 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.

Tiempo ideal

Se refiere sin embargo al tiempo de trabajo en condiciones ideales, esto es, eliminando todo lo que no es estrictamente “trabajo”, suponiendo que no hay ninguna pausa por interrupción o atención de cuestiones ajenas a la tarea y que la persona se encuentra en buenas condiciones de concentración y disponibilidad.

El tiempo ideal se emplea normalmente en estimaciones, como unidad de trabajo o esfuerzo necesario. Por ejemplo: “Esa tarea tiene un tamaño de 3 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.

Trabajo

Medir el trabajo puede ser necesario por dos razones: para registrar el ya hecho, o para estimar anticipadamente, el que se debe 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…). Basta con contabilizar lo ya realizado con la unidad empleada: líneas de código, puntos de función, horas trabajadas, etc.

Sin embargo, la gestión de proyectos ágil no mide el esfuerzo realizado para calcular el avance del trabajo. Es decir, no determina el grado de avance del proyecto por el trabajo realizado, sino por el pendiente de realizar.

Es posible que otros procesos de la organización necesiten registrar el esfuerzo invertido, 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 esfuerzo y tiempo previsto para realizar un trabajo (tareas, historias de usuario o epics).
  • Determinar el avance del proyecto, y en especial en cada sprint.

Determinar con precisión, de forma cuantitativa y objetiva el trabajo que necesitará la construcción de un requisito es un empeño cuestionable.

El trabajo necesario para realizar de un requisito o una historia de usuario no se puede prever 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 una métrica 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 necesitará, 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 unidad de tiempo, porque son muy grandes las diferencias de unas personas a otras.
  • Una misma tarea, realizada por una misma personar requerirá diferentes tiempos en o situaciones distintas.

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 del trabajo estimado.

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

  • Trabajar con estimaciones aproximadas.
  • Estimar con la técnica “juicio de expertos.
  • Descomponer las tareas en subtareas más pequeñas, si las estimaciones superan rangos de medio, o un día de tiempo real.

Unidades de trabajo

Un trabajo puede dimensionarse midiendo el producto que se construye, como los tradicionales puntos de función de COCOMO; o el tiempo que cuesta realizarlo.

En gestión ágil se suelen emplear “puntos” como unidad de trabajo, empleando denominaciones como “puntos de historia” o simplemente “puntos”. Cada organización, según sus circunstancias y su criterio institucionaliza su métrica de trabajo definiendo el nombre y las unidades.

Puede definir su “punto”:

  • Como tamaño relativo de tareas conocidas que normalmente emplea.
    • Ejemplo: el equipo de un sistema de venta por internet, podría determinar que un “punto” representara el tamaño tiene un “listado de las facturas de un usuario”.
  • En base al tiempo tiempo ideal necesario para realizar el trabajo.
    • Ejemplo: un equipo puede determinar que un “punto” es el trabajo realizado en 4 horas ideales.

Es importante que la métrica empleada, su significado y la forma de aplicación sea consistente en todas las mediciones 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 scrum técnico 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 en implantaciones de scrum pragmático, que pueden realizar 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 a la 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.”

Véase también