Las estimaciones son uno de los grandes temas, no solo en la agilidad, sino en la industria completa del desarrollo de software. Hay libros al respecto y varios, por lo que no haré el intento de hacer una revisión extensiva del tema, solo daré algunas aclaraciones sobre los conceptos importantes, y el punto de vista de la agilidad.

Primero, partamos por definir lo que entendemos por una estimación. Una estimación es una opinión profesional en base a la experiencia y el conocimiento, sobre el posible futuro de un desarrollo (o, en general, trabajo o tarea). Esta estimación puede ser en base a uno de los siguientes parámetros (entre otros): tiempo, esfuerzo o costo.

El “estándar” de la industria es la estimación en base a tiempo, ya que se traduce muy fácilmente a una carta gantt y en base a la estimación se proyectan fechas de término y son comunicadas al cliente. Y es ese el gran problema de las estimaciones.

Las estimaciones no son compromisos

Al dar una estimación, está implícito que hay menos de 100% de certeza sobre ese estimado, de otra forma, no se llamaría estimación y se llamaría predicción. Dado lo anterior, es irresponsable comprometerse si uno no puede estar seguro que podrá cumplir.

Generalmente cuando se solicita una estimación en tiempo, se está solicitando un compromiso, ya que si no cumplimos con la estimación, entonces nos tratan de irresponsables. Entonces se generan los típicos vicios de las estimaciones: Inflarlas. El programador estima un tiempo x, pero para “cubrir su espalda” comunica que estima un tiempo x+y. Luego el jefe de proyecto “sabe” que el programador es malo estimando y se trata de resguardar haciendo un compromiso en un tiempo x+y+z. He visto planillas de cálculo que tratan de formalizar este proceso sumando hasta 5 parámetros a la estimación original en base a distintos criterios que parecen muy matemáticos y serios, pero al final, son simplemente eso, números.

Hay varios problemas con lo anterior. El primero es que se elimina lo “profesional” de la ecuación ya que la opinión la descartan como insuficiente y no-confiable. Otra cosa es que se tratan de engañar con todas estas inflaciones “matemáticas” aveces hasta con estadísticas, pero al final lo que hacen estimar el margen de error de la estimación original (wtf right?), no solo una vez, sino que y varias veces por estimación. Para mi eso es simplemente maquillaje de números y al final ponen lo que a ellos les conviene comercialmente.

Otro factor que se debe considerar, es que cuando se realizan estimaciones, mientras más complejas o largas sean las estimaciones, más error tendrán. Somos buenos estimando cosas que son cortas de hacer o fáciles de hacer, pero lo complejo y lo demoroso nos pone en problemas. No somos buenos para prever el futuro lejano, y me refiero a lo seres humanos en general.

¿Como hacemos compromisos responsables entonces? Tenemos que usar las estimaciones para lo que corresponden: estimar. Los compromisos se deben hacer con la información más certera posible. Eso significa aprender, iterar. Esta es una de las razones de por qué el desarrollo iterativo es tan apreciado en la nueva generación de desarrolladores. Entrega datos rápido para realizar compromisos reales y profesionales.

Aprendizaje continuo y el cono de incertidumbre

A medida que uno aprende sobre un problema y entiende los por menores, uno es capaz de estimar con mayor certeza. También la experiencia ayuda a mejorar nuestras estimaciones, pero al final, solamente se sabe el tiempo que algo tomará una vez que está hecho. Si Ud hace el mismo software una y otra vez, exactamente igual cada vez, entonces sabrá muy bien cuanto tomará realizarlo.

Pero no hacemos eso. Siempre hay variaciones, siempre hay casos inesperados y siempre hay complejidades. Estos factores se resumen en incertidumbres y hay de dos tipos: Incertidumbres conocidas (known unknowns) e Incertidumbres desconocidas (unknown unknowns).

Las incertidumbres conocidas se pueden trabajar al inicio del proyecto con experimentación, pero son las desconocidas las peligrosas. Estas solo se pueden ir descubriendo y solucionando a medida que avanza el proyecto y son las variaciones más complejas.

Estimar la cantidad de incertidumbres desconocidas el algo que se te puede venir a la mente, pero te detengo ahí mismo. Piensa de nuevo, date cuenta lo estúpido que es.

Estimaciones en base a tiempo

Ya he adelantado varios de los problemas con estimar en unidades de tiempo, pero por sobre todas las cosas, permite confundir muy fácilmente una estimación con un compromiso.

Un desarrollador estima en horas hombre (HH), luego el jefe de proyecto pasa esas HH por unas formulas oscuras y el resultado lo mete a una gantt y así es como nace un fracaso.

