http://metaeuforias.es/desarrollar-s...-una-pelicula/
Don Quijote de Nicaragua.
Elder Soto.

Interesante el articulo, aunque sigue la linea de varias analogias tratando
de justificar el desarrollo de software de la manera "administrativa
tradicionalista". Esto es, enfocar al desarrollo de software con la
continuidad de procesos, y otorgando mayor peso a las tipicas cabezas de la
piramide administrativa, y dejando relegados a los productores del mismo
software como una "innecesidad", esto es, como el unico elemento
intercambiable y de mayor versatilidad.

Personalmente, creo que estos modelos de desarrollo, tratando de generar
analogias con otras industrias, o procesos (Mas alla del articulo que lo
compara con hacer una pelicula), como la de procesos industriales, con
controles y supervision a alta escala, son totalmente desacertados. Si no,
veamos los fracasos constantes que tienen los proyectos de software, y muy
pocos, casi por azar, llegan a buen puerto.

Pienso que los proyectos de software comenzarán a tener mayor existo cuando
el enfoque de pesos cambie de la administracion tradicionalista, y se
considere al desarrollo de software como una nueva forma de administrar
proyectos. O sea, hasta ahora, solo se han intentado mudas los procesos
industriales a una meteria que tiene no mas de 40 años funcionando.

En el momento que se tome conciencia que un software esta compuesto por
lineas de codigo, y no por metricas, creo que en ese momento la
administracion cambiara y los proyectos tendran un mejor resultado.

Ojo, con esto no quiero decir que parte de los procesos aplicados
actualmente deberian dejar de existir, pero el peso de importancia en ese
proceso, esta totalmente fuera de foco. Veo proyectos constantemente donde
tienen mayor importancia el reporte de horas, o la creacion de mediciones,
que el resultado del proyecto en si. Como resultado, proyectos desgastantes,
codigo ineficiente, tiempos de desarrollos casi infinitos, rotacion de
personal constante, y un largo etc. Obteniendo, proyectos cancelados,
tiempos sobre valuados, costos elevados sin sentido, y una calidad pobre.
Aunque, en la recoleccion de mediciones, se diga lo contrario.

Para dar un ejemplo final, despues de pasar por cientos de procesos de
testeo de producto, este deja de arrojar errores, entonces, se considera que
la calidad del mismo es elevada, aunque, internamente, el codigo solo
contiene un parche tras otro, para subsanar estos errores, en definitiva, es
como tener un auto recien salido de fabrica, pero que tiene capas y capas de
pintura arriba para tapar los constantes errores de calculo en las maquinas
que se usaron para producirlo, ya que cortaban mal el material, o hacian
huecos por error donde no debian hacerlo.

Saludos.