Velocidad, trabajo y tiempo: Difference between revisions
No edit summary |
|||
(14 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
{{Párrafo_enmarcado|texto=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. | '''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''. | |||
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== | ==Tiempo== | ||
Para mantener un ritmo de avance continuo, el desarrollo ágil emplea dos tácticas posibles: incremento iterativo, o incremento continuo | 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> | <br> | ||
[[File:Marco incremento iterativo continuo.png|700px|center]] | [[File:Marco incremento iterativo continuo.png|700px|center]] | ||
</br> | </br> | ||
===Tiempo real y tiempo ideal=== | ===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. | |||
Es un concepto similar al que | |||
==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. | 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=== | |||
Se puede hacer con unidades relativas al producto (p. ej. líneas de código) o a los recursos empleados (coste, tiempo de trabajo…) | 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. | 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: | 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 | 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 79: | 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 86: | Line 64: | ||
*Descomponer las tareas en subtareas más pequeñas, si las estimaciones superan rangos de medio, o un día de tiempo real. | *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=== | |||
==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” | 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”: | |||
Puede definir su “punto” | |||
*Como tamaño relativo de tareas conocidas que normalmente emplea. | *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. | *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: | 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== | |||
*[[Velocidad]]. | |||
*[[Sprint]]. | |||
*[[Incremento iterativo]]. | |||
*[[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 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.”