El difícil problema de la estimación

Este artículo fue publicado anteriormente en dotNetmania.


Realizar estimaciones es uno de los más complejos problemas de los varios que los desarrolladores de software enfrentamos día a día. Además es uno que históricamente hemos fallado a la hora de resolver. Por eso precisamente es esta la cuestión que he elegido para mi primera participación en esta columna.

Aprovecho también para comentar que no pretendo dar desde estas páginas soluciones concretas, más que nada porque, en mi opinión, en el desarrollo de software no existen recetas universales, sino mover a la gente que la lea a pensar de otra manera, de una manera ágil, en los problemas que nos encontramos día a día cuando tratamos de desarrollar software.

Voy a hablar, en la presente entrega, sobre que armas hemos utilizado tradicionalmente los desarrolladores a la hora de realizar estimaciones, de cómo este es un problema complejo, quizás irresoluble, y de cómo las metodologías ágiles los asumen y conviven con ello. Pero antes de nada me gustaría dejar claro, una vez más, que en este tema, quizás más que en ningún otro, la única verdad absoluta es que ha quedado totalmente demostrado que no existen balas de plata.

Hagamos un repaso de cómo se ha enfrentado el problema de la estimación hasta ahora y que ventajas y problemas, a muy grandes rasgos, tiene cada aproximación.

Primero, se utilizo el juicio del experto. Es un enfoque simple y directo. Basta con buscar a un desarrollador que haya desarrollado un sistema lo más similar posible al que queremos estimar y que nos diga cuál es su estimación. Las pegas de esta aproximación son: Primero, que es difícil encontrar alguien que haya construido un sistema lo suficientemente similar como para obtener una buena estimación, se suelen desarrollar sistemas que no existen, si lo que necesita nuestro cliente ya existe es mejor que simplemente lo compre. Segundo, cada proyecto es un mundo. Cada proyecto evoluciona de un modo diferente, se desarrolla en un entorno diferente, con un equipo diferente, en una tecnología diferente. Luego es claro que el juicio del experto no es demasiado fiable. Además se trata de la voz de una única persona, lo que siempre introduce riesgos.

El siguiente paso fue abordar el problema desde un enfoque más ingenieril, más matemático. De aquí surgieron toda una serie de técnicas basadas en utilizar la matemáticas, como COCOMO y surgieron bastantes herramientas que implementaba este modelo. El problema es que descubrimos que alimentar de datos estas herramientas era demasiado costoso para obtener unos resultados que no era mucho más ajustados que el que se obtenían usando el juicio del experto.

La siguiente aproximación fue los puntos función. La idea es simple, utilizando datos históricos podemos evaluar lo que en nuestra empresa cuesta hacer un formulario o un informe, basándonos en lo que informes o formularios similares costaron anteriormente. Luego, a la hora de estimar un desarrollo, simplemente tendremos que multiplicar ese valor por el número de informes o formularios que tenemos. Pero resulto que aunque el método es simple y sin duda funciona, es muy difícil recopilar una cantidad significativa de datos fiables que soporten subsiguientes estimaciones. Recopilar estos datos es algo que exige tiempo, y en ese tiempo se producen cambios (tecnológicos, humanos u organizativos, por citar algunos) que invalida los datos anteriormente recogidos.

Es evidente que antes de la aparición de las herramientas RAD era mucho más complejo hacer un formulario o un informe, por poner un ejemplo fácilmente entendible.

Que estimar sea un problema difícil, no quiere decir que no sea un problema importante. Los desarrolladores tenemos una continua relación con las estimaciones: damos estimaciones, recibimos estimaciones y sufrimos estimaciones que gente equivocada, comerciales, gerentes, departamentos de marketing, etc, sin suficiente conocimiento del problema, hace por nosotros comprometiéndonos. Muchos problemas y riesgos habituales que aparecen en la gestión de los proyectos tienen que ver con una estimación deficiente. Es un problema que merece mucha de nuestra atención.

Pero no podemos obviar la relación que nuestra industria ha tenido con las estimaciones, la cruda realidad que todos vivimos: nunca se respetan y nunca son suficientemente ajustadas, da igual la técnica que usemos. Por lo tanto es muy importante a la hora de estimar no consumir demasiado tiempo. Al fin y al cabo, la fecha o el precio de proyecto probablemente ya se hayan fijado por motivos ajenos al desarrollo de software, mucho antes de que el equipo de desarrollo haya podido siquiera construir su estimación. Incluso, en muchos casos antes de que exista un equipo de desarrollo. Además las estimaciones se basan en los requisitos y los requisitos cambian constantemente o por lo menos, desde el planteamiento de las metodologías ágiles así lo asumimos.

Otro fenómeno claro que tendemos a olvidar, es que las estimaciones son muchísimo más fiables cuanto más información tenemos sobre las cuestiones que estamos estimando. En proyectos de desarrollo de software, generalmente esto es equivalente a decir que solo podemos tener estimaciones fiable sobre las parte del desarrollo que vamos a abordar en un futuro cercano. Con esto y con el principio de economía en mente (estimar tiene un coste alto, para el que buscamos una rentabilidad), las metodologías ágiles proponen solo estimar el futuro cercano y no poner demasiado esfuerzo en esa estimación. La idea subyacente es que realizar una estimación aporta mucho, pero que refinar mucho una estimación o utilizar métodos muy formales, generalmente costosos en cuanto a tiempo dedicado, no aporta tanto y sobre todo, no es económico desde el punto de vista de la relación entre esfuerzo y resultados. Resumiendo, estimar si, pero lo justo y solo en referencia al futuro cercano.

