Noventa y noventa regla en la práctica

El primer 90 por ciento del código representa el primer 90 por ciento del tiempo de desarrollo. El 10 por ciento restante del código representa el otro 90 por ciento del tiempo de desarrollo.

- Tom Cargill, Bell Labs

¿Qué significa eso exactamente en la práctica? ¿Que los programadores realizan una cantidad considerable de trabajo y que están dando el 180% de sí mismos o?

Imagínelo así: cuando comienza a trabajar en software, puede escribir grandes cantidades de código en un tiempo relativamente corto. Este nuevo código puede agregar una gran cantidad de nuevas funcionalidades. El problema es que, a menudo, esa funcionalidad está lejos de estar "hecha", puede haber errores, pequeños cambios (pequeños en las pequeñas empresas), etc. Por lo tanto, el software puede parecer que está casi listo (90% listo), porque admite la mayoría de los casos de uso. Pero el software aún necesita trabajo. El objetivo de esta regla es que, a pesar de que el software se siente como si estuviera casi terminado, la cantidad de trabajo para llevar ese software al estado de funcionamiento correcto es tan grande como llegar a ese estado "casi terminado". Esto se debe a que la corrección de errores suele llevar mucho tiempo pero no produce mucho código.

El problema es que la mayoría de los desarrolladores estiman llevar el software al estado "casi listo", porque eso es relativamente simple en comparación con la estimación del esfuerzo total que tomará el software.

Es una referencia a un escenario común, que lamentablemente todavía ocurre hoy:

1. Se le pide al equipo que calcule (es decir, adivine) la cantidad de trabajo necesaria para escribir todo el código,
2. El proyecto continúa con numerosas presiones internas y externas para "mantenerse a tiempo y presupuestado",
3. Entonces, para un porcentaje significativo del proyecto, se informa "en el objetivo". Esto a menudo se complica al elegir las tareas fáciles primero para garantizar que se haga un buen progreso.
4. Luego, en algún momento, se alcanza un punto crítico donde la realidad tiene que ser aceptada: el proyecto no se completará a tiempo y la fecha de lanzamiento se retrasa (a menudo muchas veces).

"90%" es una cifra arbitraria, pero aclara bien: las estimaciones son suposiciones y probablemente serán erróneas (a menudo muy erróneas) y la naturaleza humana garantiza que casi siempre se subestime, por lo que las cosas se desbordan.

He escuchado una versión diferente de esto (también llamada "regla 90-90") que dice así:

Después de haber implementado el 90% de la funcionalidad, todavía tengo que implementar el otro 90% .

Ambas versiones se refieren a la dificultad de estimar correctamente el esfuerzo para desarrollar productos de software y las dificultades comunes en las que las personas tienden a caer:

• lanzar estadísticas cuando se requieren estimaciones y esencialmente adivinar ("Estoy hecho al 80%")
• centrarse en la complejidad algorítmica del código que se va a escribir, en detrimento del volumen de trabajo (subestimando el esfuerzo requerido para tareas comunes)
• pasos faltantes ("fuera de la vista, fuera de la mente")
• subestimar el esfuerzo para mantener y cambiar el código existente
• Subestimar el esfuerzo requerido para el código repetitivo / "pegamento"

Esta regla complementa la regla 80-20. Ahora, hay muchas interpretaciones diferentes de la regla 80-20, pero las dos que más me gustan son:

1. El primer 80% de desarrollo de productos requiere un 20% de esfuerzo.
2. El 80% de los errores están en el 20% del código.

En la práctica, esto significa lo siguiente: el desarrollo comenzará y continuará hasta cierto punto cuando se noten los primeros retrasos. Los retrasos pueden ser de diversa naturaleza:

• Mal control de calidad, lo que resulta en errores
• Requisitos adicionales que el cliente planteó en el camino (y las razones para esto también pueden ser múltiples)
• Requisitos poco claros desde el principio, que provocan la caída de partes del desarrollo anterior (lo que también puede provocar errores de regresión)
• Subestimaciones iniciales debido a un alcance poco claro, error humano o circunstancias imprevistas. Estas circunstancias imprevistas pueden ser hojas enfermas, renuncias, fallas de hardware o, en casos extremos, erupciones de volcanes (una vez que tuvimos que retrasar un proyecto porque no pudimos volar en el sitio debido a una erupción de volcán en Islandia).

La conclusión es que es mucho más fácil acercarse a la meta que alcanzarla.

La explicación de Wikipedia me parece bastante esclarecedora:

Esto suma hasta un 180% en una alusión irónica a la notoriedad de los proyectos de desarrollo de software que superan significativamente sus cronogramas (consulte la estimación del esfuerzo de desarrollo de software). Expresa tanto la asignación aproximada de tiempo a partes fáciles y difíciles de un proyecto de programación como la causa de la demora de muchos proyectos como la falta de anticipación de las partes difíciles. En otras palabras, se necesita más tiempo y más codificación de lo esperado para que un proyecto funcione.

¿Qué significa eso exactamente en la práctica? ¿Que los programadores realizan una cantidad sustancial de trabajo y que están dando 180% de sí mismos o?

No, los programadores siempre hacen la misma cantidad de trabajo por unidad de tiempo. La cita trata de subestimar el costo y los excesos. El 180% es la cantidad de tiempo y dinero que el proyecto termina costando.

Más o menos significa "Te llevará el doble de tiempo de lo que crees" y "Pensarás que te está yendo bien hasta que ya sea demasiado tarde (la fecha límite está cerca)".

Lo que esto significa en la práctica es que las personas se mienten a sí mismas.

Si un programador dice "hemos terminado el 90%", significa que se ha gastado el 90% del esfuerzo para crear las características.

Si un gerente de proyecto dice "hemos terminado en un 90%, solo necesito que alguien lo termine", significa que tienen un 90% del presupuesto (y probablemente un 50% terminado). Este es un cliente sin dinero, altas expectativas y una mala actitud.

La diferencia es que se necesita más esfuerzo que las funciones de codificación para finalizar un proyecto: qa, corrección de errores, ediciones de copia, implementación.

Esas cosas deben gestionarse en el proyecto y son responsabilidad del gerente del proyecto. Esto a menudo sorprende a los nuevos PM que llegan al "90% de características completas" solo para darse cuenta de que están a mitad de camino del "proyecto terminado".