archivo

Archivos diarios: noviembre 11, 2011

Cuanto mayor sea el número e importancia de variables conocidas para poder realizar una estimación de costes y tiempo menos desviación existirá con respecto a los datos reales.

Esta máxima podemos considerarla como válida para cualquier tipo de proyecto en cualquier ámbito.

Sin embargo hay que tener en cuenta que nunca se tendrá suficiente conocimiento para realizar una estimación sin riesgo (salvo que la hagas a posteriori, en cuyo caso no estaríamos hablando de una estimación sino de un conteo de horas) y que siempre te tiene que partir de una estimación inicial para realizar la primera tarea del proyecto en la cual no se dispone del mismo conocimiento que cuando ya se tenga más maduro el contacto con el proyecto y su contexto.

Yo soy partidario de la realización de estimaciones parciales, ya que supone menos riesgos para todos, ahora bien, hay que entender que puede darse el caso de que nos pidan una fecha objetivo para tener listas ciertas funcionalidades del proyecto y también es probable que nos soliciten una previsión de esfuerzo para el proyecto, ya que la inversión requiere ser prevista a nivel de gestión en la organización y en ambos casos la posibilidad de desviación es evidente, la clave en ambos casos es dar la estimación más objetiva posible con los datos actualmente disponibles, guste o no guste su valor a quien la espera.

Si no le gusta pedirá explicaciones y se le deberá comentar que eso es lo que se necesita para desarrollar el software y que se puede acortar alcance para ajustarlo a lo que quiere y que en el caso de no hacerlo se arriesga a que el producto no tenga el umbral de calidad esperado porque las cosas valen lo que valen.

Y es que los datos del Cutter Consortium son escalofriantes:

– El 62% de los proyectos superan la planificación inicial en más de un 50%.
– El 64% cuesta más del 50% de lo presupuestado.
– El 70% tenía errores críticos tras su lanzamiento.

¿Puede aguantar nuestra industria estos datos? Hasta ahora muchas empresas de desarrollo han ganado mucho dinero con este caos a la misma vez que nuestra profesión se ha desprestigiado.

El manifiesto ágil fue un acto de rebeldía ante esta situación y fue, en mi opinión, el punto de inflexión hacia otro escenario. La aportación de Barry Boehm, muchos años antes, con la publicación de su libro “Software Engineering Economics” asociando conceptos asociados a la economía al desarrollo de software, también me parece decisiva.

Pese a esto, se tardará todavía mucho tiempo en superar la crisis del software porque supone un cambio absoluto en la cultura de los desarrolladores y de las empresas.