Regla del noventa-noventa y otras reglas similares

0

Los plazos son quizás el concepto que menos gusta a los programadores. Cuando a un programador le preguntan por plazos, enseguida siente la presión de la soga que se está poniendo él mismo. La verdad es que hay mucha teoría sobre estimación de plazos. Pero aún así, las estimaciones suelen ser cortas y se suele llegar tarde. Hoy os traigo varias reglas, que no son nada científicas. Son más bien aforismos humorísticos. Es decir, reglas que se pueden deducir de la experiencia y que pretenden provocar una sonrisa, más que ayudar en algo.

Regla del noventa noventa

The first 90% of the code accounts for the first 90% of development time. The remaining 10% of the code accounts for the other 90% of the development time.

Tom Cargill, Laboratiorios Bell

El primer 90% del código se corresponde con el primer 90% del tiempo de desarrollo. El restante 10% del código cuenta por el otro 90% del coste de desarrollo.

Por supuesto, la broma de Tom Cargill hace referencia a dos conceptos:

  • A que el programador no es capaz de estimar en qué porcentaje está en el desarrollo. Siempre tenderá a estimar que está cerca del final, cuando le queda todavía gran parte.
  • A que el programador hace estimaciones cortas. Al final tardará un 180% de lo que estimó.

Las medidas para evitar esto son claras:

  • No preguntemos ¿En qué porcentaje estás? Sino, qué tienes acabado. Hasta que no esté acabado no cuenta. Esto suele seguirse bastante en los equipos Scrum, en los que los puntos no cuentan hasta que no se acaba la tarea. O se puede usar el concepto de Casi Acabado.
  • Romper el problema en tareas cortas.

La ley de Hofstadter

Esta ley me parece muy divertida. Del nivel de la ley de Murphy:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Douglas Hofstadter, 1979

Ley de Hofstadter: Siempre dura más de lo que esperabas, incluso cuando tienes en cuenta la ley de Hofstadter

Da igual lo que hagas: te vas a quedar corto en tu estimación. Por supuesto, volvemos a la miopía de estimar tareas complejas o grandes. Pero quizás la lección más importante es que esto nos pasará aunque tengamos en cuenta que nos quedaríamos cortos. Es decir, hacer padding no es la solución. Es mejor seguir las recomendaciones clásicas:

La ley de Lindy

Esta ley inicialmente se creó para estudiar el tiempo de emisión de un programa. ¿Cuál es la esperanza de vida de un programa de televisión?

The life expectancy of a television comedian is inversely proportional to the total amount of his exposure on the medium.

Albert Goldman, 1964

La esperanza de vida de un comediante televisivo es inversamente proporcional a la cantidad total de exposición en el medio.

Lo que venía a decir el Sr. Goldman es que cuanto más sales en la tele, menos durarás. Te quemarás rápido. Le llamó la ley de Lindy, debido a un restaurante llamado “Lindy’s delicatessen in New York” en el que solían actuar los comediantes que habían estado en la tele, y ya no salían.

No tardaron en salir otros autores a estudiar el efecto, y llegaron a conclusiones diferentes. Incluso se propagó el efecto a la duración de cualquier concepto que no estuviese vivo, como Benoit Mandelbrot que se lo llevo a poetas, libros o publicaciones científicas. Lo que se conoce como la ley Lindy actual proviene de la siguiente cita:

If a book has been in print for forty years, I can expect to be in print for another forty years. But, and that is the main difference, if it survives another decade, then it will be expected to be in print another fifty years

Nassim Taleb, 2012

Si un libro se ha estado editando durante cuarenta años, puedo esperar que se siga editando otros 40 años. Pero, y esa es la principal diferencia, si sobrevive otra década, puedo esperar que siga imprimiéndose otros 50 años.

Es decir, cuanto más dura, más se espera que sea su esperanza de vida. Es decir, hablamos de entes que cuanto más viven, más se espera que vivan. No envejecen, todo lo contrario.

Esta lección la podemos aplicar a gestión de proyectos, y sin demasiada imaginación. El propio Taleb, en 2007, nos entregó este ejemplo:

Let’s say a project is expected to terminate in 79 days […]. On the 79th day, if the project is not finished, it will be expected to take another 25 days to complete. But on the 90th day, if the project is still not completed, it should have about 58 days to go. On the 100th, it should have 89 days to go. On the 119th, it should have an extra 149 days. On day 600, if the project is not done, you will be expected to need an extra 1,590 days. As you see, the longer you wait, the longer you will be expected to wait

Nassim Taleb, 2007

Digamos que un proyecto se espera que acabe en 79 días. En el día 79, si el proyecto no ha acabado, esperaré que dure otros 25 días. Pero en el día 90, si todavía no ha acabado, probablemente tardará 58 días más. En el 100, debería tardar 89 en acabar. En el 119, debería tardar otros 149. En el día 600, si el proyecto no ha acabado, esperarás necesitar 1590 días extra. Como se puede ver, cuanto más se espera, más se espera que tarde.

¿Nunca te has sentido en esa situación? Es algo a tener muy en cuenta en proyectos grandes. Cuando ves que las estimaciones iniciales eran malas y que empezamos a retrasarnos, hay que tener en cuenta que si han salido muchos problemas, será probable que salgan muchos más. Y tenemos que pensar en poder cancelar ese proyecto si procede. Muchas veces entramos en una espiral de gasto, en la que no queremos parar el proyecto porque estaremos tirando lo que hemos gastado a la basura. Pero lo importante, como ya os he dicho en otro artículo, no es lo que hemos gastado, sino lo que nos queda por gastar. Mucho cuidado con la ley de Lindy, que cuando aplica puede ser demoledora.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios