principal

Resolviendo algunos de los enigmas de la estimación de software

Introducción

Si estás leyendo esto, es muy probable que ya hayas estado estimando proyectos de software o estés a punto de estimar uno. Hacer una estimación es una tarea compleja. Esto se debe, en muchos casos, al hecho de que interpretamos mal lo que los ejecutivos (los gerentes y las partes interesadas) están buscando cuando solicitan un proyecto. Mientras nosotros, en general, intentamos ofrecer una lista de las funcionalidades del proyecto junto con su fecha aproximada de entrega, los ejecutivos buscan un compromiso o un plan para alcanzar un determinado objetivo.

En este contexto, solemos fijar un plazo de tiempo específico, al final del cual el ejecutivo espera ver el proyecto terminado (esto es, un compromiso). Estas situaciones pueden resultar en el fracaso del proyecto o en un exceso del presupuesto. Estoy seguro de que la mayoría de ustedes ya están pensando: “¡Eso es exactamente lo que me ocurrió!”. Bueno, permíteme decirte que no estás solo. A continuación, vamos a compartir nuestra experiencia, para así poder darte algunos consejos sobre cómo ofrecer buenas estimaciones.

Durante nuestra carrera como estimadores, el libro “Software Estimation: Demystifying the Black Art”, de Steve McConnell, nos resultó invaluable. Por eso, este artículo analiza algunos aspectos importantes sobre la estimación y resume los puntos claves del libro de McConnell en base a nuestro aprendizaje del mismo.

Estimaciones, compromisos y objetivos

Empecemos definiendo la palabra “estimación”. De acuerdo con el diccionario Merriam-Webster, estimar es “hacer una determinación aproximada del tamaño, la amplitud o la naturaleza de algo”. Por lo tanto, en el mundo del software, una estimación es una predicción de cuánto va a tardar o cuánto va a costar un proyecto. Sirve como introducción para desarrollar un plan para alcanzar un objetivo que eventualmente lleve a un compromiso. Un compromiso es una promesa de entregar un determinado conjunto de funcionalidades con un nivel de calidad predefinido en una fecha específica.

No debes confundir una estimación con un compromiso o un objetivo. Un objetivo es una meta, algo que queremos alcanzar. Por ejemplo, si te piden que hagas la estimación de un proyecto que debe presentarse en una fecha específica, tu objetivo es tener el proyecto listo para esa fecha. Tu estimación te va a ayudar a preparar un plan para alcanzar ese objetivo.

Un plan puede comenzar preguntándole al cliente si es posible deshacerse de ciertas funcionalidades, o si puede preparar una lista de prioridades, para que podamos entregar las funcionalidades más importantes a tiempo. Una vez que tu plan está listo, puedes comprometerte a entregar todo aquello que puede ser logrado antes de la fecha específica. Es de especial importancia reconocer la diferencia que existe entre el objetivo empresarial y la estimación de un proyecto, ya que esto puede definir el éxito o fracaso del mismo.

“Una estimación es la predicción más optimista que tiene una probabilidad de volverse realidad diferente a cero”

— Juan Urrego

Sobreestimación y subestimación

Una de las lecciones más valiosas que hemos aprendido, si no la más valiosa de todas, es la importancia de siempre hablar de estimaciones en términos de un rango de tiempo o de probabilidades. Por ejemplo:

Estamos 90% seguros de que podemos completar este proyecto en 26 semanas.
Estimamos que, en el mejor de los casos, estará listo en 17 semanas, y en el peor de los casos, en 25.
Estimamos que tardaremos entre 18 y 24 semanas.

Esto se debe a que, si haces una estimación muy puntual, estás asumiendo que existe un 100% de probabilidades de que el resultado final sea igual al resultado esperado, lo cual no es realista. En general, las estimaciones puntuales suelen ser objetivos enmascarados como estimaciones. Estas estimaciones suelen hacer que los proyectos fracasen, ya que los ejecutivos crearán un compromiso basándose en esa estimación.

Además, a la hora de realizar una estimación, no hay que olvidarse de contemplar un plazo de tiempo suficiente para los requerimientos y el diseño. De hecho, debes recordar que, en la mayoría de los casos, los desarrolladores (quienes realizan la estimación) tienden a subestimar los esfuerzos necesarios de un 20% a un 30%. Por lo tanto, lo primero que tienes que hacer es empezar a sobreestimar un poco.

La mayoría de los ejecutivos temen que, si el proyecto se sobreestima, los desarrolladores encuentren algo que hacer con el tiempo libre (la ley de Parkinson) o posterguen mucho el trabajo y tengan que hacerlo a las apuradas a último momento (el síndrome del estudiante). El deseo de evitar esas situaciones los lleva a reducir la estimación aún más. Sin embargo, como mencionamos antes, los desarrolladores suelen crear cronogramas demasiado optimistas (esto fue especialmente resaltado por Chris Peters, el empleado N° 105 de Microsoft). Por eso, si eres un ejecutivo, no le temas a la estimación que estás recibiendo del equipo de desarrollo, y no la reduzcas aún más.

Además, recuerda que, cuando un proyecto se demora, pueden surgir algunas situaciones que retrasen aún más todo el proceso, como reuniones con los gerentes, pedidos de disculpas a los clientes, lanzamientos internos para el soporte de los demos de los clientes, o la resolución de problemas resultantes de hotfixes improvisados. Todas estas cuestiones no deberían surgir si el proyecto se desarrolla a tiempo o si está cerca de alcanzar su objetivo. Por otra parte, en el caso de proyectos de gran extensión, existen menos probabilidades de terminarlos a tiempo debido a que incluyen muchas actividades extra, las cuales mencionaremos más adelante.

En conclusión, te recomendamos que siempre intentes evitar sobreestimar o subestimar proyectos. Sin embargo, si no puedes realizar la estimación con total exactitud, asegúrate de que tu proceso tienda hacia la sobreestimación, ya que las consecuencias (como la ley de Parkinson o el síndrome del estudiante) no son tan severas como las consecuencias de la subestimación (por ejemplo, un exceso del presupuesto).

El Cono de Incertidumbre

A medida que las personas toman decisiones durante la ejecución de un proyecto, la incertidumbre de la estimación empieza a descender. Este fenómeno llevó a los investigadores a descubrir ciertas etapas en las cuales el nivel de incertidumbre es predecible. El cono de incertidumbre representa esas etapas como los casos de mejor exactitud. Es decir que, aunque existe la posibilidad de un escenario peor, no se puede ser más exacto. Lo que sí puedes hacer es forzar la reducción del cono eliminando variables de tu proyecto (lo que el proyecto ofrecerá, y lo que no).

El cono de incertidumbre. Fuente: http://www.agilenutshell.com/cone_of_uncertainty

Conceptualización inicial (0.25x – 4x) o (-75% a +300%)
Definición del producto aprobado (0.5x – 2x) o (-50% a +100%)
Análisis de requerimientos completo (0.67x – 1.5x) o (-33% a +50%)
Diseño de interfaz de usuario completo (0.8x – 1.25x) o (-20% a +25%)
Diseño detallado completo (0.9x – 1.10x) o (-10% a +10%)
Software completo

Las organizaciones que se dedican al desarrollo de software suelen sabotear sus propios proyectos haciendo compromisos en etapas tempranas del cono de incertidumbre. Por ejemplo, si la compañía se compromete en la etapa de definición del producto, esto implicaría un factor de error de 2x, algo imposible de manejar para un gestor de proyectos. Por lo tanto, se deben postergar los compromisos lo más posible hasta la parte más ancha del cono.
Además, tienes que recordar que los costos y el cronograma deberán ser estimados en base a cada nuevo requerimiento que se haga. A medida que se agreguen nuevos requerimientos y se revisen los antiguos, la estimación de los costos y el cronograma deberán ser modificados para reflejar esos cambios.

Causas de errores de estimación

Estas son algunas de las causas de errores de estimación más comunes:

Información imprecisa sobre el proyecto. Hasta que no entiendas cada funcionalidad específica en detalle, no serás capaz de estimar con exactitud el costo de un proyecto. No es posible estimar la cantidad de trabajo que será necesaria para llevar a cabo algo que no ha sido definido. Por lo tanto, debes intentar obtener tanta información como sea posible del cliente y de las partes interesadas. Puedes preparar una lista de preguntas para que respondan en la próxima reunión o, en el peor de los casos, enviarles un mail.
Información imprecisa sobre las habilidades del equipo. Esto está relacionado con prácticas deficientes de codificación, lo cual puede tener como consecuencia la necesidad de corregir errores, un diseño mediocre que conlleve errores en el código, requerimientos que no fueron bien investigados al inicio del proyecto, o el abandono de la planificación ante la presión. En resumen, si no tienes (suficiente) información acerca del equipo, es muy difícil ofrecer una estimación exacta, ya que no eres consciente de las falencias técnicas que pueden llegar a haber.
Demasiado caos en el proyecto. La incertidumbre sólo se reduce cuando tomas decisiones que eliminen la variabilidad. Diseñar la interfaz de usuario, completar el flujo de la aplicación, y definir el backlog son algunas de las actividades que ayudan a reducir el riesgo de variabilidad que surge de la interpretación errónea de los requerimientos. Si no se controla bien el proyecto, o si los estimadores no están bien capacitados, las estimaciones pueden fracasar. Tienes que recordar que las estimaciones deben reducirse durante el proceso de desarrollo del proyecto.
Imprecisiones que resultan del proceso de estimación. La exactitud de la estimación del proyecto de software depende del nivel de perfeccionamiento de la definición del software. La única manera de reducir la variabilidad de la estimación es reducir la variabilidad del proyecto. Hay muchas variables que solemos olvidar cuando hacemos una estimación, por ejemplo, los casos de desarrolladores que se suman o dejan el equipo, los días de vacaciones o de licencia por enfermedad, etc. Estas variables pueden tener un gran impacto en el caso de los proyectos extensos, por lo que debes tenerlas en cuenta.
Precisión injustificada. La mayoría de la gente tiende a creer que exactitud y precisión son sinónimos. Sin embargo, a los efectos de la estimación de proyectos, son conceptos diferentes. “Exactitud” se refiere a qué tan cerca está un número del valor real, mientras que “precisión” se refiere a qué tan puntual es un número. Por ejemplo, una estimación que dice que necesitarás 341,8 días es precisa pero no muy exacta. Sin embargo, una estimación que dice que se necesitarán 3 personas trabajando full-time durante un año no es muy precisa pero podría ser exacta.

Actividades omitidas

Ya hemos mencionado que varios estudios demuestran que los desarrolladores tienden a hacer subestimaciones de proyectos la mayoría del tiempo. Uno de los factores más relevantes de dichos estudios es que los desarrolladores suelen olvidar entre el 20% y el 30% de las tareas necesarias (ya sea que estas estén o no relacionadas con el software). Entre esas tareas, Steve McConnell resalta las siguientes:

