[PM] Estimaciones y Scheduling Avanzado

En este artículo vamos a ver una rápida introducción a la estimación de tamaño, esfuerzo, tiempos total, costos y optimización (compresión) de schedule utilizando simulaciones mediante el método de Monte Carlo.


Aclaración: lo de avanzado es según quien lo lea.


Idea


La idea detrás de esta alternativa de estimación es aprovechar toda la información disponible y utilizarla para ejecutar miles y miles de proyectos virtuales (simulados) idénticos al nuestro para conocer cual es el esfuerzo medio requerido, tiempo medio de ejecución del schedule planteado y la dispersión que presenta. Luego, es posible también plantear distintas combinaciones de ejecución de tareas, simularlas y obtener así el schedule más comprimido, el que presenta menor dispersión, o de ser posible, el más comprimido y que a su vez presenta la menor dispersión (no siempre es posible).


Fundamento


«Caper Jones identifies three major root causes for large software project delays and disasters: inaccurate estimation, inaccurate status reporting, and inaccurate historical data.» [Why Flawed Software Projects Are Not Cancelled in Time]. Y seguro que es así, si partimos del hecho de que la estimación es sobre lo que se basa la planificación y el control del proyecto y el presupuesto, queda claro que un error aquí es un error caro


En cualquier proyecto, la estimación del tamaño (y del esfuerzo luego) es justamente eso: una «estimación». Y por lo tanto se trata de un proceso estocástico en el cual, la salida no es solo un número sino que además viene acompañado de un grado de confianza sobre ese valor.


Cuando alguien presenta una estimación rara vez da a conocer el grado de confianza que tiene sobre ella, ya sea porque es muy bajo, o porque no se conoce, o porque no se sabe calcular, o porque no se sabe aprovechar o simplemente porque parece complicado de administrar. Evidentemente si la duración de cada tarea de un proyecto se observa como una posible nube probabilística, en el sentido de que no se conoce con exactitud cual será su esfuerzo/duración real, la confección del schedule, su control, la determinación del camino crítico y la asignación de tareas parece complicarse un poco. No obstante, aunque existen herramientas para solucionar este problema (véase: PERT), estos son más complejos que la alternativa recursiva y de fuerza bruta que vamos a tratar y además no dicen nada sobre cual es distribución de probabilidades de la duración del proyecto, ni su dispersión por lo que no es sencillo obtener un intervalo de confianza sobre la duración de nuestro proyecto. Por el contrario, simulando el mismo proyecto una y otra vez hasta haberlo hecho algunas miles de veces nos permite obtener las estadísticas de cuanto tamaño/esfuerzo/costos insumieron esos proyectos. Es como revisar los datos históricos sobre proyectos virtuales.


La obtención del esfuerzo está en función del tamaño estimado y, la función de conversión es determinística. Ya sea que se utilicen datos históricos de la empresa, de la industria o métodos como COCOMO, todo se resume a una conversión directa. Pero si aceptamos que el tamaño estimado es solo eso, un valor perteneciente a un espacio probabilístico, y que la función de conversión también tiene cierto error, entonces aceptaremos que tratarlos como datos estadísticos tiene sentido. No estoy solo en este punto ni en ningún otro; el Software Productivity Center Inc. recomienda estimar rangos y menciona explícitamente que la conversión size-effort tiene cierto margen de error. 


Mejoras


No más buffers. Por lo general, y según lo visto en el punto anterior, cuando se le solicita a un desarrollador (tester o lo que fuese) una estimación sobre una tarea a realizar, lo que se espera es lisa y llanamente un número fijo y certero desprovisto de cualquier indicio de ‘probabilidad’. Aún gente que respeto mucho y que sabe muchísimo del tema, y que entienden a la perfección la diferencia entre estimado/real y esfuerzo/duración, no se sienten cómodos con la idea de tener que considerar a las probabilidades sus estimaciones y menos aún en un schedule por lo que prefieren implementar el concepto de ‘buffer’ o ‘gap’ para incrementar las posibilidades de éxito de entrega a tiempo. ¿Pero, de cuanto debe ser ese buffer? ¿Como lo calculan? La realidad nos dice que no se hace nada muy científico :). O es un porcentaje del tiempo de la tarea, o se acuerda con el desarrollador según sus habilidades para negociar, o se le suma un número de horas basado en los dos últimos dígitos del número ganador sorteado por la lotería nacional.


La simulación hace a las asignaciones de tareas más justas y mejor justificadas puesto que otro inconveniente de esta práctica es que, además de ser totalmente arbitraria la asignación de tiempos y solo basarse en aspectos tan subjetivos, como el «a esta tarea deberíamos darle un poquitín más»,  logra que algunas personas se encuentren muy sobrecargadas mientras que otras se aburren y optan por escribir largas entradas en sus blogs referentes a simulación de proyectos :). Es claro, si a todas las tareas se les da un margen un tanto caprichoso (casi aleatorio) entonces habrá algún desarrollador que terminará todas sus tareas sin necesidad de consumir todo su margen y estará escribiendo un post (si no tiene chat) mientras que otro ya se habrá consumido todo su tiempo más su buffer y todavía seguirá sin poder entregar su trabajo (amén de las malas caras del jefe, el overwork y los dibujos en el timesheet para no cargarle más horas a esa tarea a la vez que intenta que no parezca que estuvo desocupado. Dios! pobre tipo.). Pero una cosa es segura, si al que le sobró tiempo no se le permite disfrutar de su tiempo «ganado» entonces la próxima vez consumirá todo su tiempo disponible y oh! casualidad, lo terminará el último día!


