Casi en los años de ábaco, concretamente en el 63, un tipo llamado Norden* escribió que los proyectos software (los entonces llamados proyectos) seguían, en lo que refiere al esfuerzo, una distribución de Rayleigh.
Como decía Stephen Hawking, en «Historia del Tiempo«, las ecuaciones ahuyentan lectores, así que me salto pegar la fea fórmula de la distribución de Rayleigh y te la dejo en un dibujo (que, concretamente, es de una charla que di hace también sus años).
Curiosamente, aunque casi nadie lo sepa, la curva de Rayleigh se ha aplicado para explicar cómo se comporta no sólo el esfuerzo, sino también otros atributos en un «proyecto» software, desde años ancestrales hasta ahora, en estos tiempos más ágiles.
Por qué nos interesa en estimación la curva de Rayleigh (entendible para, casi, cualquiera)
Norden usó la curva de Rayleigh, en aquellos viejos tiempos, para explicar (junto con sus correspondientes demostraciones basadas en datos) como se comportaba el esfuerzo y/o el número personas que participaban en un proyecto, al principio ninguna, luego iba subiendo, al principio poco en las fases de requisitos y análisis, del antiguo Cascada, hasta que llegaba a un pico máximo en la programación y luego iba bajando en la antigua fase de mantenimiento (por si acaso te dejo… en agilidad… ¿Existe el “mantenimiento”?), hasta terminar o mantenerse un esfuerzo mínimo (la cola de la derecha de la curva), dado que siempre había algo que hacer.
Aun siendo valido todo lo anterior, la visión «proyecto», frente a la de «flujo continuo», quedó obsoleta (peligros de pensar en proyectos).
Con posterioridad a lo de Norden, otros encontraron que había otra dimensión en el software que seguía el patrón de la curva de Rayleight: los bugs. El primero, salvo que yo me haya colado en algo, que uso la curva de Rayleigh aplicada al comportamiento de los defectos, fue un tal Trachtenberg en el 82, en este artículo, luego hablaron de ello los «famosos» Putnam y Myer, lo puedes leer también en el «Metrics and Models in Software Quality Engineering» (libro con muchas cosas obsoletas, pero siempre se saca algo), etc.
De entre todos los usos dados, en el mundo de software, a la curva de Rayleigh, un clásico es su aplicación en el, siempre entretenido y «levanta pasiones», mundo de la estimación.
En uno de los clásicos sobre estimación, hoy en muchas partes también obsoleto, pero, en mi opinión, aun recomendable (o imprescindible) de leer para aquell@s que quieran hablar de estimación con algo de profundidad y rigor, el Software Estimation: Demystifying the Black Art, de McConnell, 
también se tira de la curva de Rayleigh (curiosamente sin citar la palabra Rayleigh), y en la sección 1.4 del libro nos deja esta figura (espero que McConnell no me denuncie por haberla pegado del libro en este post, ni vosotros por la cutre resolución de la imagen):
En estimación software (y no sólo software), la curva venía a explicar como se comporta la probabilidad que hay de decir cuánto tiempo (esfuerzo, etc.) tardará algo y acertar. Respecto a algo que hay que hacer, hay una estimación (una predicción) que razonablemente, aun con desviaciones, razonables, no se desvía mucho de lo que realmente ocurrirá.
La probabilidad que hay de que la realidad sea superior a lo estimado…
No obstante, dicha una una estimación (p.e. esto creo que nos llevará 5 días) siempre hay una probabilidad de que la realidad sea superior (que, por ejemplo, realmente, nos llevó 40 días).
Incluso, en teoría, hay probabilidad de que la realidad se aleje de la estimación hasta el infinito (al final, nunca terminamos).
Dicha una estimación (5 días) siempre hay probabilidad de que la realidad sea superior, aunque la probabilidad de que la realidad sea superior es cada vez menor según la supuesta realidad se aleja de la estimación (estimé 5 y es más probable que al final sean 6 que 40, pero siempre existe la probabilidad, aun pequeña, de que sean 40).
Sin conocer al, ahora, para ti, famoso, Rayleigh, esto tiene todo el sentido del mundo.
La probabilidad que hay de que la realidad sea inferior a lo estimado…
Pero, ojo, ¿qué pasa con la probabilidad de que dada una estimación la realidad sea menor? Que existe, pero se comportan de manera diferente, porque, en este caso, la curva, por la izquierda, si nos da una probabilidad cero, es decir, que si dices que crees que esto nos llevará 10 días hay, por ejemplo, probabilidad igual a cero de que nos lleve 2 o menos. Imposible.
El umbral inferior imposible, ni añadiendo 100 personas, no se puede (lo que tiene relación con esto “Añadir gente a un proyecto software con retraso hace que se retrase más”).
Nótese que la curva de Rayleigh difiere de la campana de Gauss (que es lo que le viene a todo el mundo a la cabeza), porque la campana de Gauss daría la misma probabilidad, frente estimaciones, a las realidades por arriba y a las de por abajo.
La segunda parte del post está en… Rayleigh para Dummies (y qué tiene que ver con la estimación ágil) (2/2)
.
.
No era previsible, o sí, pero este post se ha ido de madre, así que lo he divido en dos y mañana, importante, ya no te cuento si eres Scrum Master, entraré en cómo aplica, y porque es importante, todo esto en estimación ágil y el uso de los Puntos Historia.
* Lo publicó en un artículo hoy casi imposible de encontrar, en Norden, “Useful Tools for Project Management” Operations Research in Research and Development, B. V. Dean, Ed., John Wiley & Sons, New York, 1963
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Me encanta! debe ser que soy friki de esos 🙂
Es precisamente porque el tiempo de ejecución de tareas sigue aproximadamente una distribución de Rayleigh que el método PERT suele usar tres puntos (optimista, probable y pesimista). En otros ámbitos suele usarse máximo-minimo, o media y desviación, que sería lo adecuado si la distribución fuese Gaussiana (o normal).
Por favor, ¿podrías indicar la leyenda de los ejes de abcisas de las gráficas?.
Gracias de antemano.
Hola, probabilidad (% de cumplimiento) y en X una escala temporal (horas o días)