h1

Software Estimation: Demystifying the Black Art

02/20/2008

Wizbook [Icon By Buuf]

 Libros: Software Engineering

Cuenta, calcula, juzga. Este es el mantra del libro Software Estimation: Demystifying the Black Art escrito por Steve McConell. En dicho libro encontraremos la teoría tras la estimación de los proyectos de software, incluyendo conceptos básicos como ¿Qué es estimación?, pasando por consejos prácticos para evitar que nos den la vuelta a la hora de presentar un estimado con los ejecutivos o equipo de marketing, hasta los formulazos y tablas de productividad en líneas de código para un proyecto con características puntuales.

Así entonces, McConell nos presenta de forma accesible cómo debemos estimar nuestros proyectos de software: empezando por el hecho que para estimar debemos saber distinguir entre una estimación y un compromiso (algo que por desgracia muchos administradores de proyecto desconocen). Adicionalmente, siempre que encontremos que nuestro calendario no va de acuerdo a los planes del cliente deberemos recalibrar alguno de los componentes del proyecto: costo, calidad o alcance.

Dos puntos llamaron especialmente mi atención. Primero, cómo podemos evitar que nos aprieten si nuestro calendario no sale; segundo, el proceso de estimación mismo.

Cómo aplicar un revire

Con frecuencia me he encontrado en juntas donde después de realizar un estimado del tiempo que nos tomará implementar una funcionalidad, el cliente nos sale con un Híjole, es que esto debe quedar para X fecha. ¿Cómo le hacemos? Obvio que el cliente quiere todo para ayer y no está dispuesto a pagar por los recursos adicionales necesarios para salir en la fecha indicada. El mismo McConell nos presenta un ejemplo y cómo aplicarnos un sombrerito:

Una implicación de la cercana y a veces confusa relación entre estimación y planeación es que los project stakeholders algunas veces comunican de manera errónea dichas actividades. Aquí tenemos un ejemplo de una falla de comunicación típica:

Ejecutivo: ¿Cuánto crees que tomará este proyecto? Necesitamos tener este software listo en 3 meses para un evento. No te puedo dar más recursos, así que tendrás que trabajar con el equipo de trabajo que ya tienes. Aquí está una lista de los requerimientos que necesitaremos.

Líder del proyecto: OK, déjame checar mis números y luego platicamos.

Más tarde…

Líder del proyecto: Hemos estimado que el proyecto tomará 5 meses.

Ejecutivo: ¡Cinco meses! ¿Acaso no me escuchaste? ¡Dije que necesitamos tener este software listo en tres meses para un evento!

En esta interacción, el líder de proyecto probablemente se retire pensando que el ejecutivo es irracional, porque está pidiendo que el equipo realice la entrega de 5 meses de trabajo en 3 meses. Por otro lado, el ejecutivo pensará que el líder no comprende la realidad del negocio, pues no sabe cuán importante es estar listo para el evento en 3 meses.

Nótese en este ejemplo que el ejecutivo en realidad no estaba pidiendo un estimado; estaba pidiendo al líder un plan para alcanzar el objetivo. La mayoría de los ejecutivos no poseen el contexto técnico que les permitiría hacer las distinciones entre estimados, objetivos, compromisos y planes. Por ello es responsabilidad del líder técnico traducir la petición del ejecutivo en términos técnicos más específicos.

Aquí tenemos una forma más efectiva de interacción:

Ejecutivo: ¿Cuánto crees que tomará este proyecto? Necesitamos tener este software listo en 3 meses para un evento. No te puedo dar más recursos, así que tendrás que trabajar con el equipo de trabajo que ya tienes. Aquí está una lista de los requerimientos que necesitaremos.

Líder del proyecto: Déjame ver si entiendo lo que estás pidiendo. ¿Es más importante que entreguemos el 100% de estos requerimientos, o es más importante que tengamos algo listo para el evento?

Ejecutivo: Debemos tener algo listo para el evento. Nos gustaría tener el 100% de los requerimientos si es posible.

Líder del proyecto: Quiero asegurarme de que sigo tus prioridades lo mejor posible. Si resulta que no podemos entregar el 100% de los requerimientos para la fecha del evento, ¿deberíamos estar listos para entregar lo que tenemos en esta fecha o deberíamos planear el proyecto para hacer la entrega una vez pasada esta fecha?

Ejecutivo: Debemos tener algo para el evento, así que si no hay de otra, debemos entregar algo, incluso si no es el 100% de lo que queremos.

Líder del proyecto: OK, más tarde te entrego un plan donde entreguemos tantos requerimientos como sea posible dentro de la restricción de fechas.

Software Estimation by Steve McConnell (Microsoft Press, 2006) and is © 2006 Steve McConnell. All Rights Reserved.

Manejando una conversación y petición de un plan de esta manera es más posible negociar la fecha límite en nuestros términos y evitar el desgaste asociado a "pues no puedo hacerlo a tu manera y me monto en mi burro".

Cómo estimar un proyecto

La parte medular del libro tiene que ver con la estimación en si. A grandes rasgos nos dicen lo siguiente:

  • Siempre que se pueda, hay que contar lo que sea que dé un buen estimado: puntos de función, casos de uso, componentes, líneas de código; si no se tiene algo qué contar, hay que calcular los estimados mediante tablas de productividad, índices de conversión por tipo de proyecto, etcétera. Si no hay forma de hacer alguna de estas dos operaciones, sólo nos queda juzgar lo más objetivamente posible cuánto esfuerzo requiere el proyecto a estimar.
  • En la medida de lo posible, es necesario recalibrar estos conteos mediante información histórica de proyectos parecidos; de menor a mayor exactitud que nos pueden aportar utilizaremos históricos de la industria, históricos de la compañía y finalmente históricos de proyectos similares en la misma compañía.
  • El libro nos ilustra algunas técnicas para estimación en caso de no tener información histórica de nuestros proyectos. Desde estimación por descomposición y recomposición — equivalente a sumar las horas de cada actividad del WBS — pasando por el Análisis de Puntos de Función hasta recomendaciones sobre herramientas de estimación — poniendo especial énfasis en Construx ya que ésta puede descargarse de forma gratuita.
Desktop de la MAC del Jerry
El Proyecto Patito con un esfuerzo estimado en alrededor de 120,000 líneas de código, 81 meses/hombre, duración de 15.5 meses y costo de US$148,650.
[Click en imagen para ver original]

Mi opinión

Siendo honestos, el libro adolece de un punto muy importante: aunque el autor nos da una buena dosis de cátedra sobre la estimación de proyectos de software y nos muestra algunas metodologías, todo lo que proporciona el libro es completamente inservible si no tenemos un punto de referencia a partir del cual realizar nuestros dimensionamientos: si es la primera vez que vamos a generar un proceso de estimación, nuestro porcentaje de error seguirá siendo de 50 – 100% mientras que para alcanzar estimaciones lo más certeras posibles, deberemos reunir al menos dos años de proyectos para empezar a tener resultados convincentes. Esto es algo difícil en el clima actual de la industria, y peor aún si sabemos que muchas iniciativas de calidad como ésta son las primeras en ser eliminadas cuando la empresa tiene dificultades financieras.

Sin embargo, considerando la información del libro en su conjunto, esta lectura es imprescindible para saber cómo reunir a nuestro equipo de expertos y generar nuestros primeros pininos de una metodología de estimación estandarizada.

One comment

  1. Excelente Articulo!



Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: