[PM] Estimaciones Agiles, no Extremas

Primero lo primero

Hace poco comentaba en un post de Rodrigo Corral sobre algunas de las desventajas de un método de estimación que el mencionaba como método ágil y rápido: el Plannig Poker. Luego, Rodrigo me responde con un post en el que intenta rebatir cada una de mis afirmaciones. Una excelente noticia es que al menos el capítulo 6 del libro Agile Estimating and Planning (by Mike Cohn) que trata, entre otras cosas, sobre  Plannig Poker está disponible para leerlos en pdf desde acá

  • Lo primero que debo decir es que la utilización de Planning Poker con Wideband Delphi es como comer pan con pan. No se trata de técnicas complementarias. Debo recurrir para esto a la misma bibliografía que en su momento me recomendó Rodrigo para explicarlo, Cohn dice:

    “The three most common techniques for estimating are
    ◆ Expert opinion
    ◆ Analogy
    ◆ Disaggregation
    Each of these techniques may be used on its own, but the techniques should be combined for best results.”

    En otras palabras, usar dos métodos de analogía, o dos de opinión, o dos de descomposición es simplemente comer pan con pan que, según el dicho que repetía mi abuela, es comida de tontos. Yo recomiendo estidiar Wideband Delphi y luego leer el libro Agile Estimating and Planning (by Mike Cohn) para entender de que hablo.

  • Lo segundo, esta técnica requiere de la participación de todos aunque Rodrigo dice en su respuesta que no necesariamente es así. Nuevamente Cohn dice: “Participants in planning poker include all of the developers on the team. Remember that developers refers to all programmers, testers, database engineers, analysts, user interaction designers, and so on. On an agile project, this will typically not exceed ten people. If it does, it is usually best to split into two teams.
    Each team can then estimate independently, which will keep the size down.

    Para quienes no entiendan absolutamente nada de inglés, Cohn dice que sí es necesaria la participación de todos.
  • Tercero, es un método que consume más tiempo que otros métodos. Para este punto recurro a McConnel quien dice: “Because Wideband Delphi requires a meeting, it burns a lot of staff time, making it an expensive way to estimate. It is not appropriate for detailed task estimates.“, esto mismo aplica a planning Poker. Si solo porque dice Wideband Delphi y no Planning Poker alguien no cree que esto sea válido, puede hacer el siguiente experimento: trate de ponerse de acuerdo con un grupo de 6 o 7 desarrolladores sobre una estimación y luego utilice alguna tool como construx para hacer el mismo trabajo; luego calcule cuanto tiempo perdió con uno y otro método. No se trata de fe, se trata de realidad.
  • Cuarto, yo digo que hace falta un moderador y Rodrigo piensa que no es necesario. De nuevo (nótese que no recurro nunca ni al ACM ni a la IEEE ni al SEI, solo a fuentes agradables) Cohn dice: “For each user story or theme to be estimated, a moderator reads the description. The moderator is usually the product owner or an analyst.
    Es posible darle diez mil vueltas a la existencia de alguien con el rol moderador pero quien sufre los método de estimación grupales sabe que este rol es imprescindible. Esto también lo deja ver McConnel cuando dice: “The coordinator should take care to prevent people with dominant personalities from unduly influencing the estimate.” solo que le llama coordinador.
  • Quinto y último gracias a Dios, yo comenté en el post de Rodrigo que los métodos de juicio arrojan mejores resultados cuando existen verdaderos expertos en el equipo. Rodrigo lo niega diciendo que esto no es cierto. Más allá de que este punto es indefendible, voy a citar a McConnel: “How many experts are enough? Studies in other fields have found that the use of 3 to 5 experts with different backgrounds seems to be sufficient (Libby and Blashfield 1978, Jørgensen 2002).

    In addition, it’s useful to find experts with different backgrounds, different roles, or who use different techniques (Armstrong 2001, Jørgensen 2002).

Sobre estimaciones de “Expertos en la materia”

Voy a continuar esta entrada explicando cuales son las desventajas documentadas de los métodos de estimación grupales o “Expert Judgment in Groups” intentado, siempre que sea posible, recurrir a fuentes reconocidas y autorizadas que promueven técnicas de estimación ágiles.

Algo que comentaba era que, como variante del método wideband delphi, ese método de estimación compartía todas las desventajas propias de la familia de métodos conocida como “Expertos en la materia” (para más detalle de estas ventajas y desventajas vea: Métodos de Estimación – Resumen ) y que una de las desventajas más importante es que, me cito: “Arroja mejores resultados mientras más  expertos “verdaderos” sean sus participantes. Si no son expertos…”. Esto ahora que lo leo no parece una gran desventaja pero realmente lo es y lo voy a explicar.

Todos los métodos de la familia “Expertos en la materia” comparten una característica común no muy deseable: la subestimación.

Steve McConnell en su libro Software Estimation: Demystifying the Black Art menciona los trabajos de investigación de Michiel van Genuchten, que afirma que las estimaciones realizadas por los desarrolladores tienen un factor de optimismo de entre el 20% y el 30%, y de Boehm, Barry W que afirma que se encontró un factor de fantasía de 1.33 entre 100 proyectos estudiados. Esto quiere decir que los desarrolladores creen (escribo creen pero debería decir creemos)  que pueden hacer las cosas un 30% más rápido de lo que realmente pueden. McConnell cita también al ex-Vice Presidente de  Microsoft Office development Chris Peters quien observó que  “You never have to fear that estimates created by developers will be too pessimistic, because developers will always generate a too-optimistic schedule”. Por todo esto, McConnell termina dandonos un Tip (el 20): Don’t reduce developer estimates—they’re probably too optimistic already.

El problema de subestimar un proyecto

Pero, ¿cual es el problema con subestimar un proyecto?. El problema es que los estudios demuestran (por favor les recomiendo fuertemente leer el libro) que un buen líder de proyectos puede ingeniárselas para llevar a buen puerto (costo y schedule) un proyecto con una subestimación de hasta un 20% pero no más que eso. Pero como si esto fuera poco, las consecuencias de subestimar no son las mismas que las de sobreestimar un proyecto. Para esto voy a necesitar este gráfico:

image

Como puede verse, mientras que las consecuencias en los costos de sobreestimar son lineales (se cumple la ley de Parkinson), las consecuencias de subestimar los proyectos son mucho más graves. Por lo tanto, si bien parece totalmente anti-intuitivo (y según la idiosincrasia de tu empresa puede llegar a ser hasta perjudicial para tu salud), ante la duda, es mejor sobreestimar que subestimar una tarea.

El lector despierto entenderá que no estoy diciendo que haya que sobreestimar los proyectos sistemáticamente. Solo es preferible sobreestimar que subestimar.

Algunos problemas humanos

Siguiendo con el tema que nos toca, hay que notar tres cosas:

  1. Los desarrolladores no creen equivocarse por mucho en sus estimaciones. Esto es, por lógica, algo obvio por cuanto nadie puede no creer en lo que cree. El 30% de subestimación al que me refiero es producto de la convergencia de las revisiones en grupos, el error individual de los desarrolladores de manera individual ronda el 55%.
  2. Los desarrolladores pierden la dimensión del problema cuando estos crecen en tamaño. Así, no tendrán la misma precisión para estimar la intranet de una agencia de seguros que al estimar el sistema de control de tráfico aéreo de la UE. Esto es producto de muchos factores pero especialmente de la anti economía de escala del software y la ley de Metcalfe.
  3. El juicio de los expertos es más valioso que el de los no-expertos. Esto es algo peligroso por cuanto puede llavar a autoengaños. Experto es aquel que tienen basta experiencia en la tecnología a utilizar, que conoce muy bien el negocio y que cuenta con mucha experiencia en sistemas en algún aspecto similares al que se pretende desarrollar. No se es experto solo por contar con una certificación .Net y por programar desde los 12 años. Se es experto según el proyecto, en unos se es experto mientras que en otros no.