Con una simulación, no hacen falta buffer ya que están considerados dentro del esfuerzo total del proyecto. Otra alternativa es manejar dos milestones: uno interno y uno para el cliente. Uno podría tranquilamente calcular cual es el plazo necesario para tener una certeza de entrega a tiempo del 85% y cual es el que nos garantiza un 70% de entrega a tiempo y manejarnos internamente con el primer milestone mientras que nos comprometemos con el cliente para la otra fecha. Como siempre el proyecto se irá atrasando y el gap entre las dos fechas se irá reduciendo a modo de termómetro.


Sencillez, flexibilidad y economicidad. La verdad es que por más que el juicio experto sea un método demasiado ‘intuitivo’, además que se requiere la existencia de un experto en proyectos similares, es uno de los métodos más utilizados. Ya sea en su forma más pura, o como complemento de otros métodos o como parámetro de entrada en alguna tool de estimación parametrizable, esta técnica sobrevive gracias a su sencillez, flexibilidad y economicidad. Pero aquellas empresas que no poseen un historial de proyectos, muchas veces acuden a una estimación direct-to-effort utilizando el juicio experto el cual no aporta más que un único dato: la estimación pelada, sin un grado de certeza o riesgo.


Con el método que veremos ahora es posible aunque más no sea, introducir en las consideraciones mayor información proveniente del experto como cual estima que sería el tiempo mínimo, el más probable y el tiempo máximo de duración de una tarea, y de esta manera realizar simulaciones teniendo en cuenta que la tarea en cuestión posee una distribución de probabilidades triangular (este fue solo un ejemplo. Según los datos que tengamos podremos utilizar la distribución más conveniente).


Por otro lado, si este no fuera el caso y sí se contara con información histórica, podría alimentarse el modelo con esos datos y simular la ejecución del proyecto para estudiar alternativas de schedule, simular riesgos o realizar análisis de sensibilidad sobre las tareas del proyecto.


Análisis de sensibilidad. Al contar con un modelo que puede ser simulado, es posible realizar un análisis de sensibilidad para conocer como se verá afectado el proyecto ante variaciones en el tamaño/esfuerzo de las tareas de modo de focalizar la atención sobre las tareas que tienen mayor potencial de hacer fracasar el proyecto en términos de tiempos mientras que se libera el control innecesario sobre las tareas que tienen un bajo poder de impacto.


sensibility


Por ejemplo, del análisis de sensibilidad del schedule más conveniente del proyecto de ejemplo, surge que hay que presarle especial atención a las tareas test_contacts_report y test_contacts_search (tareas de testing de dos features del módulo de contactos) que como se imaginarán están en el camino crítico.


Considerar los riesgos. En todo proyecto existen riesgos que deben ser controlados. En la mayoría de las veces esto se gestiona  utilizando una planilla Excel como herramienta en la que a cada riesgo identificado se le asigna, entre otras cosas, una probabilidad de ocurrencia y el impacto que tendría su ocurrencia sobre el proyecto. Por más que los riesgos se «gestiones», estos no desaparecerán del todo y su ocurrencia seguirá afectando al proyecto de alguna manera consumiendo esfuerzo indefectiblemente y esa relación (riesgo->esfuerzo) puede introducirse en la simulación de manera que, en alguna de las corridas del proyecto el riesgo se producirá, consumirá el esfuerzo en cuestión y ese esfuerzo formará parte de las estadísticas finales. Los riesgos convendría asociarlos a las tareas en lugar de hacerlo con el proyecto completo porque la ocurrencia de un riesgo no afectará al proyecto de igual manera si retrasa a una tarea que se encuentra en el camino crítico que si lo retrasa a una tarea que no lo está.


Mayor entendimiento de los posibles escenarios. Como ya dijimos, el que cada una de nuestras certezas tenga ahora un grado (medida de la certeza) parece complicar la administración haciéndola demasiado parecida a la realidad. Pero esto es muy bueno porque presenta una enorme cantidad de información contra-intuitiva que nunca se nos hubiera ocurrido (o al menos eso me pasó a mi). Luego de simular varios schedules con las mismas tareas uno puede encontrarse con que existen schedules que arrojan menores tiempos en promedio pero con mayor desviación estándar mientras que otros tienen peores plazos pero con mucho menor desviación estandár. La elección dependerá de nuestra simpatía o aversión por los riesgos o a otras necesidades. Otro efecto (demoledor) de simular nuestros proyectos es que por más que ajustemos todo y elijamos valores  para tiempos de entrega y esfuerzo que nos garanticen un 90% de certeza de cumplir con el cliente y el presupuesto, cuando simulamos con un gran número de iteraciones vemos que: el 10% de las veces nuestro proyecto fracasa!!!! Parece una obviedad y lo es pero no deja de hacerme pensar. Cae al caso recomendarles el libro «¿Existe la suerte?: Engañados por el azar» de Nassim Nicholas Taleb que podríamos resumir así: «si nunca ha fracasado ninguno de tus proyectos es solo porque no has participado en suficientes» la pura estadística lo demuestra. 


 acumulado frecuency


