Para definir qué es el agilismo, probablemente basten un par de líneas. Ya veremos más adelante, en este mismo capítulo, que el concepto es realmente simple y queda plasmado en cuatro postulados muy sencillos. Pero creo que llegar a comprenderlo requiere un poco más de esfuerzo y, seguramente, la mejor manera sea haciendo un repaso a la historia del desarrollo de software, para al final ver como el agilismo no es más que una respuesta lógica a los problemas que la evolución social y tecnológica han ido planteando.
Ya desde el punto de partida es necesario hacer una reflexión. Al otear la historia nos damos cuenta de que el origen del desarrollo de software está a unas pocas décadas de nosotros. Para llegar al momento en el que el primer computador que almacenaba programas digitalmente corrió exitosamente su primer programa, sólo tenemos que remontarnos al verano de 1948. Esto nos hace reflexionar sobre el hecho de que nos encontramos ante una disciplina que es apenas una recién nacida frente a otras centenarias con una base de conocimiento sólida y estable. Por nuestra propia naturaleza nos oponemos al cambio, pero debemos entender que casi no ha transcurrido tiempo como para que exijamos estabilidad.
Siguiendo la ley de Moore, los componentes hardware acaban duplicando su capacidad cada año. Con lo que, en muy poco tiempo, aparecen máquinas muy potentes capaces de procesar miles de millones de operaciones en segundos. A la vez, los computadores van reduciendo su tamaño considerablemente, se reducen los costes de producción del hardware ya avanzan las comunicaciones entre los sistemas. Todo esto tiene una consecuencia evidente: los computadores ya no sólo se encuentran en ámbitos muy restringidos, como el militar o el científico.
Al extenderse el ámbito de aplicación del hardware (ordenadores personales, juegos, relojes, ...), se ofrecen soluciones a sistemas cada vez más complejos y se plantean nuevas necesidades a una velocidad vertiginosa que implican a los desarrolladores de Software. Sin información y conocimiento suficiente, unos pocos aventureros empiezan a desarrollar las primeras aplicaciones que dan respuesta a las nuevas necesidades pero es un reto muy complejo que no llega a ser resuelto con la inmediatez y la precisión necesarias. Los proyectos no llegan a buen puerto, o lo hacen muy tarde.
En la década de los cincuenta nos encontramos con otro hito importante. En el ámbito militar, surge la necesidad de profesionalizar la gestión de proyectos para poder abordar el desarrollo de complejos sistemas que requerían coordinar el trabajo conjunto de equipos y disciplinas diferentes en la construcción de sistemas únicos. Posteriormente, la industria del automóvil siguió estos pasos. Esta nueva disciplina se basa en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles.
Hasta este punto, hemos hablado sólo de desarrollo de software y no de ingeniería de software, ya que es en 1968 cuando se acuña este término en la NATO Software Engineering Conference.En esta conferencia también se acuña el término crisis del software para definir los problemas que estaban surgiendo en el desarrollo y que hemos comentado anteriormente.
Los esfuerzos realizados producen tres áreas de conocimiento que se revelaron como estratégicas para hacer frente a la crisis del software:
- Ingeniería del software: este término fue acuñado para definir la necesidad de una disciplina científica que, como ocurre en otras áreas, permita aplicar un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software.
- Gestión Predictiva de proyectos: es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles.
- Producción basada en procesos: se crean modelos de procesos basados en el principio de Pareto, empleado con buenos resultados en la producción industrial. Dicho principio nos indica que la calidad del resultado depende básicamente de la calidad de los procesos.
En este punto, con el breve recorrido hecho, podemos sacar conclusiones reveladoras que luego nos llevarán a la mejor comprensión del agilismo. Por un lado, la gestión predictiva de proyectos establece como criterios de éxito obtener el producto definido en el tiempo previsto y con el coste estimado. Para ello, se asume que el proyecto se desarrolla en un entorno estable y predecible. Por otro, se empiezan a emular modelos industriales e ingenieriles que surgieron en otros ámbitos y con otros desencadenantes.
Debemos tener en cuenta que, al principio, el tiempo de vida de un producto acabado era muy largo; durante este tiempo, generaba beneficios a las empresas, para las que era más rentable este producto que las posibles novedades pero, a partir de los ochenta, esta situación empieza a cambiar. La vida de los productos es cada vez más corta y una vez en el mercado, son novedad apenas unos meses, quedando fuera de él enseguida. Esto obliga a cambiar la filosofía de las empresas, que se deben adaptar a este cambio constante y basar su sistema de producción en la capacidad de ofrecer novedades de forma permanente.
Lo cierto es que ni los productos de software se pueden definir por completo a priori, ni son totalmente predecibles, ni son inmutables. Además, los procesos aplicados a la producción industrial no tienen el mismo efecto que en desarrollo de software, ya que en un caso se aplican sobre máquinas y en otro, sobre personas. Estas particularidades tan características del software no tuvieron cabida en la elaboración del modelo más ampliamente seguido hasta el momento: El modelo en cascada. En el siguiente punto de este capítulo veremos una breve descripción de dicho modelo, para entender su funcionamiento y poder concluir por qué en determinados entornos era preciso un cambio. Como ya comentaba al principio, el objetivo es ver que el agilismo es la respuesta a una necesidad.