Requerimientos. En esta categoría podemos mencionar los programas de configuración/instalación, el código de integración para usar software de terceros o de código abierto, los modos de implementación, las interfaces con sistemas externos, la portabilidad, la seguridad, la usabilidad, la capacidad de respuesta, el rendimiento, y la capacidad de modificación.
Actividades relacionadas al software. Esta categoría incluye el tiempo que conlleva encontrar nuevos miembros de equipo, la supervisión de los miembros nuevos, la gestión y las reuniones, la implementación, la instalación, la personalización, la clarificación de requerimientos, el mantenimiento del sistema de control de revisión, el respaldo de lo construido, el mantenimiento requerido para ejecutar lo desarrollado diariamente y las pruebas de humo, la creación de data de prueba, la gestión de programas beta de prueba, la participación en revisiones técnicas, el trabajo de integración, el procesamiento y la estimación de pedidos de modificaciones, la coordinación con subcontratistas, el apoyo técnico, el ajuste del rendimiento, aprender cómo usar herramientas nuevas, la coordinación entre los testers y los desarrolladores, la creación y revisión de la documentación de usuario, los demos para los clientes o usuarios, la interacción con las partes interesadas, la revisión de planes, la estimación, la arquitectura y el diseño.
Otras actividades no relacionadas al software. Las vacaciones, los feriados, los días por enfermedad, las jornadas de capacitación, los fines de semana, las reuniones empresariales y las reuniones departamentales, la instalación y el mantenimiento del hardware y software, y los problemas que puedan surgir con estos.

Estas actividades, que no están relacionadas al software, pueden ser excluidas de la estimación cuando se trata de proyectos pequeños, pero son de suma importancia en los proyectos largos. No tener en cuenta este tipo de actividades puede resultar en un cronograma ajustado, el cual creará mucha presión a medida que se acerca la fecha de entrega.

Además, los desarrolladores tienden a cometer más errores cuando están estresados, lo cual suele ocurrir como consecuencia de un cronograma ajustado. Este último aspecto es causado por correcciones rápidas y desprolijas que se realizan al proyecto para evitar perder tiempo en pensar en soluciones apropiadas. La presión de la fecha de entrega es el más grande enemigo del desarrollo de software. A su vez, los cronogramas excesivos o irracionales son la influencia más destructiva en el mundo del software.

Estimación por camisetas

Como hemos señalado, los ejecutivos quieren tomar decisiones sobre el alcance del proyecto, y eso suele ocurrir durante las primeras etapas del Cono de Incertidumbre. Un buen estimador no va a acceder a ofrecer una estimación demasiado exacta, ya que tiene claro que la única manera de proceder es a través de una estimación de alto nivel. En este contexto, los ejecutivos o las partes interesadas piden una clasificación de las funcionalidades para organizarlas según un criterio de costo/beneficio.

Un método muy útil es el de estimación por talle de camisetas, que resulta conveniente en estos casos. Los desarrolladores tienen que clasificar cada funcionalidad en talles de camisetas (es decir, small, medium, large y extra large). A su vez, las partes interesadas deben clasificar las funcionalidades según su valor empresarial en base a la misma escala. Este proceso tendrá como resultado aportes combinados en ambos aspectos.

Ejemplo de estimación en base al enfoque de talles de camisetas

La clasificación en base a talles de camisetas es increíblemente útil, ya que deja en claro qué conjunto de funcionalidades ofrece más valor al producto por el menor costo. Por ejemplo, echa un vistazo a la tabla. A primera vista, el interesado podría creer que la Funcionalidad 2 es más sencilla porque tiene menos valor empresarial.

Sin embargo, cuando los desarrolladores suman el costo de desarrollo, es más fácil entender que no se trata de costo justificado y, por lo tanto, se lo puede mover hacia el final de la lista de tareas. Se trata de una técnica de mucha ayuda que puede ser utilizada en la parte ancha del Cono de Incertidumbre para ofrecer información valiosa que facilite la toma de decisiones por parte de la gerencia.

Los beneficios de una estimación exacta

Algunas de las técnicas de estimación más comunes apelan a la intuición, la suposición o la memoria en base a proyectos anteriores. Estas técnicas suelen tener malos resultados. Además, están estrechamente relacionadas con los excesos de presupuesto y con los desvíos del cronograma.

