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 ;- ).

Javier Garzás

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

  1. Excelentes posts y muy bueno su curso que tuve la oportunidad de tomar, sin duda la estimación es todo un arte, faltan riesgos en el proyecto a estimar, hay muchas funcionalidades dificiles de estimar, el modelo de estimación sirve muy bien para nuevos proyectos pero no para mantenimiento, la empresa ha cambiado mucho y ahora los historicos no reflejan la realidad, etc etc.↲sin duda es algo muy dificil donde la tecnologia avanza a pasos agigantados y las tecnicas de estimacion de tamaño ya se estan quedando cortas y esto hace aun mas dificil estimar. Espero encuentren el metodo que mas se adapte a sus necesidades, mientras tanto, paciencia, mucha paciencia y por favor hagan mucho caso a los post y de ser posible tomen el curso de kybele, les sera de mucha utilidad.↲saludos y disculpen las faltas ortograficas, pero escribi a media conferencia desde mi movil.

  2. Pingback: Bitacoras.com

  3. Buen resumen/introducción de la estimación software más clásica. Me ha extrañado que no hayas comentado nada sobre estimación y planificación Agile.
    Permíteme contribuir con otra buena práctica: involucra a todo el equipo en la estimación o al menos a buena parte.

  4. Exactamente como dice Julio, si el project manager hace la estimación solo en su oficina es más probable que cometa errores o subestime tiempos. Lo mejor siempre es incluir a un experto del equipo, o al menos el que tenga experiencia en la tecnología que se va a utilizar. (recien leo el post, espero que sigan vivos todos! jajaja)
    Saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ir arriba