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.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
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