Estimando (no practicando la brujería)

Las estimaciones son necesarias, sin duda, para hacer una primera aproximación a la dimensión de la tarea que vamos a realizar. Sea cual sea la indole de esta tarea. Sentada esta base, me interesa comentar cómo se maneja la estimación en el 'mundo real' y que errores tendemos a cometer.

El primer punto a tener en cuenta es que las estimaciones solo son estimaciones. Esto que, a priori, es una perogrullada, se tiende a obviar. Los involucrados en los proyectos, especialmente los roles involucrados en la gestión del proyecto y la relación del cliente, tienden a olvidar esto. Tenemos que entender que cuando un desarrollador da una estimación no conoce muchos de los aspectos que con más fuerza influiran en la duraciona de la tarea, como, por ejemplo, la dificultad técnica. Además estos aspectos son mucho más dificiles de ver cuanto más lejano está el punto de incio de la tarea. Las estimaciones con estimaciones, no contratos. Cuando alguien convierte las estimaciones en contratos esta realizando un acto de brujería no de ingeniería del software. Brujería por que esta confiando en artes adivinatorias y porque esta forzando la voluntad de quien realizo la estimación. Si una estimación no nos gusta solo podemos añadir recursos o recortar características para que se ajuste a nuestras necesidades.

Si bien las estimaciones no son compromisos, solo estimaciones, todos hemos vivido situaciones, en las que se manejan como tales. ¡Hay incluso empresas que miden a sus desarrolladores por como de buenos son cumpliendo sus estimaciones!. Y lo que es peor aun ¡hay empresas que solo valoran este aspecto del trabajo!. No creo que no sea un aspecto relevante, el problema es que cuando solo se valora un aspecto del desarrollo, los desarrolladores tendemos a optimizar ese aspecto olvidandonos de otros y esto es, en mi opinión, extremadamente dañino para el proyecto. Pero eso es algo de los que hablaré en otro post. Siguiendo con lo que nos ocupa, y teniendo claro, que nuestras estimaciones se tratan a menudo como compromisos, que en nuestra imagen como desarrolladores depende de como de buenos seamos estimando, ¿qué podemos hacer?. La situación no es facil, en muchas ocasiones, ¡te van a valorar por cumplir compromisos establecidos sobre información insuficiente!. Pues bien hay ciertas reglas a la hora de comunicar estimaciones que es interesante seguir:

¡Si te piden una estimación, estima!: No des una estimación a la ligera, nunca. Si alguien te pide una estimación tomate un tiempo, directamente proporcional al tamaño de la tarea a estimar y a cuan lejos se encuentra su inicio, para realizar esta estimación. Es necesario hacer el intento consciente de lograr la mayor información posible sobre lo que estás estimando. Recuerda que tu imagen profesional, desgraciadamente, puede estar en en juego. La respuesta adecuada cuanto te pidan una estimación siempre es 'lo estudio y te comento'.

!Defiende con uñas y dientes tus estimaciones!: ¿Cuantas veces al momento de dar una estimación te la intenta cambiar?. ¿Y cuantas veces tienes que ceder?. Recuerda que ceder en una estimación no sería 'tan importante' pero estás cediendo ¡en un compromiso!, aunque no lo parezca. Para poder mantener una estimación tienes que tener argumentos, y si no has tomado tu tiempo en realizar una estimación argumentada dificilmente la vas a poder mantener.

!No olvides las tareas 'menores'¡: A menudo al estimar olvidamos las tareas menores, sin embargo estas suponen un porcentaje alto del trabajo total del proyecto.

!Recuerda que tendemos a ser optimistas¡: Está estadisticamente demostrado (pag. 168 de Rapid Application Development de Steve Mcconnell si quereís la justificación) que tendemos a ser optimistas en nuestras estimaciones. Debemos recordarlo. En el gráfico adjunto tambien se puede observar como nuestra estimaciones tienden a desviarse más hacia el lado optimista. Si X es lo que hemos estimado al principio del proyecto, lo probable es que el proyecto duré o cueste 4 veces más y solo 0,25 veces menos.

!Las estimaciones se refinan¡: Es necesario, ya que las estimaciones inciales se dan con escasa información ir refinandolas a lo largo del tiempo según vamos avanzando y ganado información sobre el problema inicialmente estimado. No es interesante saber como de buenos somo estimando, sino saber como de buenos somos haciendo que nuestras estimaciones converjan (ver el gráfico adjunto). Cuanto antes converjan, mejor estamos obteniendo la información necesaria para resolver el problema estimado y antes lo completaremos.

En un proximo post hablaré sobre como creo que debemos manejar las estimaciones cuando somos quienes las recibimos, no cuando somos quienes las damos.

Para terminar os dejo algunos recursos interesantes sobre estimación:

El Curso de Gestión de Proyecto de la Universidad de Columbia tiene bastante material sobre estimación.

Steve McConnell tiene un libro (en inglés) de obligatoria lectura:
Software Estimation: Demystifying the Black Art

Además tambien tiene una herramienta gratuita para estimación.