El camino crítico puede no ser el camino crítico. Si bien duración no es igual a esfuerzo, cuando solo se cuenta con un único desarrollador que trabaja exactamente 8 horas y que está abocado a una única tarea, entonces en ese caso particular el esfuerzo y la duración son lo mismo (quiten los fines de semana, vacaciones y cualquier otra cosa que hagan que esto no se válido). En ese caso, si planteamos que esfuerzo y duración son lo mismo, y acordamos que el esfuerzo no es un valor obtenido de forma determinística, entonces la duración de las tareas variará. En el ejemplo de abajo ilustro esa situación en la que existen tres tareas y dos desarrolladores, dev1 tiene asignada dos tareas secuenciales cuya duración media son de 4,6 hs. y 4,85 hs respectivamente mientras que dev2 tiene asignada una única tarea cuya duración media estimada es de 10 hs. Si no fuese porque en este ejemplo hemos establecido que esfuerzo y duración son equivalentes, el camino crítico estaría dado por la tarea nro. 3 pero en este caso particular el tiempo máximo de la ejecución en serie de las tareas 1 y 2 es mayor al tiempo mínimo de ejecución de la tarea 3 por lo que aquí no tenemos un camino crítico definido. 


criticalpath


Conocer el coeficiente de amortiguamiento. Ante un retraso, si no es posible re planificar la entrega, existen dos posibilidades: asignar más recursos a una tarea (este es todo un tema aparte) o que la gente haga overwork. Estos dos factores hacen las veces de amortiguadores del proyecto. Ahora, la asignación de más gente a una tarea no siempre es buena idea y tiene un límite, de igual manera, la jornada laboral de los ingenieros no puede alargarse hasta el infinito. Por lo que estos amortiguadores tienen una limitada capacidad de absorber las oscilaciones de un proyecto. Simulando estas situaciones con datos históricos de los timesheets es posible conocer cual es la capacidad que tienen los ingenieros de salvarnos.


Una herramienta


Para realizar cualquier tipo de simulaciones con el método de Monte Carlo nada mejor que MS Excel sin duda. Ahora, además de esto existen muchos add ins comerciales que pueden adquirirse en la web, pero para quienes quieran experimentar con un sencillo y muy útil add-in les recomiendo SimuAr es un «emailware» . Con esta herramienta he desarrollado el ejemplo.


Para simular proyectos en serio les recomiendo Slim y Construx Estimate.


El ejemplo


Por razones de sencillez del modelo voy a realizar una estimación direct-to-effort, es decir, no estimaremos el tamaño y vamos a hacer de cuenta que esfuerzo y duración de la tarea es lo mismo. En otras palabras, vamos a estimar como lo haría un albañil. 


En este ejemplo existen solo tres etapas: Análisis de requerimientos a cargo del líder técnico, codificación y test unitario a cargo de tres desarrolladores y testing a cargo de un solo tester. Se desarrollarán 4 módulos de un CRM: Contacts, Activities, Cases y Opportunities. Todos utilizan una distribución triangular cuyos parámetros han sido proporcionados por nuestro experto virtual (no tengo un experto cerca en este momento). Se plantan dos schedules ultrasencillos para simular, el primero consiste en «Etapas secuenciales y codificación en paralelo (salvo Contacts y Activities que pertenecen al mismo desarrollador)» mientras que el segundo consiste en «Modulós en paralelo c/lider técnico en el camino crítico», esto significa que debemos esperar a que el TL ponga las specs de un módulo en baseline antes de poder comenzar con la codificación.


 estimation


Los schedules se simulan con la siguientes fórmulas:









secuenciales y codificación en paralelo =s_reqana+MAX(s_cu_contacts+s_cu_activities;s_cu_cases;s_cu_opp)+s_test_contacts
Modulos en paralelo c/lider técnico en el camino critico =MAX(reqana_contacts+s_cu_contacts+s_test_contacts+s_cu_activities+reqana_activities;SUM(I3:I5)+s_cu_cases;SUM(I3:I6)+s_cu_opp)+vsalida()

Esto es porque la duración total de las tareas secuenciales es igual a la suma de sus duraciones mientras que la duración de las tareas paralelas es igual al tiempo de duración de la que insume mayor tiempo.


Para bajar el archivo de ejemplo y correrlo hay que instalar previamente el addin SimuAr.


Continuará…


Lucas Ontivero

Sin categoría

