Estimaciones Extremas

25 05 2008

Como muchos sabemos existen reportes donde indican que los proyectos de software casi nunca acaban en el tiempo indicado ni con el presupuesto indicado, es mas sobrepasan estas dos dimensiones.

Pues aunque existen variada razón para que los proyectos se desvíen, las cuales no sera parte de este post, me concentrare en las estimaciones.

Algo que aprendí de un gran amigo, es que las estimaciones que estamos acostumbrados a escuchar o a decir, son estimaciones de punto único, queriendo decir que si se dice que la estimación del proyecto da 90 Horas, con días de trabajo de 9 horas y un solo recurso, pues el proyecto acabara en 10 días. Pues la verdad eso no sucede con tanta linealidad.

Las estimaciones deben ser exactas,mas no precisas. La exactitud puede tener margen de error, mientras la precisión no. Los margenes de error pueden ser controlables si se tienen adecuados procesos y control de los mismos. Indudablemente para poder estimar adecuadamente se debe tener mas información de lo que se va ha realizar. Como se expone en el cono de incertidumbre

 

 

Cono

 

Hay una etapa que no lo indica el cono para los desarrollos de software a la medida, y es la etapa de comercial, donde es el “Vendedor” el realiza la estimación. Esta estimación estará muy sesgada y su margen de error sera superior a los que indica el cono.

Es importante que si es el agente comercial el que realiza la estimación, que el equipo constructor no se deje intimidar por dicho tiempo, y realice la tarea de reestimación, para poder saber cual es el desfase esperado. La reestimación es un ejercicio que se debe llevar a cabo durante la ejecución del proyecto, dado cada vez que se avanza se tiene mayores niveles de certidumbre del proyecto dando lugar a mejores estimaciones.

Las estimaciones extremas se pueden hacer, y son aquellas donde se conoce poco del proyecto y se da el esfuerzo requerido para llevarlo acabo, sin embargo el riesgo es mejor valorarlo, para ver si el negocio es rentable.


Acciones

Información

Un comentario

27 05 2008
Jorge Suarez

Cada vez me doy cuenta mas que en estimacion de software, “EL TAMAÑO SI IMPORTA”. Dejando a un lado los compromisos establecidos por los agentes comerciales que venden (o comprometen?) a un equipo de desarrollo para realizar un proyecto en determinada fecha, el tamaño del proyecto es algo invariable; el detalle del conocimiento de la dimension de lo que se va a realizar es directamente proporcional a la certidumbre que se gana a medida que se avanza en el cono, o mas bien es a la inversa, a medida que se gana detalle de la dimension del proyecto de software se avanza mas en el cono reduciendo la incertidumbre.

Ahora, que hacer cuando existen metas plasmadas en un calendario? Dado que el tamaño del proyecto de software no varia, solamente quedan las opciones de:

1. Reducir el alcance del proyecto para cumplir con la fecha establecida con el staff disponible.

2. Ampliar el staff disponible y realizar la planeacion del proyecto paralelizando al maximo.

De nuevo: lo mas importante de todo es culturizar al cliente en el concepto del tamaño.

Deja un comentario