Cómo mejorar las estimaciones en tus proyectos de software
“The process is called estimation, not exactimation”.
Esta frase de Phillip Armour, quien es un consultor independiente, prácticamente lo dice todo. A veces pensamos que hacer una estimación implica establecer un dato preciso acerca de cuánto tiempo nos vamos a tardar ejecutando una tarea, cuánto nos va a costar ejecutarla o, inclusive, qué tan compleja es, pero la realidad es ¿quién realmente tiene la capacidad de adivinar lo que sucederá en el futuro? Entonces, ¿por qué pretendemos que los datos que proveemos cuando generamos una estimación sean tan precisos?
“So-called expert judgment is the least accurate means of estimation”[1]
Diferentes estudios han encontrado que las técnicas de estimación que pretenden comparar un proyecto actual con un proyecto pasado, sólo tomando como referencia la experiencia de las personas, son las más usadas (McConnell, 2006). Sin embargo, dichas técnicas de estimación son las menos precisas (McConnell, 2006), ya que se ha encontrado que tienen una alta correlación con las desviaciones de tiempo en los proyectos (McConnell, 2006). Entonces ¿por qué continuamos usándolas?
La ciencia de las estimaciones
Hoy en día, los investigadores dedicados a mejorar las estimaciones de software están enfocados en mejorar las técnicas de estimación que les permitan a las organizaciones obtener resultados en sus proyectos de +-5% de variación con respecto a los resultados de sus estimaciones (McConnell, 2006). Estas técnicas son matemáticamente intensivas y funcionan mejor cuando son combinadas con herramientas de estimación de software.
Ninguna técnica de estimación es perfecta
Debido a que ninguna técnica de estimación es perfecta, usar múltiples enfoques de estimación es de mucha utilidad. Por lo tanto, aquí dejo algunas técnicas de estimación que pueden ayudarte a mejorar tus estimaciones de tiempo sin necesidad de convertirte en un gurú de las matemáticas y la estadística para lograrlo:
Contar, calcular y juzgar
Cómo funciona:
Te dejamos aquí 3 actividades para que practiques estas técnicas:
Actividad 1 - Cuenta
Actividad 2 – Calcula
Actividad 3 – Juzga
1. Sin buscar en Google o consultar cualquier otra fuente, solo usando tu criterio y experiencia previa, indica cuántos cráteres crees que hay en la Luna.
2. Después, busca en Google y encuentra una fuente confiable para determinar cuántos cráteres tiene la Luna.
3. Reflexiona: ¿cuántas veces has tenido que adivinar para estimar en tus proyectos?, ¿cuál es la diferencia en precisión cuando adivinas y cuándo buscas en una fuente confiable?
Estimación análoga
Cómo funciona:
Ejemplo
1. Usando la tabla superior (que representa los datos históricos de esfuerzo para programar formularios en una empresa), determina cuánto esfuerzo te tomaría programar 4 formularios.
2. Si observas la tabla, podrás encontrar un registro que indica que, en el pasado, programar 4 formularios requirió un esfuerzo de 10 horas.
3. Usando una estimación análoga, podríamos decir que ejecutar nuevamente la actividad de programar 4 formularios, requeriría un esfuerzo de 10 horas.
Actividad
1. Usando la tabla del ejemplo anterior, estima el esfuerzo de una actividad que consiste en programar 14 formularios.
2. ¿Qué harías si encuentras en la tabla de registros históricos más de un registro que represente el valor que estás estimando? ¿Sacarías un promedio? ¿Elegirías la cantidad de esfuerzo más alto de los tres registros?
Estimación paramétrica
Cómo funciona:
Ejemplo
Dejamos aquí un ejemplo de esta técnica de estimación. Recomendamos seguirlo al pie de la letra, pero una vez que lo comprendas, intenta cambiar algunos datos para que observes diferentes resultados.
Conclusiones
· Lo mejor que puedes hacer es probar diferentes técnicas de estimación y descubrir los resultados por ti mismo.
· No olvides comparar los resultados de tu estimación con los resultados de tus proyectos.
· Busca y prueba nuevas técnicas de estimación.
· Practica hasta que te conviertas en un experto estimador.
· Para mayor información, te recomendamos descargar este Whitepaper.
[1] Steve McConnell (McConnell, 2006)