Por otra parte, se suelen obtener mejores resultados cuando basas tus estimaciones en información histórica. Entonces, si no has estado registrando información sobre tus proyectos anteriores, deberías empezar ya mismo, incluso si comienzas sólo con información sobre la cantidad de líneas de código que escribes por proyecto. Estos son algunos de los beneficios que esto te traerá:

Visibilidad del estatus mejorada: Es una excelente manera de supervisar tu progreso y de ver si todo fluye según el plan. Comparar la estimación con el avance real es muy importante, ya que nos permite ver qué tan realista fue nuestra planificación. Por ejemplo, si eres consciente de cuántas historias de usuario están terminadas, y cuánto esfuerzo fue necesario para terminarlas, puedes predecir cuánto trabajo queda por hacer con sólo echar un vistazo al backlog.
Mejor calidad: Alrededor del 40% de los errores de software son causados por el estrés. Cuando los desarrolladores sufren estrés, se suelen reportar aproximadamente 4 veces más problemas en comparación a un proyecto en el que no se encuentran bajo presión extrema.
Mejor presupuestación: Es muy difícil predecir el costo de los proyectos que no tienen estimaciones exactas. La mayoría de los proyectos tienden a fracasar porque los responsables suman recursos para poder terminarlos a tiempo, lo cual genera un exceso del presupuesto. Esta no es una buena manera de ahorrar tiempo, ya que se tienen que crear nuevos canales de comunicación dentro del proyecto, lo cual casi nunca resulta en más tiempo disponible y puede incluso generar retrasos.
Más credibilidad para el equipo de desarrollo: Un equipo que cuenta con buenos estimadores puede aumentar su credibilidad dentro de la organización. Sin embargo, cuando las cosas salen mal, ellos serán los primeros en ser culpados por la organización.

Conclusiones

Durante años ha existido un gran problema con respecto a la comunicación entre aquellos encargados de realizar estimaciones de proyectos (los desarrolladores) y los ejecutivos. Los ejecutivos suelen pedir estimaciones, pero lo que en realidad quieren es un plan para alcanzar ciertos objetivos. Esto es algo que los estimadores no suelen tener en cuenta a la hora de preparar la estimación. Por lo tanto, el primer paso para reducir la brecha de comunicación es saber diferenciar entre estimaciones, objetivos y compromisos.

Una estimación es una herramienta que ayuda a los líderes a preparar un plan para alcanzar un determinado objetivo. Una vez que el plan está listo, se lo podemos presentar a los ejecutivos para que ellos puedan hacer un compromiso. Puedes negociar el compromiso, pero no la estimación.

Además, hay muchas cuestiones que pueden generar errores en las estimaciones, como actividades omitidas, o falta de información (o información imprecisa) sobre las funcionalidades o el equipo, que tenemos que intentar recordar y evitar. También debemos ser conscientes de la etapa en la que se encuentra el proyecto en el cono de incertidumbre, para así saber si es posible comprometernos o no.

Un aspecto final muy importante es que las estimaciones siempre deben basarse en información histórica para que sean más exactas. En este sentido, durante un proyecto, debes asegurarte de que tus premisas de base sean siempre verdaderas (o tengan una baja probabilidad de cambiar). Por ejemplo, si empiezas a trabajar en un proyecto para una aplicación móvil asumiendo que los usuarios se registrarán a través de Facebook, pero al final utilizas el método email/contraseña, esto puede tener efectos adversos. En cuanto a la estimación, si estimaste el proyecto con una exactitud de +-5%, pero cambió en un 100%, entonces no te va a aportar mucho valor.

Estamos analizando apenas los aspectos más superficiales del concepto de estimación. Hay mucho más por aprender, experimentar y aplicar. Pero el objetivo de este artículo es ofrecerte las mejores prácticas y consejos en relación a la estimación y a los beneficios de una buena estimación. Finalmente, recuerda no usar precisión y exactitud como sinónimos en el contexto de la estimación de proyectos. Siempre es mejor ofrecer fechas exactas en lugar de precisas.