¿Desarrollo Agile o desarrollo Waterfall? Por Breogán Gonda

¿Por qué se me ocurre, ahora, hablar de esto? Porque he bajado de Amazon y leído el libro: “Why Agile is Failing at Large Companies” de Ms. Geri Schneider Winters. Mi primer pensamiento: “otro libro que trata de demostrar que las cosas no se pueden hacer, que los cambios no son posibles”. Con todo cuidado y respeto, me dije: leer a los que piensan como yo, puede ser placentero, aunque probablemente sea inútil, leer a los que piensan diferente siempre es útil.

La lectura fue gratificante: el libro estudia profunda y seriamente el tema. En lugar de poner el énfasis en la imposibilidad, (como yo suponía al leer el título), nos insta a aplicar el paradigma Agile de manera responsable, sólida, mesurada, tomando en cuenta todos los elementos necesarios para obtener el éxito. Pero no hablaré más de esto aquí: ¡recomiendo sinceramente la lectura del libro!

Paradigma Waterfall

El paradigma Waterfall implica un análisis monolítico, muy profundo y detallado del problema a resolver y la resolución total del mismo a nivel del proyecto, para pasar luego a su implementación.  ¿Funciona? Pone el énfasis en la previsibilidad (costos en dinero y tiempo) e, idealmente, todo funciona  bien, sujeto a que el proyecto original se ajuste a la realidad, no contenga errores importantes y que esa realidad no cambie mucho durante el proyecto.

Este paradigma fue pensando para otras circunstancias, donde el tamaño de los sistemas y, sobre todo, la velocidad de los cambios, eran mucho menores que hoy.

A principios de los 80 comenzamos a ser requeridos para la implementación de grandes sistemas corporativos e, inmediatamente, enfrentamos dificultades importantes, las que íbamos superando con esfuerzo, pero cada vez más convencidos de que el paradigma que estábamos utilizando no era adecuado.

En mi caso, en 1984, apareció una gran empresa brasileña que necesitaba un sistema corporativo basado en una única gran base de datos central alrededor de la cual todo debía construirse. Luego del primer análisis se vio que se trataría de una base de datos de, por lo menos, 500 entidades  y nos quedó claro que enfrentarlo con el tradicional paradigma Waterfall nos llevaría al fracaso. También nos fue claro que no disponíamos de un paradigma alternativo, por lo que comenzamos a investigar, buscando nuevas soluciones.

Paradigma Agile

Mucha gente tuvo, más temprano o más tarde, problemas parecidos. Todos nos hicimos, probablemente, la misma pregunta: con Waterfall priorizamos la previsibilidad de los costos pero ¿Qué ocurre con la calidad del producto?, ¿cómo los sistemas obtenidos se ajustan a las necesidades reales?, ¿cómo seguimos para mantenerlos válidos y actualizados a través del tiempo?, ¿es razonable pensar que los costos (dinero y tiempo) serán menores que en Agile?: ¡en la práctica suelen resultar mucho mayores!

El paradigma Agile tiende a un desarrollo incremental. ¿Cómo lo caracterizamos? Por una interacción permanente, por el involucramiento de los usuarios, por la prototipación oportuna. Con el debido nivel de abstracción, todo esto lo podemos resumir conceptualmente en: “feedback”.
¿Con qué problemas fundamentales nos encontramos en el Paradigma Agile? A medida que se avanza se van encontrando situaciones que no estaban previstas. Cuando debemos modificar o agregar procesos para tratar los mismos datos, eso se hace con facilidad. Pero todo es muy diferente cuando se necesitan modificaciones estructurales en la Base de Datos: el nivel de independencia entre datos y programas que nos proporcionan los DBMS es rudimentario y, por ello, cuando hay cambios importantes en las estructuras de los datos, se necesita realizar un conjunto de complejas operaciones como, por ejemplo, determinar que programas seguirán siendo correctos y cuales deberán ser modificados, lo cual tiene importantes costos en tiempo,  dinero y riesgo de errores.

 ¿No ocurre lo mismo en el paradigma Waterfall? Desde luego, pero Waterfall está pensado para situaciones de estabilidad, donde poco o nada cambiará.

La necesidad de modificaciones estructurales en la Base de Datos

¿Fatalmente debemos caer en este problema?, ¿no existe una manera de resolverlo automáticamente?
Ha habido muchos intentos: por ejemplo, a fines de la década de los 70, ANSI-SPARC emitió una recomendación tendiente a viabilizar la independencia entre datos y programas. Luego Cincom Systems lanzó un DBMS (SUPRA), que obedecía razonablemente a esa recomendación. Posteriormente Microsoft en su Framework.net, incluyó un mecanismo (Datasets / Dataviews) con el mismo objetivo. Por diferentes razones, estas iniciativas no prosperaron.

En 1985 y como resultado de investigaciones propias, concluimos que la mejor manera de resolver el problema era aumentar el nivel de abstracción  y pasar a trabajar con el conocimiento puro.

Con el tiempo hemos conseguido una muy buena administración automática de conocimiento de los sistemas de negocios que nos permite, como subproductos, la automatización de:

- Proyecto, generación, mantenimiento y reorganización de la Base de datos.
- Proyecto generación y mantenimiento de los programas.
Todo esto lo hemos concretado en nuestro producto GeneXus, vastamente utilizado en más de  45 países, fundamentalmente en sistemas de misión crítica, en empresas de todo tipo.

RESUMEN:

El paradigma Whaterfall ha quedado obsoleto, pero sigue existiendo porque casi todos los sistemas legacy lo usan.
No es razonable encarar hoy sistemas nuevos con el paradigma Waterfall.
El paradigma Agile ofrece claras ventajas para las nuevas aplicaciones.
El uso de tecnología que permita una muy buena independencia entre datos y programas, de manera de viabilizar un verdadero desarrollo incremental, ayuda mucho.

 * Breogán Gonda es Ingeniero en Computación, Investigador, Docente, Consultor, y Presidente del Directorio de GeneXus S.A., empresa dedicada a construir herramientas de software basadas en procesamiento automático del conocimiento.