Interesante artículo traducido al español por Leonardo De Seta (http://www.dosideas.com/noticias/desarrollo-de-software/746-como-determinar-el-costo-y-tiempo-de-un-proyecto.html) donde nos permite tener un panorama más amplio al momento de determinar el costo y tiempo de entrega de un proyecto de desarrollo de software…

Determinar el costo y tiempo de un proyecto de software es uno de los temas más importantes en el desarrollo de software. Mi opinión seguramente va a ser polémica, y acá está: es imposible determinar cuál será el costo y el tiempo de un proyecto de desarrollo de software. Más aún, es muy mala idea intentar usar la planificación como si fuera un contrato con nuestro cliente.

El Triángulo de Hierrro es una muy buena analogía para explicarlo. Lo que muestra el triángulo es que en los proyectos de software (y, básicamente, en cualquier proyecto), asumiendo que la calidad queda estática (los proyectos siempre deberían apuntar a tener la mayor calidad posible), hay otras tres variables en juego: el Tiempo (qué tan rápido queremos entregar la solución), el Costo (que tan barato queremos que sea el producto) y el Alcance (cuántas características queremos que tenga la aplicación). Lo interesante es que estas tres variables dependen entre si, por lo que resulta imposible dar más prioridad a una sin quitarle a las demás.

Lo que hace que sea imposible determinar el costo y el tiempo de un proyecto es que es imposible conocer por completo el alcance de las características de la aplicación desde el iniio, sin importar cuánto análisis y recolección de requerimientos hagamos (dije que iba a ser polémico). Y sin estos datos, ¿cómo vamos a calcular los otros dos lados del triángulo? Incluso cuando el costo es fijo, o el tiempo es fijo, es imposible calcular el otro vértice del triángulo.

Para analizar más, supongamos que estoy equivocado y que realmente podemos determinar el Alcance de la aplicación desde el inicio. Por lo tanto lo estimamos, y supongo que todos estamos de acuerdo en que la estimación tan sólo expresa una probabilidad; cuando digo “estará terminado en un mes”, quiero decir algo como “hay un 80% de probabilidad de que termine en un mes”. Cuando encadenamos las probabilidades (la estimación de cada una de las características que formaban el Alcance), la probabilidad de acertar cae exponencialmente, lo que significa que incluso aunque conozcamos todas las características, la probabilidad combinada de acertar en todas las estimaciones es ridículamente baja.

La planificación continua

La solución al problema es cambiar la perspectiva y mirar a la planificación no como una actividad enorme que se hace al comienzo del proyecto, sino como una actividad continua que se realiza druante toda la vida del proyecto. Mientras más hayamos desarrollado la aplicación, más podremos refinar nuestro plan.

Conclusión

Existe un círculo vicioso: un proyecto de software no se aprueba hasta que se estime el costo y el tiempo, pero esto no se puede determinar porque recién conoceremos el alcance real de las características al momento de empezar a desarrollarlas. Igualmente, esto no debe impedirnos de empezar un proyecto y crear una estimación inicial, y refinarla a medida que desarrollamos el producto. Pero tengan cuidado: crear una planificación inicial y usarla como un contrato va a afectar seriamente a todas las partes involucradas; es probable que el cliente no pueda hacer cambios durante el desarrollo, y el equipo de desarrollo trabajará bajo presión para cumplir fechas, y al terminar el producto final no será lo que el cliente esperaba y su calidad será pobre.

Traducido de : How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront), por Alberto Gutierrez.