Una breve introducción a la estimación software. Recomendaciones y buenas prácticas (4/4)

Enlace al post Estimación software, una breve introducción (3/4)
Para concluir, un conjunto de buenas prácticas útiles a la hora de trabajar con estimaciones:
En un proyecto real no sólo hay que estimar la construcción del software, también hay proveedores de hardware, diseñadores gráficos, entornos de producción, etc. Otro error frecuente es obviar las tareas comunes, como vacaciones, reuniones, informes, etc., aun recuerdo aquel proyecto, de cuya empresa no quiero acordarme, en el que cuando dijimos “creemos que en la estimación hay un error porque no nos salen en el mes tantas jornadas” el comercial contesto “es que he tenido que meter los fines de semana porque no entraba en plazos el proyecto”.
Estimar varias veces durante el proyecto. No basta con estimar al principio, según avanza el proyecto deberíamos reajustar la estimación. Algunos autores señalan que deberíamos estimar al menos en tres puntos: En la etapa de estudio de viabilidad, o inicio del proyecto, en la etapa de requisitos y en la etapa de diseño. Yo incluso creo que en proyectos grandes habría que estimar varias veces según avanza el desarrollo.
El nivel de precisión de la estimación es distinto a medida que avanza el proyecto. Al principio del proyecto, cuando sólo se tienen requisitos, el error con el que se trabaja es mayor que cuando se estima en la fase de diseño. Una figura muy útil para entender esto es el “cono de incertidumbre”, que muestra cómo las estimaciones son más precisas según progresa el proyecto:

Aparte de tamaño y esfuerzo global, hay que estimar fases concretas del ciclo de vida. Si no se tienen históricos, existen fórmulas que dicen cómo se divide en fases el esfuerzo total del proyecto, las más famosas son del ISBSG.
Cada empresa (y muchas veces tipo de proyecto) tiene su método de estimación. No hay un mejor método de estimación… hay uno mejor para cada empresa, y este depende del negocio, del tamaño de la empresa, de su madurez, etc. Por ejemplo, el método de estimación para empresas que desarrollan productos no será seguramente igual que el de empresas que externalizan.
Utilizar varias fuentes y métodos. Complementar siempre el método de estimación con datos de proyectos anteriores (analogía), y realizar comparativas con los mismos. Además, complementar preguntando al equipo de desarrollo.
Usa una unidad de estimación acorde a la fase del proyecto en la que estimas. A la hora de proporcionar una estimación muchas veces es útil valerse de rangos, que se pueden ir ajustando conforme avanza el proyecto. Por ejemplo, “entre la primera y la segunda semana del mes de abril” o “10 meses con más menos quince días de error”. Un error muy frecuente es en la primera estimación decir el día exacto de finalización del proyecto, cuando sabemos que en una estimación tan temprana siempre hay error.
Último consejo. Si os habéis leído los 4 post y habéis llegado hasta aquí, seguro que tenéis serias necesidades de implantar un método de estimación. Así que, si queréis aprender más cosas sobre estimación… apuntaros a este curso online ;- ).