Una pequeña pruebita

Pensando en hacer esto un poco más curioso de leer, hice este problema:
Mariano es un excelente desarrollador web al que se le ha pedido que estime un proyecto de 21 tareas y vos (quien lee) sos su líder de proyectos. Mariano ha estimado el tamaño de las tareas y a partir de ellas calculó, basandose en los datos históricos de productividad que tiene en su cabeza, el esfuerzo que le requerirían esas tareas. El proyecto comenzó y Mariano quedó como único desarrollador por lo que las 21 tareas se desarrollan de manera secuencial.

Luego de 21 dias (31/03), Mariano tiene 4 dias de retaso pero esto no parece preocupate (recordá que sos el lider de proyecto) así que no tomas ninguna medida correctiva. Pero después de unos cuantos dias (24/5) Mariano acumula ya un mes de atraso (ya le pusiste mala cara y aún así no avanza). Es que Mariano aculuma pequeñas desviaciones fruto de haber sobreestimado su capacidad para realizar las tareas que se le han asignado.

No queda otra, el cliente sabe que el proyecto está atrasado y como buen cristiano  “nos perdona”. Eso sí, quiere saber cuando va a estar listo y no aceptará otro “problemita”.

La pregunta es: según los datos que ves en el excel ¿cuando estará listo el software? ¿Que le decis al cliente?
estimation_problem

Opciones:

  1. Estará listo para el día en que te comprometiste!.
  2. Tendrá un mes de atraso por lo que se entregará el 23/11/2008.
  3. De seguir con la productividad actual el proyecto se entregaría con algo más de dos meses de atraso.
  4. El proyecto se finalizará con suficiente seguridad con un atraso máximo de 3 meses.
  5. El proyecto no se entregará nunca pero nos aseguraremos de que Mariano no vuelva a trabajar en una empresa de software.

La respuesta la voy a poner en un comentario.

Como mejorar las estimaciones

Para contrarestar estas falencias es necesario la utilización de otros métodos que aporten otra perspectiva a la estimación. Lo ideal sería contar con la experiencia (los números) del esfuerzo que se requirió para desarrollar el sistema de control de tráfico aereo de la América, o no? (100 a 1 a que alguien piensa que no). Contar con cualquier información para comparar el proyecto o para dimensionarlos o para usarlo como parámetro de entrada en una tool de estimación será mejor que no tener nada.

¿Que tanto pueden aproximarse las estimaciones grupales como wideband delphi? Los números que muestran los experimentos realizados por McConnell dicen que mejoran las estimaciones en un 40%. De seguro que es un muy buen número ya que en proyectos con muchos factores desconocidos puede reducir el error desde 290% a 170%. No estoy siendo irónico, esta diferencia traducida en costos es enorme.

Recomendaciones

No obstante, la técnica que recomiendo para lograr un conocimiento suficiente de las probabilidades de cumplir con una estimación es la que describo en mi entrada sobre Estimaciones y Scheduling Avanzado. En ese post solo le doy mi visión a las recomendaciones realizadas por Steve McConnell en su libro de estimar utilizando rangos. Otros buenos complementos para iniciarse son Software Estimates – Managing Expectations via Ranges y Agile Estimating – Estimation Approaches de Mike Griffith en los que se explican de manera más sencilla los conceptos que se utilizan en mi post de estimaciones.

(Continuará…)

Lucas Ontivero

Sin categoría

