Estimación y planificación detallada

Un error habitual en gestión de proyectos es creer que la mejor manera de estimar el coste o la duración de un proyecto es realizar una división del trabajo en tareas. Veía este error hace pocos días entre los comentarios al post titulado Tengo un plan: ser ágil. Es curioso cómo en varios comentarios se ligaba estimación con planificación detallada. El argumento era más o menos el siguiente: puesto que las metodologías ágiles no realizan una estimación detallada más que en el momento de abordar una iteración o sprint ¿cómo podemos estimar?.


Lo primero, me gustaría explicar porque las metodologías ágiles no tratan de realizar una planificación detallada: es una simple cuestión de economía. Realizar una planificación detallada es un esfuerzo grande. Además todos sabemos los volátiles que tienden a ser las planificaciones. Cuando más detalladas más volátiles. Según una aproximación ágil, el coste de realizar una planificación detallada no merece la pena.


Lo segundo, no realizar una planificación detallada, no significa no realizar una planificación en absoluto. Es posible realizar una planificación suficiente para guiar el proyecto a medio y largo plazo sin necesidad de de que esta sea demasiado detallada. Los riesgos de una planificación excesiva siempre amenazan a los proyectos y en ocasiones son más peligrosos que los de una planificación escasa. Incluso existe un patrón que describe esta situación ‘Death by planning’, su nombre lo dice todo.


Bueno una vez dejado claro que las metodologías ágiles no propugnan no hacer planificación sino hacer la que es imprescindible, volvamos al tema que nos ocupa. ¿es necesaria una planificación detallada para poder estimar?. No, y lo voy a ‘demostrar’ con un pequeño ejercicio de estimación que os pido realicéis, y me hagáis llegar vuestros resultados en los comentarios. No pongaís por favor cual debería ser el resultado obtimo, cualquiera lo puede averiguar. Solo contadme cual fue vuestra desviación en cada una de las estimaciones del ejercicio.


El ejercicio es el siguiente: Debéis estimar la distancia entre Bilbao y Ámsterdam. No vale usar MapPoint ¿eh?. Seguro que estáis pensado que es algo difícil, que no tenéis información suficiente, pero eso es precisamente lo que ocurre la mayor de las veces en un proyecto de software. Debéis estimar con poca información o lo que es peor en base a información incompleta o sesgada.
Bueno venga… ¿tenéis ya una estimación?. Apuntadla.


Ahora os propongo hacer el equivalente a detallar más el plan de proyecto y estimar en base a la descomposición del viaje en etapas, actuación en cierto modo equivalente a estimar un proyecto en base a la subdivisión en tareas. Os diré por qué ciudades tendréis que pasar, así podréis estimar tramos más pequeños, y en teoría vuestra estimación debería ser más exacta. ¿Lo será?.


El itinerario pasa por: Bilbao – Bayona – Burdeos – Orleans – Paris – Amberes – Amsterdam
Debéis estimar estos tramos y sumar el resultado.


Ahora podéis comparar vuestras dos estimaciones con el valor real. ¿A mejorado en algo el tener un itinerario más detallado vuestra estimación? Seguro que no.


Podriamos refinar más aun el itinerario, e incluir más tramos, pero ¿creeís que esto mejoraría la estimación?.


La conclusión de este pequeño ejercicio: Una planificación detallada no mejora en nada nuestra capacidad de estimar.


Entonces ¿qué podemos hacer para mejorar nuestras estimaciones?… en el próximo post os lo cuento ;).