Las “horas ideales” tampoco funcionan. Sufren exactamente el mismo tratamiento.

Pero el problema no es solo las estimaciones y los compromisos, es mucho más de raíz, el problema está con la contabilidad, facturación, contratos y cobros. En base a las horas hombre estimadas, se procede a calcular el costo del proyecto (multiplicando HH por costo por hora de cada persona, luego agregando el margen de ganancia y otras cosas) luego eso se le traspasa al cliente como propuesta de proyecto, define el sueldo de los programadores (subir el sueldo a mitad de un proyecto puede des-balancear al proyecto económicamente) etc.

Este es un cancer en metástasis. Todo porque no podemos entender que nuestras estimaciones no pueden ser adecuadas para estos cálculos. Nunca lo podrán ser.

Estimaciones en base a esfuerzo

Las estimaciones en base a esfuerzo intentan asumir la efimeridad de las estimaciones, y evitar confusiones con los compromisos.

Cuando se realiza una estimación de esfuerzo, se utilizan generalmente una de estas dos unidades: Puntos de historia o tamaño, y ambos son muy similares.

Los puntos de historia son un número entre el 1 y algún otro límite superior (10,20,100, etc). El número solo tiene significado para el equipo, en el sentido que se acuerda que el 1 será la tarea más pequeña que se pueda realizar y cada número será múltiplo directo, es decir un 3 es tres veces más grande que un 1. “Grande” es el concepto clave, ya que no se evalúa solo en base a cuánto podría demorar, sino que tan complejo es el algoritmo, cuántas integraciones pueden haber, los casos de prueba que conlleva, las personas que tienen que colaborar, etc. Al final, es un número que nace de la intuición.

Al ser “puntos” y no “horas” es más complicado confundirlo con un compromiso. Lo que si puedes hacer es dar vuelta un poco la situación y aprender cuántos puntos es capaz de hacer el equipo en un periodo de tiempo (ver post sobre velocidad) y poder comprometerse a realizar la misma cantidad la próxima iteración. Eso es mucho más humano y posible, especialmente cuando vas realizando compromisos en base a los datos que sabes son realidad. A medida que avanza el proyecto tus estimados pueden seguir igual de malos (en realidad, van mejorando), pero tus compromisos serán mas acertados, ya que al tomar como precedente tu comportamiento en el pasado, puedes proyectar correctamente al futuro y podrás incluso adelantar problemas. Para un equipo nuevo, generalmente toma 4 a 6 iteraciones el tener estimaciones muy confiables.

Estimar con tamaños es el mismo concepto, pero sin un valor numérico directo. La idea es hacer más fácil de entender el concepto, a costa quizás de hacer un poco más complejo el proceso. Se escogen de tres a cinco tamaños: (xs, s, m, l, xl) y en base a esa escala se estima. Es mucho más fácil entender este concepto de tamaño que el de puntos (aunque es casi lo mismo). Para calcular luego el compromiso posible para la siguiente iteración, se les asigna un valor numérico igual que en los puntos, por ejemplo, XS=1, S=2, M=4, L=9, XL=18.  Lo importante es que si XS=1 y XL =18 significa que XL es 18 veces más grande que un XS y que no puedes elegir un numero intermedio entre L=9 y XL=18, esto es para ilustrar que un salto de magnitud significa también mayor incertidumbre.

Al ser estimaciones, estos ajustes de incertidumbre y otras complicaciones con etiquetas y números, generalmente solo ayudan a los equipos a estar más cómodos o dar una sensación de control. Utilicen lo que les dé más sentido ya que al final, las diferencias debieran promediarse en el tiempo y quedar incluidas en las estimaciones del equipo.

Estimaciones en la agilidad

Un equipo ágil realiza compromisos a mucho menos plazo. Las metodologías ágiles son todas iterativas, por lo que realizan el compromiso de entrega iteración a iteración en vez de un gran compromiso por proyecto. Si el proyecto es a plazo fijo (es decir, el cliente lo necesita en una fecha dada o cosas muy malas van a pasar) el equipo no se comprometerá con todas y cada una de las features, será un compromiso de “lo que alcancemos a desarrollar a esa fecha”. Obviamente el desafío está en los contratos, comunicación con el cliente y confianza.

De aquí en adelante la conversación se vuelve hacia los contratos con clientes, modelos de negocio y otras cosas complicadas, que si bien me interesan un montón, tengo cero experiencia.

Te invito a continuar la discusión en los comentarios, o mejor aun, en los foros de ChileAgil.