¿Puede considerarse la gestión de proyectos de software como un proceso empírico? Intentar eliminar la complejidad interna, los errores humanos y la variabilidad en los proyectos, es el camino que erróneamente seguimos durante décadas. Pero paradójicamente, sobre estos errores, descansan las bases de —al parecer— nuestra nueva piedra angular: La gestión de software como proceso empírico, como un camino de ensayo y error(…)
Desde la década de 1950 se ha venido buscando la mejor forma de lidiar con el desarrollo del software. Esto se ha hecho mediante tres aproximaciones:
- Eliminando la complejidad interna, buscando trabajar sin programadores.
- Eliminando los errores humanos mediante métodos formales.
- Eliminando la variabilidad de los proyectos.
Todas estas aproximaciones, en general, podemos decir que han fracasado. Cuando se intentó eliminar la complejidad interna, por ejemplo, se llegó a la conclusión de que el software “no es accidentalmente complejo, es esencialmente complejo” [1]. Por tanto la complejidad no está en las personas que desarrollan software, está en el software per se.
Los métodos formales, por otro lado, fracasaron porque “el análisis y el modelado no tienen porqué sustituir a los tests y a las validaciones”. Los errores humanos se dan por defecto al momento de desarrollar software. Cuando escribimos software, escribimos errores.
El último intento, el más reciente, tiene que ver con la estandarización de procesos en el software. Mediante la copia de los modelos industriales y de la ingeniería civil. También está fracasando. Fracasa porque no se tiene en cuenta un elemento determinante: el contexto. Ningún proyecto, por definición, puede ser igual al otro. Por lo que, en ese sentido, ninguna técnica o estrategia aplicada a un proyecto, tiene por qué funcionar en otro.
Estas aproximaciones de solución enumeradas anteriormente, han llevado a que, como ya se conoce, en los últimos 50 años de cada 10 proyectos 8 fracasen significativamente en cuanto a calendario, presupuesto y expectativas de los interesados. Pero… ¿Realmente han fracasado o se ha partido de las premisas incorrectas para medir este fracaso? Es discutible, claro está, pero lo cierto es que ha generado y genera inconvenientes colosales.
¿Qué podemos hacer a este respecto? Los expertos coinciden en que, en lugar de intentar eliminar la complejidad interna, los errores humanos y la variabilidad de los proyectos, debemos Aceptarlas. Debemos asumir que los problemas, en su gran mayoría, son complejos y no deterministas.
Pero este proceso de «aceptación», no puede tener lugar si no viene acompañado del método empírico: observación, hipótesis, análisis de resultados. Esto, por supuesto enmarcado dentro un ciclo iterativo e incremental. En definitiva, dándole más prioridad a la adaptabilidad que a la predictibilidad. Mientras este concepto no esté claro, mucho me temo que las cosas —por más ágiles o tradicionales que se quieran pintar— no cambiarán. ¿O si?
Referencias
[1] Brooks, Frederick. The Mythical Man Month: Essays on Software Engineering.