16 comentarios sobre “Estimación y planificación detallada”

  1. Un error habitual en gestión de proyectos es creer que la mejor manera de estimar el coste o la duración de un proyecto es realizar una división del trabajo en tareas. Veía este error hace pocos días entre los comentarios al post titulado Tengo un plan:

  2. ummmm esperaré a tu próximo post porque no lo veo claro.

    A hacer una planificación detallada no le veo sentido, pero dividir un problema en N problemas puede ayudar, sin llegar al detalle que comentas. Todo tiene término medio..

    porque ejemplo, en el caso que comentas es probable que no haya ido nunca de Bilbao a Amsterdan, pero sí que haya hecho algunos tramos en otros viajes; igual he ido alguna vez a Burdeos o a Bayona o he hecho Amberes-Amsterdam o lo me lo le léido en algún lado.

    No comento nada más y espero a tu próximo post-

    Un saludo!!

  3. Aupa Ibón!!!

    Creo que lo que Rodrigo quiere hacer patente es que conocer en detalle la duración de las subtareas no va a mejorar la estimación. Todos sabemos que ne desarrollo de software, incluso la pequeñas tareas sufren grandes cambios, por ello estimar pequeñas tareas no mejora la estimación.

    Además ya dice Rodrigo que hay que tener en cuenta el coste de realizar esa subdivisión, que claro esta no es pequeño.

    Yo entiendo el post de Rodrigo en el sentido de que hay que buscar información sobre el software a estimar, pero no demasiada porque llega un punto que el coste no compensa. Y hacer la división de todo un proyecto en tareas es algo que puede ser excesivamente costoso sin que mejore demasiado la estimación.

  4. Además, te puede pasar lo siguiente. Al dividir tu proyecto en fases y/o tareas, es posible que a mitad del proyecto tengas que modificar totalmente la planificación de una de las tareas por lo que toda la estimación se va al cuerno.
    En el ejemplo de Bilbao a Amsterdam. Imaginate que cuando estás camino de Burdeos te das cuenta de que pasar por París no es viable (huelga de transportes?)

  5. Oscar A.G. dijo: «Además, te puede pasar lo siguiente. Al dividir tu proyecto en fases y/o tareas, es posible que a mitad del proyecto tengas que modificar totalmente la planificación de una de las tareas por lo que toda la estimación se va al cuerno.

    En el ejemplo de Bilbao a Amsterdam. Imaginate que cuando estás camino de Burdeos te das cuenta de que pasar por París no es viable (huelga de transportes?)»

    Precisamente ahí creo que está el meollo. El tratamiento de la incertidumbre frente a los requisitos cambiantes, y cómo afecta a las estimaciones y las planificaciones. Me explico. En un ejemplo como el que ha puesto Rodrigo, a menos que haya alguna catástrofe, sí que podemos realizar cierta estimación. No necesariamente en el tiempo (quién sabe qué atascos habrá), pero sí en los Km.

    El coste de analizar, diseñar y estimar es alto. El de intentar hacerlo de forma apriorística con toda la solución es grande. Con la gran desventaja de que si luego te cambian la especificación, se te hunde el chiringuito.

    Por este motivo con las metodologías ágiles se estima iteración a iteración. Porque a muy corto plazo es posible analizar, diseñar y estimar de forma razonable sin que te cambien los requisitos.

  6. Excelente ejemplo !!!

    Sin embargo, TU planificacion detallada (Bilbao – Bayona – Burdeos – Orleans – Paris – Amberes – Amsterdam) a vos te parece que no te ayudará a estimar correctamente; pero a MI sí. No me ayudará a estimar, pero si me ayuda porque sirve de la lista de lugares q tengo pendientes de conocer: {Bilbao, Bayona, Burdeos, Orleans, Amberes}.

    Por eso puedo suponer lo siguiente: si existe información que piensas que no es útil, tal vez a alguien le sirva 😉
    Esto es para q no empecemos a desestimar planificaciones existentes y comencemos a hacer todo de nuevo, creo que lo mas importante es saber el nivel de detalle con el que necesitamos trabajar.

    Saludos

  7. Como forofo de geek, y admirador de Rodrigo, me lanzo ha dar mi opinión.

    La descomposición en tareas menores se realiza para llegar a una unidad de trabajo conocida y estimable, la cual nos permita tener una primera cifra y saber de lo que estamos hablando. Evidentemente después de utilizar esta metodología y hay aplicarle unos factores correctivos que dependen de muchas variables (semejantes a los que se utilizan en la estimación por casos de uso: tecnicos, ambientales, etc). Y al final establecer una estimación basada en métricas y experiencia al 50%.

    En cambio en el ejemplo (que aunque es muy bueno no es aplicable) descomponemos la tarea en unidades que seguimos desconociendo por lo que nunca tenemos una referencia real y estimable.

    Bueno esta es mi opinion. Muchas gracias por GEEKS a todos lo que lo componéis.

  8. Como forofo de geek, y admirador de Rodrigo, me lanzo ha dar mi opinión.

    La descomposición en tareas menores se realiza para llegar a una unidad de trabajo conocida y estimable, la cual nos permita tener una primera cifra y saber de lo que estamos hablando. Evidentemente después de utilizar esta metodología y hay aplicarle unos factores correctivos que dependen de muchas variables (semejantes a los que se utilizan en la estimación por casos de uso: tecnicos, ambientales, etc). Y al final establecer una estimación basada en métricas y experiencia al 50%.

    En cambio en el ejemplo (que aunque es muy bueno no es aplicable) descomponemos la tarea en unidades que seguimos desconociendo por lo que nunca tenemos una referencia real y estimable.

    Bueno esta es mi opinion. Muchas gracias por GEEKS a todos lo que lo componéis.

  9. Javier,
    de eso trata este ejemplo creo yo.
    El desmenuzar el proyecto en tareas y estas en subtareas hasta encontrar unidades «conocidas» y «estimables» es donde te puedes llegar a perder.
    A medida que vas profundizando en las subtareas estás aumentando el número de variables estimadas.
    En el ejemplo propuesto por Rodrigo se ve muy claro: Sólo tengo que estimar la distancia entre 2 puntos.
    Al principio puede parecer dificil porque no tengo suficiente información. Así que lo divido en subtareas más «asequibles». En el ejemplo son pasar por varias ciudades que están a una distancia menor. Ahora tengo que estimar la distancia de Bilbao a Bayona, de Bayona a Burdeos y así sucesivamente. De esta manera creo que el número de variables a estimar crece. Paso de estimar una distancia a estimar 6 distancias. Es posible que los fallos de estimación en cada uno de los tramos sean menores, pero… ¿qué me dices de la suma de todos los fallos de estimación de cada una de las etapas?
    Sinceramente, es posible incluso que sean hasta peores.

  10. Aproximacion vasta:
    Minimo (bilbao-bayona) 100 km (distancia de la capital a la frontera)
    Maximo frontera-frontera 2000km (minimo para un pais en condiciones)

    5 pasos a 100 km = 500 Km

    La distancia es 2000km + 500 km (me pillo los dedos ? )

  11. Rodrigo, me sumo tarde a la discusión.
    Existe un aspecto para considerar sobre el uso de la descomposición para la estimación que puede proveer algunos beneficios: la ley de los grandes números.
    Steve McConnell habla sobre la ley de los grandes números y su influencia en las estimaciones en su último libro: «Software Estimation». Dice:
    «…si tú creas una única gran estimación, la tendencia de error de esta se encontrará completamente en el lado superior o inferior. Pero si tú creas varias estimaciones más pequeñas, algunos de los errores estarán en el lado superior, y algunos estarán en el lado inferior. Los errores tenderán a cancelarse entre ellos hasta cierto punto.»
    Tambien agrega referencias a estudios que proveen evidencias que ayudan a confirman la teoría.

  12. Esto no deja de ser un ejemplo seleccionado para demostrar algo sin sentido. El ir de Bilbao a Amsterdam, no tiene nada que ver con el diseño de software. Cierto que es lo que pone para saber distancias, pero no lo es para estimar una tarea definida. Si me dicen que tengo que limpiar un edificio entero pues no se lo que me puede costar, pero si me dicen las habitaciones, baños, etc. que tiene y los pisos y demás, si que podré estimar mejor un tiempo. Otro ejemplo seleccionado para demostar lo contrario. Tampoco esto tiene nada que ver con sw. Para mi el modelo de divide y vencerás sigue vigente a pesar del trascurso del tiempo.
    Seguid el link:(no mas comentarios)
    http://spanish.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html

  13. Carlos… en esto no hay verdades absolutas… yo también puedo proponer otros links… aunque conste que son un grandísimo admirador de Joel. Pero sigo creyendo que no es necesario dividir en tareas detalladas para hacer buenas estimaciones.

    Es más, el equipo del que formo parte, clava sus estimaciones (después de un lógico proceso sde ajusta) sin necesidad alguna de hacer una división en tareas, solo a partir de escenarios. Creo que es algo que tiene mucho sentido, pues lo vivo día a día. Sprint planning meeting tras sprint planning meeting.

    Aquí va mi link (por poner uno):

    http://msdn.microsoft.com/msdnmag/issues/07/01/EndBracket/Default.aspx?loc=es

    Generalmente lo último que alguien será capaz de decire es cuantas ‘habitaciones, baños y pasillos’ tendrá tu software, porque nadie lo sabe hasta que el software está terminado. Si pudiesemos saber exactamente como será nuestro software a priori, todo sería mucho más facil. Pero eso es una falacia, es imposible capturar los requisitos a priori, luego es imposible hacer una división en tareas. Construir software no es construir edificios, no es ni remotamente parecido.

    Gracias por expresar tu opinión!!!

Deja un comentario

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