Velocidad, trabajo y tiempo: Difference between revisions

From Scrum Manager BoK
No edit summary
 
(11 intermediate revisions by the same user not shown)
Line 15: Line 15:
===Tiempo real y tiempo ideal===
===Tiempo real y tiempo ideal===
Es importante conocer la diferencia entre 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.'''


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.


Para un equipo de cuatro personas con jornada laboral de ocho horas el tiempo real en una semana (cinco días laborables) es:
====Tiempo ideal====
4 * 8 * 5 = 160 horas
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.


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


El tiempo ideal se emplea normalmente en estimaciones, como unidad de trabajo o esfuerzo necesario. Ej: “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.
Es un concepto similar al que [[PSP]]  denomina “Delta Time” como la parte del tiempo laboral que es realmente tiempo efectivo de trabajo.
 
 
{{Párrafo_enmarcado|texto=“Tiempo ideal” no se emplea como unidad de tiempo sino de trabajo o esfuerzo necesario.}}


==Trabajo==
==Trabajo==
Line 35: Line 33:
===Trabajo ya realizado===
===Trabajo ya realizado===


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


 
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'''.
Para medirlo, basta contabilizar lo ya realizado con la unidad empleada: líneas de código, puntos de función, horas trabajadas, etc.
 
 
'''La gestión de proyectos ágil no mide el esfuerzo realizado para calcular el avance del trabajo.'''
 
 
{{Párrafo_enmarcado|texto=La gestión ágil 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.
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===
===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]]).
* 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.
* 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
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.
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”:  
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.
*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.
*Una misma tarea, realizada por una misma personar requerirá diferentes tiempos en o situaciones distintas.
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.
Line 73: Line 58:
**Intentan incrementar la fiabilidad y precisión de los resultados.
**Intentan incrementar la fiabilidad y precisión de los resultados.
**Aumenta el tamaño del trabajo estimado.
**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:
Line 81: Line 65:


===Unidades de trabajo===
===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.
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” “puntos.  
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.
La unidad “Story Point” de eXtreme Programming se define como la cantidad de trabajo que se realiza en un “día ideal”.


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”:
Puede definir su “punto”
*Como tamaño relativo de tareas conocidas que normalmente emplea.  
*Como tamaño relativo de tareas conocidas que normalmente emplea.  
**Ej: 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”.
**'''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.
*En base al tiempo tiempo ideal necesario para realizar el trabajo.
**Ej: Un equipo puede determinar que un “punto” es el trabajo realizado en 4 horas ideales.
**'''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:
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]]
[[File:Velocidad.png|300px|center]]


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