12 thoughts on “[PM] Estimaciones y Scheduling Avanzado

  1. Pensé que tardarías más en sacar el post 🙂

    Excelente como siempre.

    Ahora, me pregunto. Quien se animaría a usar este modelo (además de mi y vos, claro), después de años de adoctrinamiento y aceptación de todo aquello que sabemos, no es el mejor modelo?

    Me refiero a que, como dijiste y hemos hablado, prácticamente en todos los casos se recurre a la estimación a ojo. O sea, el manager del proyecto le pregunta al desarrollador cuanto va a tardar, este tira un numero, el cual, sumado a todos los demás números deberá caer dentro de la fecha que el cliente le dijo al primero, sobre cuando esperaría tener el producto terminado, para que nuevamente el manager, «negocie» con el desarrollador otra fecha, y finalmente agregarle un %, para un posible «if the fly» o «por si las moscas».

    Creo que este método puede ser más certero, que por ejemplo, recurrir a una base de datos históricos (proyectos ya hechos), que contiene miles de horas cargadas por ingenieros que se vieron en la necesidad de maquillar horas para no ser amonestados. En definitiva, estos datos son tan incorrectos como podría serlo la raíz de toda estimación. O sea, el «cuanto crees que te puede tomar?».

    Digo mas certero, debido a que, si bien estamos «tirando los dados» para sacar probabilidades, estaremos seguros que en miles de iteraciones por lo menos tendremos la posibilidad de fracasar un X%, así como tendremos un Y% de chances de hacer las cosas bien. La diferencia, y porque optaría por este sistema, es que con el, estaría totalmente convencido de las «CHANCES» de conseguir que el proyecto funcione. A diferencia de usar los métodos tradicionales, donde nos engañamos creyendo que por contar con datos de cientos de proyectos reales o porque alguien con experiencia nos dio un estimado, deberíamos llegar a buen puerto. Con esto quiero decir que, normalmente nos auto engañamos. Nos hacemos creer que eso es correcto, aunque sabemos perfectamente que los datos que estamos manejando son inconsistentes. Lo que nos lleva a una menor aceptación de las posibilidades de fracasar. Lo que acarrea las típicas represalias sobre el ingeniero a cargo de una sección del desarrollo, lo que hace que este se sienta mas hundido en su desgracia, se frustre, y naturalmente retrase aun mas el trabajo que, desde un principio estuvo totalmente mal estimado.

    Entonces, sabiendo cuales son mis posibilidades desde un principio, es mas fácil, si bien, no aceptar el fracaso con un simple: Y bue, sabíamos que teníamos un X% de que esto no funcione.

    Si podremos ver antes, un pseudo futuro para nuestro proyecto y tomar el que mas nos convenga.

  2. Sinceramente, no me puedo creer que a estas alturas del siglo XXI, haya quien todavía piense que los métodos analíticos y estadísticos de estimación funcionan…

    Utilizar datos historicos y valores medios para la estimación es algo que funciona para el proyecto medio, ejecutado por el equipo medio, con tareas de complejidad entorno a la media…

    La realidad es nosotros queremos estimar nuestro nuevo proyecto. Generalmente diferente de los proyectos sobre los que contamos con datos estadísticos (si es que contamos con esos datos). El proyecto que estemos estimando lo hará, muy probablemente un equipo diferente a proyectos anteriores, con diferentes conocimientos, habilidades y destrezas… Ningún proyecto informático se parece demasiado a uno anterior, y la dispersión es tal que las leyes de los grandes números funcionan de manera tan débil que apenas justifican el esfuerzo de llenar de datos una herramienta.

    Usar solo métodos estadísticos para estimar es algo que solo nos da estimaciones mediocres… y que exije un esfuerzo alto.

    No hay una técnica de estimación que sea una bala de plata. Solo una combinación de diferentes técnicas da resultados.

    Un saludo!

  3. Matias, en primer lugar gracias por tu comentario. Me parece claro que los has leido y releido y lo has masticado bastante. Se que no crees mucho en los datos históricos y que preferís un enfoque más parecido al de direct-to-effort solo que sin saltearse la estimación del size. Creo que es una buena alternativo por dos cosas: es más facil de entender y de negociar con los desarrolladores y también puede que no tengas datos históricos o que estos sean muy disimiles por tratarse de tecnologías distintas, equipos distintos, entornos distintos, etc. Es exactamente el enfoque que usaría yo si me tocase estimar.

    Rodrigo, si «utilizar datos historicos y valores medios para la estimación es algo que funciona para el proyecto medio, ejecutado por el equipo medio, con tareas de complejidad entorno a la media…» porque no nos enseñas por favor como lograr resultados superiores a la media en todos esos aspectos que mencionas?
    La justificación de que «este proyecto es diferente» es del maestro de lo evidente (y sin Espada del Augurio) porque todos los proyectos, de software o no, son todos diferente. El creer que somo especiales, que nuestros proyectos son distintos, que esto no es ingenieria y todas las frases similares son una enfermedad de esta industria por su novedad.
    Vuelvo a lo mismo, si «Usar solo métodos estadísticos para estimar es algo que solo nos da estimaciones mediocres… y que exije un esfuerzo alto.» enseñanos como lograr estimaciones «no-mediocres» pero que no lleguen a ser malas. Lo del esfuerzo alto no es cierto: tardé menos de 15 minutos hacer una estimación con construx!
    Que «Solo una combinación de diferentes técnicas da resultados» es otra verdad muy clara. Yo no digo que deba usarse solo esta técnica, lo que digo es que esta es solo una técnica más que puede utilizarse.

    Saludos.

  4. Lucas, primero disculpas por no haber leido el post completo pero cuando leo palabras como «riesgos», «camino critico», «excel», «formulas» y demás palabras que los project leaders repiten para hacerse los interesantes hasta me dan ganas de ir a leer un post del dios de la programacion (vos sabes quién es) y enterarme si ya saco su ajContruye-tu-aplicacion-clikeando-un-boton. Pero, tratándose de vos te diría que no me gusta eso de pensar en «estimar como lo haria un albañil». Un albañil no se compra un libro de albañileria (o lo baja x el emule..) y lo lee por las noches para aprender que posicionando los ladrillos con un determinado patron va a ahorrarse materiales o le va a permitir al proximo albañil a que agregue otra habitacion a la casa de una manera más rápida.

    Yo creo que hasta en la simple decisión que toma un desarrollador de poner 58 métodos en una clase «comun» del tipo: CommonClass.GenerateEmail(from, to) junto a CommonClass.GetInvoice(id) para ganar tiempo al programar en contrario a tener un buen diseño de clases existe una gran diferencia de horas. A que viene esto? imaginate tu frustración como desarrollador si tres personas antes que vos hicieron el módulo de Contacts en 16 horas con archivos de código de más de 10.000 líneas como has visto en tu trabajo y ahora te toca a vos hacer lo mismo, pero, como lo queres hacer bien tu estimación es de 24 horas lo cual es un 50% más que lo que dice la maldita estadística. Seguro terminas haciendolo como los anteriores para que no se aparezca el que hizo 5 años de ingenieria en una carrera para sólo saber usar el excel (tambien llamado Project Leader) y frunza el ceño al lado tuyo mientras sostiene el diagrama de gantt.

    Por último (que largo! ni yo me leería mi comentario), para mí si alguien quiere que el proyecto de software le salga bien tiene que contratar buenos ingenieros, tenerlos muy contentos y darles las herramientas apropiadas para que hagan el mejor trabajo posible.

    Saludos!

  5. Lucas…

    Hay técnicas que con mucho menor esfuerzo obtienen resultados mucho más fiables y sobre todo producen estimaciones que la gente percibe como suyas, no como las de una herramienta. Esto es vital, porque los desarrolladores que no perciben las estimaciones como algo propio, algo en lo que han tenido voz y en lo que han participado, no cuentan con la motivación necesaria para cumplirlas. Nada me mueve a cumplir las estimaciones de una herramienta, pero si son mis estimaciones o las de mi equipo y son consensuadas y aceptadas por todos, ten claro que el desarrollador se dejará la piel para cumplirlas.

    Sobre el tema de si la ingería de software es diferente, es algo que cada vez más desarrolladores tenemos claros. No es un cuestion de falta de madurez es una cuestión de ver que llevamos 40 años perseverando en el error de pensar que la ingeniría de software no es diferente. Quizás por eso los clientes perciben los proyectos de software como un mal necesario en gran medida. Habría mucho que hablar sobre esto, y lo podría justificar… y seguro que escribiré sobre este tema… pero no quiero estenderme demasiado ahora.

    He escrito mucho sobre estimación en mi blog, en el puedes ver la aproximación que desde la metodologías ágiles hacemos a la estimación.

    Te propongo que leas aquí: http://geeks.ms/blogs/rcorral/archive/tags/Estimaci_26002300_243_3B00_n/default.aspx

    Un resumen que considero interesante sobre la aproximación ágil a la estimación es el que expongo aquí: http://geeks.ms/blogs/rcorral/archive/2007/07/22/el-dif-237-cil-problema-de-la-estimaci-243-n.aspx

    Y espero tus críticas, si es que las tienes. Del debate sano surge la mejora.

    También me voy a permitir el sugerirte un libro espectacular: http://geeks.ms/blogs/rcorral/archive/2008/01/30/he-le-237-do-agile-estimating-and-planning-de-mike-cohn.aspx

    Me gustaría seguir generando un debate sano sobre este tema. Sinceramente, COCOMO y las herramientas estadísticas es algo que la mayoría de autores modernos consideran como algo superado. De hecho son herramientas que existen desde hace decadas y que ‘nadie’ usa, lo que nos debe llevar a ser cuando menos críticos a la hora de analizar su validez.

    Un saludo!!

  6. Carlos, hay varias cosas juntas en tu comentario así que voy de a una por vez:
    Lo primero es que ya sé que no lo haz leido y que riesgos y camino crítico son conceptos importantes, no son solo palabras lindas y altisonantes para hacerme el interesante.
    Segundo, después que contrates a tu primer albañil hablamos. a mi vieja el albañil le terminó cobrando más del doble y tardó también el doble. El la empresa en donde trabajamos juntos…como les fué con el proyecto de la casona?. Si hasta en los Simpson se rien de las estimaciones de los albañiles porque tiran un número a la manchancha!
    Tercero, el problema es que cuando las cosas se hacen mal el que menos tiene la culpa es el método de estimación! Cuando los comerciales arreglan una fecha con el cliente (a veces les hacen creer que ya lo tienen por lo que no pueden atrasarse ni un segundo) y luego tu jefe te fuerza a decir un número, para convertilo luego en un compromiso «que vos asumiste y al que te comprometiste», entonces es cuando se te para al lado tu jefe con el gantt y la mala cara. El resumen es que en ese caso lo que realmente está mal es tu jefe que te pide estimaciones cuando ya sabe para cuando lo quiere y después, como no llega porque estimó mál o no estimó, quiere forzar las cosas estirando el amortiguamiento hasta que después de toda esa ensalada de imbecilidades termina fracasando el proyecto o en el peor de los casos, el proyecto es un éxito. Si fracasa es porque vos y la otra manga de vagos no se ponen la camiseta, pero si resulta exitoso es porque él es un as del project. En realidad ese tipo no sabe que chances tiene su proyecto! tal vez tenía solo un 20% de chances de ser exitoso y el pobre imbecil se enoja cuando el proyecto fracasa o por elcontrario, el proyecto tenia todas las de ganar y se le infla el pecho de orgullo por su logro.
    La mayoría, al ajustar tanto los tiempos y al ser tan irracionales, juega a tirar la moneda. O acaso decime con la mano en el corazón, cuantos proyectos exitosos tenes encima? cuantos fracasaron? y ahora sacá el porcentaje! mal no?
    Otra cosa al margen, actualmente trabajo en un proyecto en el que los creadores creen ser los más locos del mundo y por eso es la cagada que es. Pero existen proyectos de la reputísima madre en los que me encantaría trabajar. El proyecto en el que trabajo no es propiedad de la empresa sino que lo hicieron unos yankis muy chacheros.
    Y por último, el sueño del pibe: buenos ingenieros, contentos (pagarles bien), con herramientas apropiadas para el mejor trabajo, etc, etc. son el sueño del pibe y aún teniendo todo eso, si estimas mal estas perdido, muy perdido.
    Que culpa tiene un étodo de estimación de todas las malas decisiones de una empresa realmente no lo sé.
    Saludos.

  7. Rodrigo,
    Cuando decis que hay técnicas que con menor esfuerzo obtienen resultados más fiables, debo entender que has comparado estas técnicas? Tenés las pruebas a mano? Con cuantos proyectos has probado esto? Si esto no es así preferiría pasar a otra cosa aunque del mismo párrafo, desgraciadamente me doy cuenta de que no has lei mi post o bien no lo has entendido. Por qué los desarrolladores no considerarían estas estimaciones como suyas? si son «ellos» los que analizan el problema y no solo proponen UN número sino que además aportan mucha más información como cual estiman «ellos» que podría ser el menor esfuerzo y cual el peor esfuerzo. El algoritmo lo único que hace es jugar con esos número para decirnos que «según lo que los desarrolladores aportaron» el proyecto necesitará tal o cual tiempo estimado y una dispersión como datos auxiliar. En este método que propongo, como alternativa al experto juicio pelado para las estimaciones direct-to-effort, nada sale de otro lugar que no sea de la boca y del estudio de los propios desarrolladores, no hay funciones de conversión como en COCOMO ni datos históricos con los que pueda alguien estar en desacuerdo, ni datos propios de la industria, ni factores de productiviodad de los lenguajes, ni factores de complejidad ni nada de nada. Es tan dificil estar en desacuerdo que no lo entiendo y o tengo otra que llegar a lo que llego; a que no lo has leido.

    En cuanto a los de la ingeniería, yo pienso que sí es ingeniería al igual que lo pienta Steve McConnel y Joel Spolsky entre otros y sí, también soy desarrollador.

    Tu blog lo leo siempre y nunca me ha pasado de ver un comentario en mi blog hacia un post tuyo que yo no haya leido ya. Como ahora te das cuenta, no siempre estamos de acuerdo. En cuanto al libro, no lo he leido así que lo voy a leer y si resulta tan interesante como decis, entonces lo voy a disfrutar y mucho. Aunque estoy seguro que lo debes conocer, te comento que estoy leyendo «Software Estimation: Demystifying the Black Art» de Steve McConnell y está muy pero muy bueno – recomendable.

    En una cosa estamos de acuerdo: COCOMO a mi tampoco me gusta. Pero tampoco me gusta lo que no es preciso, «la mayoría de autores modernos…» quienes son? porque la decis: mayoria? los contaste y afirmativamente son más que los que piensan lo contrario o es tan solo un sesgo tuyo? Está claro que las personas siempre seleccionan lo que leen de manera de leer solo lo que les parece correcto pero esa actitud no es correcta. Es muy dificil decir que las matemáticas en nuestra profesión son distintas sin apelar a la más caprichosa de las subjetividades. Y la única forma de mantenerse firme ante la evidencia es simplemente cerrar los ojos y taparse los oidos y cuando te pidan pruebas, hacer hasta lo imposible por no presentarlas tan solo porque son demasiado conocidas por todos!

    Este es el mejor espacio para un debate sano pero abrir un comentario con una patada a la cabeza del blogger, por el solo hecho de pensar distinto, no es muy saludable.

    Saludos Rodrigo.

  8. Creo que uno de los principales problemas que estoy viendo en el debate, es que o no se está terminando de leer el post de Lucas, o no se lo está terminando de entender.
    Posiblemente, en mi caso, lo veo desde otro punto de vista, básicamente por las conversaciones entabladas con Lucas, las mismas que pudieran complementar eso que, tal vez, faltara en lo anteriormente escrito.
    En todo caso, veo que hay dos líneas fundamentales o, mejor dicho, fundamentalistas cuando de ingeniería de software y de plazos de desarrollo de proyectos se trata.
    Por un lado, veo los que fueron totalmente desilusionados por una burocracia desmedida, entre papeles y cifras, que consumían tiempo, y que, lo más notable, agregaban frustración. Estas personas pasaron por esto básicamente desde una postura de desarrollador o ingeniero raso, donde tenían a un pseudo pelotudo que los dirigía. Especialmente, este pseudo pelotudo, se encargaba de no hacer su trabajo, y al mismo tiempo, tratar de impedir a toda costa que ese ingeniero hiciera el suyo. Esto es consciente o inconscientemente.
    Básicamente, con este punto me refiero a un «líder» o «manager» que no sabía unir dos palabras para formar una frase coherente, y que siempre que notaba algo que estuviera fuera de lo pactado se desesperaba, por su propia incompetencia, y aplicaba presión desmedida sobre aquel que, este pelotudo, creía culpable. O sea, el ingeniero raso.
    Este ingeniero vivió una experiencia tan amarga que dijo: – Esto no sirve, yo SÍ tengo la «papa» en lo que planificar proyectos se refiere.
    Finalmente, este ingeniero tomo el control y trató de no hacer lo mismo por lo que el paso, ya que estaba convencido que no era la solución.
    Por el otro lado, esta aquel que vivió esta experiencia burocrática, pre digerida e instruida en la universidad, como una religión. Como nota al pie, si alguien es de estos, es probable que sea el pseudo pelotudo que dije antes, por lo que, si en algún momento llegara a ser mi jefe, por favor obviar la idea que para mi, es un pseudo pelotudo, y solo considerar que lo tomaré de imbécil.
    Digo esto, debido a que esta persona representa el otro extremo, el que cree que todo se debe hacer sistemáticamente, y que si no está escrito en un libro difícilmente es creíble. Ahora, esta persona, usará todas estas técnicas aprendidas, y las aplicará al máximo, esperando que todo salga bien. Esto sería más o menos como pararse en una línea de ensamble de bombas, y con un martillo pegarle a cada una de estas bombas en la punta, rogando que no estén armadas, para así comprobar la calidad de las mismas. Es obvio, si la analogía no les gustó, que este imbécil, constantemente, o mejor dicho, estará totalmente convencido que el enemigo directo de todo proyecto es el mismo ingeniero raso, por lo que lo culpará de toda falla, retraso, o mala planificación y ejecución del plan de trabajo.
    Por lo que expliqué en el primer comentario que hice, el problema viene desde el principio, ya que este tipo está basando todo su conocimiento en información adulterada, falsa y disfuncional. Por lo que está tan fuera de foco como el que cree que tratar de planificar es erróneo.
    Ahora, lo que plantea Lucas, y desde mi punto de vista es lo más importante, que mas allá de un numero que más o menos se podría aproximar a una fecha de entrega o de conclusión de un proyecto real, es que los datos usados para llegar a este número no son falsificados, si no, que son simulados en base al «azar» (Si no crees que el azar esta dentro de todo en la vida, necesitaremos otro post de Lucas para poder debatir esto), o a la «randomización» de posibilidades. Con la diferencia que, de antemano, sabes que tienes una posibilidad de que todo esfuerzo que realices igualmente tienda al fracaso, ya que, como se demostró, tienes un % de posibilidades de que esto no funcione. Esta conciencia de fracaso les hará las cosas más llevaderas a todos, y por otro lado, te dejará elegir la opción con la que te sientas más cómodo y que, por supuesto, te de menos posibilidades fracasar.
    Ahora debo aclarar, para reforzar algunos comentarios de Lucas, lo siguiente:
    – Si tu proyecto ha tenido que ser re planificado por algún motivo, y aunque después de haber realizado esta re planificación lo entregaste como correspondía. La verdad es que, tu proyecto ya fracaso una vez. Esto quiere decir que tu primera planificación fue equivocada, por lo que ya tienes una pepa en contra.
    – Si comprometerse con un schedule representa que el ingeniero deba quedarse 15 minutos de más en cada jornada laboral, para poder cumplir ese compromiso. Entonces, una vez más, tu planificación fracaso totalmente.
    Básicamente, estas consignas, entre otras tantas, son algunas que creemos o aceptamos como comportamientos naturales en todo proyecto de software. Pero, no nos damos cuenta que cada una de estas pautas son simplemente fracasos, o micro fracasos, dentro del proyecto.
    Ahora, después de analizar estos dos simples puntos que planteo. Quien se anima a decir que algún proyecto en el que estuvo involucrado NUNCA fracaso?

  9. Cuantas cosas! Y sí, entre fracasos, microfracasos y fracasos camuflados de renegociaciones podríamos decir que los proyectos de software «gustan mucho de fracasar» pero parafraseando mas o menos a Nassim Taleb, lo que diferencia a los proyectos de un juego de ruleta rusa es que en el proyecto no vemos el revolver apuntándonos en la cabeza pero las probabilidades siguen ahí.

    El otro punto, el de los datos falsificados, es un tema enorme enorme pero quiero dejar acá 3 cosas:
    – los datos son falsos porque las empresas crean el sistema que obliga a mentir. En tres trabajos me sentí obligado a mentir, ya sea porque me exigian cierto número de horas facturables (1) o tantas horas semanales en el timesheet (2) o porque tenia que facturar 7.000 euros (3). Esto último no necesita mucha explicación: si pudiera facturar 7.000 euros desde argentina, por qué trabajaria para vos?
    – los datos son falsos porque los proyectos son muy disimiles y aunque presentan un patrón claro de correlación, uno observa los puntos se desparraman demasiado alejados de los minimos cuadrados y por lo tanto no son tan confiables como uno quisiera.
    – esto último no quita que puedan mejorarse aunque la realidad dice que parece que nunca se mejorarán en ninguna empresa.

    Por último Matias, no te imaginas cuantas veces quise poner en mi blog lo que vos has resumido como «pseudo pelotudo», en realidad lo que más me fascina es la palabra pelotudo, el pseudo es opcional. Es un concepto Dilberiano muy preciso. Ahora, cuanto mal le hace a la gente (y por transitiva, a la empresa) este pelotudo nacido como de un licuado de El Principio de Dilbert y El Príncipe (de Maquiavelo) pero con tres materias de liderazgo, gestión estratégica y project I. Hablabamos con Zanini del miedo y la desconfianza que generan las estimaciones en los desarrolladores por eso de que al fin y al cabo «después te controlan con eso!». No es que Carlos esté super equivocado, es que es una realidad el que dar las estimaciones se convierta en algo parecido a firmar tu acta de defunsión pero eso solo ante un comité de pseudo pelotudos, yo también pensaba lo mismo porque me reprochaban el que «yo me habia comprometido» como dandome a entender de que «yo no tenia palabra» cuando en realidad lo que no tenia era la bola de cristal. Después de todo, existe una teoría muy aceptada que dice que las cosas no funcionan muy bien porque los empleados son un poco vagos e ineptos; y seguro que es así, si uno no fuese tan vago e inconciente de atrasarse el jefe sería tan genial como él cree que es, pero realmente no puede porque está siempre rodeado de vagos que se atrasan. El pecado de estos tipos es no entender de estimaciones, de probabilidades y de no ser concientes del revolver en la cabeza.

    Bueno, en fin, aunque el post no se lea mucho ya llevamos como un libro de comentarios.

  10. Lucas… quiero pedirte disculpas si mi primer comentario sono rudo. Releyendolo creo que no fuí correcto. A veces soy demasiado behemente…

    Sobre si leí tu post: claro que sí! Con atención… no entiendo porque es necesario tamizar mediante una herramienta los datos que salen de la boca del equipo de desarrollo si estos están fundados en un proceso de estimación razonable.

    Sobre la cantidad de proyectos en que use tecnicas ágiles de estimación, te puedo asegurar que son muchos. Yo no cuento con datos comparativos mios. Pero hay una enorme cantidad de ellos.

    Sobre si Joel y McConnell (tios a los que admiro infinitamente) piensan o no que la ingeniera del software es una ingeneria no tengo dudas. Yo tamibién creo que es una ingenieria. Pero una esencialmente diferente de la ingenieria industrial, naval, etc…

    En otras ingenierias es viable hacer toda la fase de diseño aguas arriba del proyecto, a priori, una vez completado este el resto es construir. En el software cada línea de código que se escribe supone una decisión de diseño. Cada línea que se escribe puede podrucir un bug. Ningún barco se hunde por un solo tornillo. El software falla por una sola línea erronea. Cambiar el diseño de un barco es muy muy muy costoso, por pequeño que sea el cambio, eso exige que el diseño previo sea sumamente concienzudo. Esto no es así en el software. Los cambios son mucho más sencillos de realizar, sobre todo si cuentas con una buena arquitectura. La flexibilidad es vital en el software, pero no es una caracteritica que se busque o que sea posible cuando construyes un coche, un barco, un tren o un edificio… La ingeniería del software es una ingeniería, seguro, pero una muy muy diferente.

    Un saludo!!!

  11. Disculpas aceptadas Rodrigo. Yo veo que cada uno intenta hacer su aporte al conocimiento general desde sus respectivos puntos de vista y creo que discutir desde experiencias no compartidas es sumamente dificil. Probablemente en muchos post no estaremos de acuerdo aunque seguiremos leyendonos, de eso estoy seguro.

    Un saludo!!!

Responder a lontivero Cancelar respuesta

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