8 thoughts on “[PM] Estimaciones Agiles, no Extremas

  1. Lucas, lei tu post!!! 😛 y tambien leí el de Rodrigo.

    Estoy muy de acuerdo con vos con respecto al juicio de expertos. No hay peor estimacion que la de un junior, y lo digo por experiencia. Cuando yo era junior mis estimaciones eran pateticas en cambio ahora… bueno, son “menos peores” pero al menos se diferencian mucho de “pateticas”.
    Si yo usara planning poker en algun proyecto donde el 50% (o más) del plantel fuesen juniors creo que buscaria huir de ese proyecto excepto que mi cargo sea technical leader lo cual sólo haria que a dicha huida la piense 2 veces, nada más.

    (Junior = desarrollador nuevo que no tiene experiencias en sistemas ni conoce los distintos modelos de negocios, aunque tenga 38 certificaciones y 23 estrellas en el programa DCE que para colmo, se puede rendir usando google)

    De hecho si yo fuese project leader no permitiría que un junior intente estimar nada. Seguro que ese junior o mi abuela, estimarán cifras similares. ¿Porqué me puede interesar las estimaciones de alguien que no sabe? ¿Acaso me llaman a mí para estimar en cuanto puedo construir un puente sólo para promediar con los que sí saben cuanto puede llevar hacer dicho puente? NO. (y debe ser por eso que los puentes no se caen!)
    Pero bueno, todo hay que decirlo, por algo no soy project leader, no? :). Puedo tranquilamente estar equivocado, pero escribo desde mi experiencia.

    Con respecto a tu pruebita.. mi respuesta -aceptando tu consigna- es la “C” simplemente por ser la más evidente y lógica.
    Fuera de la consigna creo que cualquier project leader que trabaje en una empresa con más de 10 personas tiene otras opciones por ejemplo meter a otro desarrollador en el proyecto y terminar en el tiempo estipulado o bien unos días más pero no tanto como 2 meses.
    Todo depende tambien del proyecto, a veces una empresa “resigna” un poco de la ganancia para satisfacer a un cliente. (y conseguir otro futuro proyecto)
    A veces incluso hay matices, no puedo olvidarme de una persona llamada Oriol Q. que un día me dijo “tío, ese cliente nunca nos dará otro proyecto a nosotros por lo que haz tu trabajo lo mas cutre posible y nos saquemos ese marron de encima”. En este caso se resignaba “calidad” e incluso al mismo cliente pero sin perder dinero.

    Pero esa es otra historia. Por cierto, muy buen post. Se nota que hay mucho tiempo detrás del mismo buscando información que sustenta lo escrito y esto no es muy común que digamos en post no-técnicos.

    Saludos!

  2. Pongo aquí lo mismo que puse en los comentarios a mi post.

    Lucas ya leí tu respuesta. Uff… habría tanto que discutir…

    Sinceramente que solo estimen los expertos es aberrante, ya explique el porqué. Si tu eres un experto tu estimación no vale si la implementación la va a realizar finalmente alguien menos experto.

    Efectivamente WD y PP consumen tiempo, pero no solo dan una estimación sino que sirven para clarificar los requisitos. De todos modos, Cohn lo dice claro, no son técnicas para usar con tareas sino con requisitos. En Scrum en 4 horas estimas el trabajo de 8 personas de un mes. No me parece que consuma mucho tiempo…

    Por último todas las citas que usas para revatir mis argumentos son del siglo pasado, muchas cosas se están moviendo en la ingeniería del software, aunque mucha gente no se está enterando.

    Efectivamente el optimismo inherente al desarrollador hace que sea optimista. Pero es optimista en lo que se refiere al tiempo, no tanto en lo que refiere a la magnitud. Por eso en las metodologías ágiles primero estimamos magnitud y luego tiempo de desarrollo, de manera separada.

    En este post insistes en los argumentos que yo rebatí pero no veo para nada nuevos arguementos a parte de un motón de citas de expertos en gestión de proyectos de la ‘vieja escuela’. Yo también bebí en las aguas del gran Steve McConnell pero sinceramente su libros se publicaron hace una eternidad…

    Leyendo tu post queda claro que no conoces a fondo los fundamentos que guian las metodologías ágiles y la estimación ágil, así que es muy dificil que comprendas lo que digo. Nunca le darás importancia a cosas que son vitales para mí, como por ejemplo que todo el mundo sienta que tuvo voz en la estimación, que todos sientan las estimaciones como suyas…

    De todos modos creo que todo lo que podríamos decir está dicho ya, así que por mí parte el debate está cerrado…

    Un saludo!

  3. Ya estoy cansado. Ni usando los autores que me recomiendas reconoces que tus errores. La postura de negar lo aprendido hasta ahora es ilógica. Habrá que desechar todo entonces y cree solo en tu palabra porque solo te citas a ti mismo como fuente del saber.
    No hablé de scrum ni en una sola oportunidad. Eso de intentar a toda costa acusarme de “ingenieril” es una chicana similar a acusarme de hereje en el medioevo o de comunista durante la guerra fria. No sirve. Yo siempre he planteado mi postura muy pero muy clara: los extremos están equivocados y vos como extremista no colaboras al conocimiento de la comunidad en lo más mínimo.
    Este comentario que me haces parece estar dirijido a una horda de ignornates, no son los ágiles los que estiman tamaño y luego esfuerzo, simplemente así se hace.
    Tampoco cito fuentes antiguas, Agile Estimating and Planning (by Mike Cohn) es bastante nuevo y me lo recomendaste vos mismo.
    Sinceramente queda claro que tu postura o es demagógica o es de una profunda ingorancia que le hace muy pero muy mal a la profesión.

    Yo también terminé esta discusión.

    Saludos.

  4. /* Posteado tb en el blog de Rodrigo */

    Los post de Lucas son abrumadores. Llenos de datos, referencias y citas…El enfoque de estimación que comenta y defiende response a una visión tradicional del mundo de software mientras Rodrigo defiente una visión más moderna de estimación, basada en metodologías y equipos ágiles.

    Me consta que Rodrigo conoce las dos pero no conozco si Lucas conoce las metodologías ágiles y tiene experiencia en ella. Si no es así, sin echar mas leña al fuego, deberías conocerlas para poder añadir mayor calidad a tus post y poder opinar sobre ambos métodos.

    En algún punto de la discusión es verdad que se ha perdido el norte y ambos han podido caer en los extremos. Lucas, tu ultima respuesta tampoco es muy adecuada y si criticas a Rodrigo por la forma de contestar también deberías criticarte a tí mismo.

    Yo os hablaré desde mi experiencia personal, experiencia que he tenido en ambos enfoques, el tradicional y el ágil.

    Mis mejores experiencias son trabajando con metodologías ágiles ya que con éstas he obtenido los mejores resultados.

    Las metodologías tradicionales suelen quedar muy bien en los libros y para vendérselo a los gerentes o responsables de desarrollo, pero son tb las que durante años han fracasado por no tener en cuenta cosas básicas como el equipo, la motivación o la persona como parte clave del proceso de desarrollo. A nivel teórico prácticamente cualquier alternativa se puede defender porque siempre podrás dar datos y citas que puedan ir a tu favor…podríais estar años y años discutiendo.

    Debo decir, que creo fundamental que todos los miembros del equipo intervengan en las estimaciones.Esto lo he realizado en varios equipos de desarrollo y los resultados obtenidos son muy buenos. Y sí, gente con menos experiencia también participa, se involucra y se siente parte activa del equipo. La motivación es mucho mayor.

    He obtenido mejores resultados estimando en equipos ágiles que estimando yo desde mi mayor experiencia e imponiendo éstas estimaciones.

    No conozco todos los libros que mencionáis, pero está claro que es importante tener en cuenta cuándo se han escrito estos libros y el contexto en el que se escribieron. El mundo del software ha cambiado mucho y han salido muchas cosas desde hace 25 años. Yo tb he leído a Steve McConell y tengo claro alguno de ellos habría que revisarlo y que no todo lo que comenta sigue vigente hoy en día, al menos, en mi opinión.

    En cambio, otro libro como Peopleware puede ser el mismo durante otros 25 años más..¿ por qué? Porque los temas que tratan siguen siendo los mismos hoy en día que hace 25 años…que esto del software va de personas!!! Leyéndolo me veía reflejado en infinidad de situaciones que describían….Muchos de los problemas que se describen en este libro son debidos al enfoque tradicional del desarrollo del software y a olvidar algunos principios básicos.

  5. La respuesta al problema:
    Con los datos que tenemos (son muy pocos) no es posible calcular con exactitud la fecha de finalización. Solo sabemos que Mariano se viene retrasando y que no existe nada que nos haga pensar que el el futuro no seguirá atrasándose. Por lo que descartamos la opción ‘1’. La opción 1 es la más irealista de todas pero es la que muchas veces se persigue. Igualmente la opción ‘2’ es dificil porque no solo no deberían haber más atrasos sino que habría que avanzar más rápido, esta es la opción que más les gusta a los seguidores de Harry Potter. Para asegurarle una fecha al cliente necesitamos saber cuanto es lo máximo que se puede atrasar Mariano, si hacemos una regla de tres simple pensando “si en tres meses se atraso un mes entonces en 6 meses se atrasará 2 meses” estamos jugando a lanzar una moneda y elegir cara o seca. Por qué se atrasaría linealmente? Por qué no podría atrasarse más o tal vez menos?
    La opción más segura es la opción ‘4’ mientras que la ‘5’ es solo una broma.

  6. Saludos Lucas.. Muy Buen Resumen de Estimaciones Agiles, no Extremas.. pues no soy muy experto en este tema.. Mi pregunta es lo siguiente, no se si tiene que ver con la estimación.
    Existe herramientas que permitan llevar registro de Tiempos y de errores de un programador de acuerdo con la propuesta del SEI (software Engineering Institute), yo se que este esto tiene que ver con PSP (Personal Software Process) el cual no se que tiene que ver con la estimación..

    Me gustaria que me explicara un poco de eso. si tienes algun conocimiento sobre ello. y si es posible que me dijiera como cuales herramientas son muy buenas, para proyectos serior..

    Gracias por su atención..

  7. Hola Hector,
    Herramientas existen a montones y cada quien debe evaluar cual es la que le resulta más a medida. Las hay costosísimas y hasta open source, las hay integradas (suites) y productos separados. Por esto y otras cosas más, te recomiendo que pases un tiempito estudiando alternativas. Si tu equipo es pequeño y todavia no llevan adelante tareas de administración te recomiendo que antes de buscar herramientas, se empapen un poco en lo que se refiere a la aministración de proyectos. Luego, el temasde las herramientas es menos importante. Como habrás visto yo planteo los problemas en Excel y no en un ClearCase muy caro y sincermente creo que Excel es una opción a considerar seriamente para la administración de proyectos (podés leer también http://www.joelonsoftware.com/articles/fog0000000245.html)

    Las estimaciones tienen que ver con todo tipo de proyecto, sea de software o no, y esa es la relación que tiene con absolutamente todas las metodologías de trabajo. Basicamente, se empieza estimando.

    Para todo tipo de proyecto, lo más importante no son tanto las herramientas como el uso que se hace de ellas, es decir, de la inteligencia y del conocimiento con el que se las utilicen, por eso es que inicialmente propongo Excel.

    Seguro que no es lo que uno puede esperar oir pero la herramienta no hace la diferencia. El conocimiento sí.

    Saludos.

  8. “ejemplo meter a otro desarrollador en el proyecto y terminar en el tiempo estipulado” Ese es el error , mas comun que cometen algunos jefes de proyectos o gente que cree saber como es en tu caso. Eso de la gente nueva no sabe estimar otro error, ya que la gente nueva tiene otra vision de como abordar un tema y no se cierra a otras posibilidades(puede cometer errores)”carloszanini” con respecto al articulo es bastante , bueno conocer herramientas que permitan facilitar las labores de gestion informatica.

Deja un comentario

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