Pages Menu
Categories Menu

Posted by on Jun 11, 2013 in General | 2 comments

4 excusas típicas para no tener un método de estimación software

Conocido es desde hace años (te recomiendo aquí aquel post de errores frecuentes en proyectos software) que una de las causas más frecuentes, e impactantes, de fracasar en un proyecto software viene de las malas planificaciones, derivadas principalmente de malas estimaciones.

Aún así, paradójicamente, la estimación software es lo que más suele fallar en proyectos software. En mi caso, después de haber visto seguramente ya más de 70 empresas de software (por cierto, dejo aquí auel post de después de pasar por 56 empresas… 8 experiencias), coincido plenamente: el problema de gestión más repetido viene de la ausencia, o carencia, de estimación.

Cuando suelo preguntar… “¿Por qué no tenéis un método de estimación?” Suelen ser muchas las excusas. Pero hay algunas que siempre se repiten, por lo que le he querido sintetizar aquí las 4 excusas más comunes para no tener un método de estimación software:

1 – “Para que vamos a estimar, si el cliente nos fija plazo y presupuesto”. Que te obliguen a terminar el 15 de febrero, no quita desde el primer día de proyecto tu sepas si eso es realista o que te vas retrasar 6 meses. Si desde el primer día de proyecto sabes que habrá un retraso aproximado de un semestre puedes ir gestionándolo desde mucho antes, minimizando el desastre.

2 – “Para que vamos a estimar, si nosotros llevamos años trabajando en este software y estimamos con nuestra experiencia de años”. Si llevas estimando “a ojo” durante años, y además se te da bien, y aciertas… escribe tu proceso mental de estimación en un papel, y tendrás un método de estimación. ¿Qué para qué? Para que otros puedan aprender de ello y replicarlo sin tu obligada presencia.

3 – “Para que vamos a estimar, si es imposible acertar la fecha exacta de finalización”. El objetivo de una estimación (que no es una “exactimación”) es mostrar un intervalo de finalización, no un día exacto, un intervalo con un error conocido. Ejemplo, “el proyecto terminará durante el mes de febrero”, “el 1 de febrero, con un mas menos error de dos semanas”, etc.

4 – “Para que vamos a estimar, si nosotros usamos un ciclo de vida por Sprint o ágil”. No sé yo dónde viene que siguiendo una metodología ágil no se estima (al igual que tampoco sé donde viene que no se documenta). Hay quien piensa que por usar Sprint (gestionar el proyecto por ventanas de tiempo fijo) no debe estimar, solo debe ir introduciendo requisitos en cada Sprint…

Terminando…

Bueno, y por si lo que te comentaba te ha llegado al alma, y desde ya te quieres poner a estimar, te dejo:

Estimación software, una breve introducción.

Cómo implantar un modelo de estimación software en grandes empresas que subcontratan mucho software.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

2 Comments

  1. Hola Javier,
    ¿Existe alguna referencia bibliográfica importante que intente explicar los diversos métodos existentes? Y, por supuesto, que lo consiga de forma didáctica.

    Un saludo

    • Hola,

      No tiene todos, pero el mejor libro para mi, el más didactico, es el de McConnell, el de Software Estimation: Demystifying the Black Art

      Saludos

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: Conocido es desde hace años (te recomiendo aquí aquel post de errores frecuentes en…

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This