La siguiente pregunta es evidente, si estimar es inevitable y los métodos formales tradicionales exigen un esfuerzo que no tiene suficiente recompensa, ¿qué nos queda?. Una aproximación a la estimación que está ganando partidarios día a día es Wideband Delphi un proceso de estimación muy ligero y que obtiene unos resultados muy similares a procesos de estimación más pesados o complejos. El proceso es simple y no exige mucha preparación o formación previa.


  • Se reúne unas cuantas personas (de dos a cinco). Idealmente se contará con personas que haya trabajado en aplicaciones similares y personas que no, es interesante contar con diferentes perspectivas.
  • Cada persona contará con una descripción general de la cuestión a estimar y quien mejor la conozca expondrá de viva voz sus conocimientos sobre la misma.
  • Cada persona presente en la reunión de estimación realizará y anotará su estimación sin colaborar con los demás. No se mostrará aun esta estimación al resto de participantes.
  • Un facilitador revela los cálculos de manera anónima y seguidamente, tiene lugar un debate sobre las suposiciones en que se basan los cálculos. Quien lo desee puede revelar cual fue su estimación.
  • El paso 3 se repite hasta que los cálculos converjan. Lo que se pretende es que cada persona aprende de los demás participantes, actualiza sus estimaciones y proporcione una nueva.

Existen varias variaciones sobre está técnica, por ejemplo hacer publicas las estimaciones de manera simultanea y que, para agilizar, solo los propietarios de estimaciones extremas, la más pesimista y la más optimista, debatan el por qué de sus estimaciones. Desde hace algún tiempo utilizo este método de estimación en un proyecto gestionado con Scrum para estimar y planificar cada uno de los Sprints, y la verdad es que tras el necesario proceso inicial de ajuste, puedo decir que esta funcionando excelentemente.

10 comentarios en “El difícil problema de la estimación”

  1. Excelente post Rodrigo.

    Yo, en este tema, me conformaría con que mis estimaciones se escuchasen y se tubiesen algo en cuente. A mi lo plazos me vienen impuestos. Se que es una aberración… pero no logro convencer a mi jefe de lo dañino que es.

  2. Hola Rodrigo!,

    me acaban de aprobar un proyecto para una empresa de venta fármacos, y entre las cosas que más me costó es estimar justamente el tiempo de desarrollo del sistema, y más aún que es la primera vez que desarrollaré un sistema de este tipo de negocio. voy a revisar Wideband Delphi, me parece muy interesante, porque se puede todos los involucrados pueden ir retroalimentando sus estimaciones para finalmente dar tener un estimación bastante aceptable y confiable.

    Saludos, y felicitaciones por este excelente post!

    Percy Reyes,

  3. Como es habitual, muy buena entrada Rodrigo.

    Julián, hay muchas empresas que funcionan así. La imposición de tiempos es un error conceptual grave que tiene una consecuencia más grave aún, la desmotivación. He trabajado en empresas que tienen esa forma de trabajar o que incluso el comercial que en la mayoría de ocasiones no tiene ni idea de informática, es decir, en nuestro argot, un vende motos, es el que impone los tiempos, y eso suele generar descontento generalizado y casi siempre y como decía, desmotivación. Es una lástima, pero poco se puede hacer, y menos si los responsables superiores no escuchan, no tienen en cuenta, o simplemente imponen el es así porque lo digo yo y punto. Aceptar críticas (que suelen ser constructivas) no es una tarea fácil y muchas personas que adolecen de ello, se lo toman como algo personal, así que ánimo y piensa que todo incluso eso, es experiencia, así que saca lo positivo de ella. 😉

    Volviendo a la entrada de Rodrigo, todo lo que comenta él es puro Scrum o tiene una relación directísima con las metodología ágiles. Una de las máximas de Scrum es que las tareas a abordar dentro de un Sprint Backlog sean realistas. Y que sean realistas entran dentro del marco de la estimación. Si una de las tareas es tan larga como para superar el tiempo de un Sprint Backlog (15 días ó 30 días), divídela en varias… 🙂
    Otros tipos de estimaciones lejos de la filosofía general de las metodologías ágiles como las comentadas por Rodrigo, podrían ser tenidas en consideración como estimaciones realistas también, porque no, pero el problema es que no existe una estimación perfecta ni real 100%. Detrás del desarrollo del Software no hay un autómata ni un sistema de cambios de estado controlados. Cada desarrollo de Software es distinto a otro, y aunque siempre tratamos de basar el desarrollo del Software a la experiencia, esto no es suficiente en lo que respecta a la estimación. Cada empresa debe hacer balance de qué tipo de estimación le resulta mejor o peor, pero yo no he conocido la estimación perfecta. Como decía Rodrigo, no existen balas de plata en lo que a estimación se refiere, pero a mí la que comenta Rodrigo es la que más me gusta y la que en los proyectos en los que la he usado, más éxito me ha ofrecido. Cada uno tendrá su propia experiencia como es lógico.

    Una estimación realista de metologías ágiles como la que muy bien ha comentado Rodrigo, y obteniendo pros y contras de cómo se hacen otras estimaciones diferentes (supuestamente realistas también) que yo he vivido (todas ellas, no me ha faltado ni una de las que ha comentado Rodrigo y ha dado, creo yo, en el clavo en todas sus apreciaciones), hace en mi opinión que los tiempos marcados se acerquen a esa realidad y que el proyecto se realice en un clima dónde las tensiones están casi a 0 ó lo más cerca de ese 0.

    Todos los proyectos (TODOS) se inician con una incertidumbre, tensiones y ansiedades que hay que rebajar al máximo, y las estimaciones es quizás y en mi modesta opinión, uno de los factores anímicos más importantes de un proyecto, sobre todo cuando te reúnes con todo el equipo para marcar la orden de trabajo (Sprint Backlog). La imposición de estimaciones es en mi opinión, mala por naturaleza, consensuarlas o explicarlas ayuda y mejora nuestro conocimiento y el de todas las personas que nos rodean, para que todo el mundo las comprenda de una forma más clara, permitiendo además, ser más realistas en la consecución de los objetivos que serán marcados.

    Aquí pongo algo de información adicional al respecto de la entrada de Rogrigo que espero que ayude:

    http://www.ewh.ieee.org/r6/phoenix/compsociety/PDF_Presentations/Software-Estimation-60503a.pdf

    Aquí, encontraréis una hoja Excel de una estimación tipo Wideband Delphi (en portugués) que ayudará a entender aún más (por si no quedó claro) lo que Rodrigo ha comentado:

    http://www.cin.ufpe.br/~emb/PGP/segundaTarefa/wideband-delphi.xls

  4. Julian, yo sufro el problema contrario: me encuentro con programadores que, sistemáticamente, se niegan a dar estimaciones. Según ellos, una determinada tarea podría durar un día o una semana porque “nunca se sabe si van a presentarse problemas”, por lo que al final soy yo el que impongo las estimaciones. Si las estimaciones son correctas, estupendo, pero si no entonces “la culpa es mía y no suya”. Una postura comoda.

  5. en mi opinión estimar es intentar predecir el futuro.

    Está claro que todos intentamos utilizar algún tipo de método o lógica que nos prevenga de equivocarnos, pero al final todo se reduce a una predicción más o menos guiada.

    Bueno y dicho esto, en mi opinión no hay metodos mejores o peores, todo dependerá de distintos factores que irán cambiando según el proyecto que tengamos entre manos, como por ejemplo:

    – Los conocimientos que tengamos sobre el tipo de tecnologia a usar.
    – Experiencia en ese tipo de proyectos.
    – Expertos disponibles.
    – Información disponible.

    Por ejemplo el Delphi es bueno cuando se tiene un detalle muy a bajo nivel de las tareas a realizar, de lo contario las distintas opiniones pueden variar mucho en función de las distintas asunciones que cada experto haga a la hora de evaluar esfuerzos.

    En fin, mis recomendaciones a la hora de estimar es que se haga siempre por un equipo experto en estimaciones que conozca muy bien al menos 3 metodos distintos de estimación y sepa cual aplicar según que casos, y al menos siempre utilice dos de ellos.

    Que se recurra a BBDD de esfuerzos donde poder comparar los resultados o al menos sacar información de ellas por analogia cuando tenemos muy poca información del proyecto entre manos.

    Y si en vuestra empresa no teneis una BBDD de estimaciones en condiciones, os recomiendo que veais esta página web:

    http://www.isbsg.org

    Esta organización se dedica a recoger información de miles de proyectos realizados en todo el mundo con diferentes tecnologias, y agruparlos por distintos metodos de estimación y otras variables, con ella podeis obtener estimaciones mas o menos fiables aunque solo sepais el numero de ventanas que tendrá tu aplicación y el lenguaje de programación.

    Por otro lado, los Function Points así como otras técnicas de estimación de Software fueron inventadas por IBM, y en su Web precisamente he encontrado un gran articulo sobre las diferentes técnicas de estimación, os aconsejo revisarlo, no nos convertirá en Rapell o en la bruja Lola pero nos quitará dolores de cabeza cuando las planificaciones y los costes se mantengan bajo control

    http://www.ibm.com/developerworks/rational/library/jun07/temnenco/

    Un saludo y perdonarme el rollo, Rodrigo se explica mucho mejor.

    Por cierto Rodri otro buen Post.

  6. Hola Jmonts7!!!

    Gracias por compartir tu opinión!

    Excelentes los links que nos has aportado, son muy interesantes.

    Solo hay una cosa en la que discrepo contigo, no creo que sea necesario un gran nivel de detalle para que Wideban Delphi, es precisamente cuando no se tienen muchos detalles cuando mejor funciona esta técnica de estimación.

    Un saludo!!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *