Puntos frente a horas

La estimación tradicional da lugar a lo que se denomina brillantemente "El cono de incertidumbre". El gráfico muestra que las estimaciones iniciales del trabajo pueden oscilar entre el 400% del tiempo realmente empleado y el 25% del tiempo empleado. Las estimaciones bajas y altas

 

difieren en un factor de dieciséis. A medida que el proyecto avanza y se va asentando más y más, las estimaciones se ajustan cada vez más a la realidad hasta que ya no hay estimaciones, sólo realidad.

A menudo se plantea como un debate entre puntos y horas, pero en realidad no hay debate. La estimación por puntos sigue siendo una estimación, una conjetura, pero ofrece estimaciones mucho más precisas, predecibles y estables. Estimar en horas simplemente dará como resultado estimaciones tan alejadas de la realidad que serán inútiles. Hay razones por las que los proyectos de software tradicionales suelen llegar tarde y por encima del presupuesto. La insistencia en estimar en horas en lugar de en puntos es un factor importante.

Razón 1: A los humanos se nos da mal calcular en horas

El ser humano ha sido capaz de medir el tiempo durante milenios, pero hasta hace unos 150 años (cuando los relojes empezaron a ser más precisos y a estar más disponibles) medir el tiempo en algo más preciso que los días era algo prácticamente desconocido. Esencialmente, la humanidad ha evolucionado durante cientos de miles de años sin utilizar las horas y, como resultado, es mala para estimar en ellas.

Lo que se le da bien al ser humano es estimar el tamaño relativo. Las investigaciones lo confirman. Al principio de la Guerra Fría, el Departamento de Defensa pidió a la RAND Corporation que pronosticara cómo cambiaría la guerra la tecnología moderna. (¿Cuánto tardará un país en desarrollar un arma nuclear?) RAND descubrió que las estimaciones basadas en el tiempo tenían grandes tasas de error y una amplia variabilidad, y que los humanos eran mucho mejores estimando tamaños relativos, en particular los que siguen el Secuencia de Fibonacci. (La secuencia es eficaz en la estimación porque la suma de las cantidades del número mayor es igual al cociente entre el número mayor y el menor. Y, como demuestra tan acertadamente el vídeo de la izquierda, es un patrón que la raza humana ha visto en todas partes en el mundo natural desde el principio de los tiempos).

Un estudio reciente de Microsoft en el que se analizaron dos equipos Scrum (uno estimaba en horas y el otro en puntos) mostró resultados similares. El equipo que estimaba en puntos tenía una tasa de error de +/- 25%, mientras que el equipo que estimaba en horas tenía una tasa de error tan grande como +/- 400% (denotada como la línea gris claro en la diapositiva de su derecha).

Otra ventaja de estimar el tamaño relativo es que es más rápido que intentar planificar cuántas horas se tardará en completar un trabajo.

Razón 2: El uso de horas resta velocidad

En Scrum, la Velocidad se utiliza tanto para proyectar rápidamente cuánto esfuerzo se necesita para completar un trabajo, como métrica para determinar cómo afecta a la productividad un cambio en el proceso. (Si la producción aumenta, mantenga el cambio de proceso; si no, vuelva al proceso anterior). Si un equipo mide en horas, será imposible calibrar el rendimiento o medir la productividad.

Esto se debe a que las horas miden los insumos y el Scrum se basa en la medición de los resultados. Por ejemplo, si un miembro del equipo tarda una hora en completar un trabajo y otro tarda dos horas en completar el mismo trabajo, el resultado (el trabajo completado) es el mismo a pesar de la diferencia de tiempo invertido en el trabajo. La estimación del rendimiento debe ser la misma independientemente de quién realice el trabajo. La velocidad mide el esfuerzo colectivo del equipo y no la aportación de un miembro individual.

Razón 3: El tiempo es finito

Una semana laboral normal sólo dura 40 horas. Si el esfuerzo se mide en horas, un equipo de 5 miembros nunca puede superar las 200 horas de trabajo en una semana. Hiperproductivo Scrum Los equipos aumentan la producción en 400% o más. Para obtener estos beneficios en horas, cada miembro del equipo tendría una semana laboral de 160 horas. Esto no es posible y, desde luego, no es Ritmo sostenible.

La mejora se produce cuando el equipo en su conjunto se vuelve más eficiente a través de la mejora tanto del proceso como de las prácticas. Si antes un miembro del equipo tardaba dos horas en completar un trabajo y ahora puede hacerlo en una, su rendimiento se ha duplicado, pero el tiempo que ha dedicado al trabajo se ha reducido a la mitad. Medir en horas nunca reflejaría su mejora.

Mientras esté conceptualmente ligada al tiempo, la velocidad no tendrá valor.

A menudo, las organizaciones se resisten a utilizar puntos porque a la dirección le preocupa que los equipos inflen artificialmente la cantidad de puntos que se necesitan para realizar un trabajo. ¿Por qué no estimar un trabajo en cinco puntos de esfuerzo en lugar de los tres que vale en realidad, creando dos puntos de inflación y aumentando artificialmente la Velocidad?

Independientemente de la validez de esta preocupación, es más probable que los equipos desinflen el valor de los puntos.

Por ejemplo, el miembro del equipo que ahora puede completar su trabajo en una hora en lugar de dos podría inclinarse a estimar ese mismo trabajo en un valor de puntos más bajo en una futura reunión de Planificación del Sprint porque siente que le requiere menos esfuerzo ahora que ha mejorado su productividad. Esto es deflación de puntos. Su producción es la misma, por lo que el trabajo debe estimarse con el mismo valor en puntos.

Sin embargo, tanto la inflación como la deflación pueden medirse y controlarse utilizando las métricas de gestión Scrum.

(Las horas también sufren presiones inflacionistas porque suelen utilizarse para comparar el esfuerzo de los empleados. Mediante una técnica denominada Mapeo del flujo de valor muestra que pocas empresas alcanzan una eficiencia de procesos superior a 15% sin un esfuerzo concentrado. Ningún empleado quiere admitir que de una semana laboral de 40 horas sólo ha realizado 6 horas de trabajo real).

Puntos

El Scrum Lenguaje Patrón de Programación : El movimiento PLoP codifica prácticas ágiles bien conocidas que se han aplicado con éxito en numerosas ocasiones.