Waterfall vs Agile: ¿qué es mejor?

Waterfall vs Agile: gestión tradicional contra gestión ágil

Cuando en su momento te hablé sobre qué es agile, lo primero que comenté sobre esta filosofía fue que resulta menos burocrática y rígida para crear software, en oposición a los modelos tradicionales (modelos predictivos) de gestión y desarrollo de software. Modelos waterfall, para entendernos. 

Partiendo de esto, puede resultar difícil entender la esencia del pensamiento ágil si no lo comparas precisamente con lo que vino a sustituir. Así que para poder profundizar en qué es agile hablemos un poco de qué no es agile.

En este post te contaré algunas cosas de la gestión tradicional de proyectos software y realizaré una comparativa con la gestión ágil: Waterfall vs Agile.

¡Así que adelante!

Gestión tradicional del software

Admitámoslo, el mundo del software siempre ha padecido una crisis de identidad. Se trata de una ciencia tan joven que los profesionales de este mundillo no siempre hemos tenido muy claro a quién debíamos tener como modelo a imitar.

Por esta razón, durante mucho tiempo se pensó que el software debía tratarse como cualquier otro producto manufacturado. Por tanto, la programación, desarrollo de software o como quieras llamar a la actividad profesional de generar software, debía seguir el mismo paradigma de la ingeniería más tradicional.

No me enrollaré hablando del Taylorismo o el Fordismo, ni del lastre que supone nuestra herencia de la Revolución Industrial. Simplemente decir que durante mucho tiempo la creación de software se ha abordado de forma semejante a una cadena de montaje de un producto físico: primero una gente muy sesuda generaba una idea de producto, después otros la analizaban y generaban unos requisitos, después otros creaban un diseño y finalmente el último eslabón de la cadena, los “obreros-programadores”, construían.

Y por medio, estaban los “capataces” (llámales jefes de equipo, jefes de proyecto, managers, o como te apetezca) haciendo planes y vigilando que se cumpliesen plazos y costes y que el personal cumpliese con su trabajo.

Cadena de montaje
Cadena de montaje de las de toda la vida

El Modelo Waterfall

Como ya habrás deducido acabo de resumir el famoso Modelo en Cascada o Waterfall de creación de software. Este modelo quizá es el que mejor representa la gestión tradicional (o predictiva) de proyectos. Así que en este post, si me permites, utilizaré el término waterfall como sinónimo de gestión tradicional de proyectos software.

Bajo este modelo, el software debía tratarse de forma semejante a una lavadora, un coche o cualquier otro producto industrial, de tal manera que se van abordando fases de forma secuencial y hasta que no se remata una fase no comenzamos la siguiente.

¡¡Si la informática o Tecnología de la Información o como porras la quieras llamar era ingeniería, debía comportarse como tal!!

Hasta no hace tantos años en las facultades y escuelas técnicas de informática éste era el modelo típico de gestión y desarrollo de software y a nadie se le ocurría cuestionarlo.

Y no importaba que, cuando empezaba uno a llevarlo a la práctica, intuyera que algo no cuadraba, que era demasiado rígido, que el software tiene un noséqué que no se ajusta bien a este modelo… Ahí estaba tu profesor de ingeniería del software para decirte qué sabrás tú, insensato, para cuestionar a los gurús de la gestión del software.

Modelo en Cascada
No es difícil deducir por qué lo llamaron Modelo en Cascada…

Por qué el software no casa bien con el modelo Waterfall

El Modelo Waterfall adolecía y adolece de inconvenientes a la hora de aplicarlo a un desarrollo software. El motivo es que waterfall obvia que el software no puede tratarse como cualquier otro producto manufacturado creado mediante un proceso ingenieril, ya que su naturaleza es per se diferente a la de un objeto físico.

Veamos estos inconvenientes:

Waterfall odia la incertidumbre

Los requisitos que describen la lavadora o el coche tienen que quedar perfectamente definidos y delimitados antes de empezar a poner la primera tuerca, esto es evidente. Hay que crear al principio un plan con total exactitud y a continuación seguirlo sin desviarnos un ápice. Cambiar el plan en mitad de la construcción resultaría sencillamente un varapalo económico. Esta claro, por tanto, que un modelo Waterfall encaja perfectamente con este caso.

En cambio, el software sí es susceptible de sufrir cambios en sus especificaciones durante su creación, con «poco» o apenas impacto económico para el proyecto.

No es ningún trauma que en mitad de un proyecto se puedan meter funcionalidades de mejora o correcciones que hagan del software un producto de mayor calidad.

Al contrario, hay que pensar que dichos cambios mejorarán el resultado final del producto y deberían ser recibidos con entusiasmo, no como un cambio de alcance que viene a trastocar (por no usar otra palabra más fea) nuestro bonito diagrama de Gantt.

Ojo, estoy hablando siempre de mejoras, no decidir en mitad de un proyecto de software de gestión que ahora queremos que sea software para videojuegos. No nos pasemos con los cambios 😉 

Waterfall odia los cambios rápidos

Una obra de ingeniería no es, normalmente ni volátil ni de rápida caducidad. Imagina la construcción de un puente: merece la pena definir perfectamente los requisitos de la obra cueste el tiempo que cueste ya que, una vez construyamos el puente, éste tendrá una vida útil de décadas.

Y en menor medida podemos decir lo mismo de cualquier producto manufacturado. Una lavadora o un secador de pelo serán perfectamente válidos años después de su fabricación.

En cambio, el software es un producto de altísima caducidad. Pasar demasiado tiempo en las primeras fases de análisis simplemente puede provocar que, una vez te pongas manos a la obra, estés desarrollando un producto que ya nació obsoleto.

Es más, durante todo ese tiempo en el que estás definiendo perfectamente los requisitos de tu software antes de tirar la primera línea de código, puede que tu competencia ya haya empezado a crear software sin andarse con tantos remilgos. Y esto, en un mundo tecnológico que se mueve tan rápido, puede suponer que te quedes fuera de mercado.

Waterfall odia la ambigüedad

Un producto manufacturado parte de la base de qué necesidad pretende cubrir al potencial cliente y los requisitos normalmente varían poco con el tiempo. Es decir, tras el proceso de análisis de requisitos, no suelen quedar ambigüedades respecto a la funcionalidad del producto ni dicha funcionalidad va a cambiar.

Por ejemplo, volviendo al ejemplo de la lavadora, no es muy probable que en mitad de la cadena de montaje el fabricante decida modificar el programa de centrifugado, entre otras cosas porque desde el principio tendrá clarísimo cuál quiere montar en su lavadora.

En cambio, hay que recordar que la industria del software es industria del conocimiento, con todas las abstracciones que ello implica. Es perfectamente normal que el cliente no tenga nada claras sus necesidades al principio del proyecto y que sea sobre la marcha cuando termina de conformarse en su cabeza qué quiere realmente.

Por tanto, pretender que te proporcione todos sus requerimientos sin ninguna clase de ambigüedad nada más empezar es simplemente iluso. De modo que deberás asumir que vas a comenzar a desarrollar software a partir de unas ideas que sólo el tiempo terminará asentando.

Waterfall divide entre diseño y construcción

En la manufactura de un producto físico existe una diferencia muy clara entre diseño, que es un trabajo intelectual, y construcción, que tiene un fortísimo componente manual. Por tanto, tras el diseño podemos establecer un plan de construcción que no debería desviarse en exceso, dado que la parte de construcción, precisamente por su naturaleza manual y más mecánica, está mucho más acotada y por consiguiente presenta menor grado de incertidumbre.

En cambio, a la hora de construir software, ¿dónde está la frontera que separa el trabajo intelectual de diseño y el trabajo más mecánico de construcción?

De hecho, un diseño muy exhaustivo termina convirtiéndose en una “programación” en pseudocódigo o semejante. Y si por el contrario tu diseño es pobre, será durante la programación donde el desarrollador terminará por completar ese diseño antes de traducirlo a un lenguaje de programación en particular.

En resumen, la propia construcción de software implica diseñarlo, por tanto ¿cómo pretendes planificar a priori la construcción de un producto del que ni siquiera tienes un diseño completo?

Es más, la palabra construcción no puede ser menos aplicable al software. La programación es un proceso intelectual altamente creativo y no tiene nada que ver con el construir un producto cuyas especificaciones otros han pensado previamente. Así que si para ti programar es simplemente generar líneas de código de forma semejantes a hacer tuercas, te pido que lo reconsideres.

Estás exagerando, Waterfall no es tan malo…

No es el objetivo de este post despellejar al pobre modelo Waterfall, así que dejaré las críticas aquí. Mi idea es simplemente ilustrar la rigidez de este modelo en contraste con la naturaleza entrópica del software.

De todas formas, a todas estas conclusiones que acabo de citarte respecto a las carencias del modelo Waterfall ya se llegó hace mucho tiempo. Ya en el año 1968 se hablaba de la Crisis del Software, en relación a la falta de calidad y a las desviaciones en tiempo y costes de los proyectos software. Te aseguro, por tanto, que no se trata de algo reciente ni de manía persecutoria por parte de los agilistas.

La solución que trató de darse fue la que parecía más evidente, pero que en el fondo no hacía más que agravar el problema. Se buscó reforzar la planificación y el control para que las predicciones fueran más fiables, lo que sirvió de poco por las razones que ya hemos hablado.

Cuál sería el enfoque agile

Pues básicamente el contrario al enfoque Waterfall, es decir, desde el pensamiento agile se asume que la naturaleza del software es la que es. Por tanto, deberemos adaptar nuestra forma de gestionarlo a dicha naturaleza y no al contrario, tratar de forzar con calzador la condición del software para que encaje con nuestro método.

Abraza la incertidumbre

Como el software puede cambiar sus requerimientos con poco impacto y, además, es un producto ambiguo difícil de definir desde el principio, partimos con unos requisitos básicos que no tienen que quedar perfectamente definidos y delimitados antes de empezar a desarrollar y que evolucionarán con el tiempo.

Sencillamente, aceptamos la incertidumbre no como una amenaza, sino como algo natural que enriquece el producto conforme más tiempo pasa.

Parte con un plan básico que iremos readaptando

Partimos de la base de que el software es también un producto de alta caducidad, así que no perdemos demasiado tiempo tratando de diseñar el plan perfecto antes de tirar la primera línea de código.

No somos por tanto predictivos ni deterministas, ya que no tratamos de prever todo el desarrollo del proyecto ni realizamos una planificación completa. Somos empíricos y aprendemos de la experiencia.

Así que trazamos un plan inicial básico y ¡tiramos palante!. Este plan ya iremos adaptándolo según las circunstancias del producto y del proyecto.

Entrega de valor continua

Como no planificamos todo el proyecto desde el principio, no es necesario esperar a tenerlo todo desarrollado para aportar valor al cliente.

Al contrario, cada funcionalidad desarrollada se pondrá a disposición del cliente. No esperamos a tenerlo todo, vamos entregando funcionalidades de forma iterativa e incremental, primero lo más importante y después lo secundario. Por tanto, es imprescindible saber priorizar.

De esta forma, el cliente dispondrá tempranamente de software que, si de da el caso, podría llegar a explotar.

Creamos equipos multidisciplinares y autónomos

No separamos a los que diseñan de los que construyen. Formamos equipos multidisciplinares donde todos, desde el el experto en negocio hasta el tecnólogo colaboran en la definición, la planificación y la construcción del producto.

De esta forma, se recibe feedback continuo por parte de Negocio, lo que evita posibles malentendidos y desviaciones respecto a lo que se espera que se entregue y lo que se está desarrollando.

Waterfall vs Agile: gestión tradicional contra gestión ágil
Waterfall vs Agile: gestión tradicional de software contra la gestión ágil

Pero, ¿es tan malo el Modelo Waterfall?

Voy a romper una pequeña lanza a favor del modelo Waterfall en la gestión y desarrollo de software.

¿Pero cómo, ahora me dices que no es tan malo? 👿 

Verás, es sencillo, cuando tu proyecto requiera ceñirse perfectamente a unos objetivos y éstos estén totalmente establecidos desde el principio sin ningún grado de incertidumbre, no tengas miedo de que la competencia te adelante por la derecha ni tampoco te preocupe la obsolescencia del producto, Waterfall puede ser una solución perfectamente válida a tu proyecto.

¿Tus requisitos iniciales son inamovibles? Waterfall puede serte útil 

Imagínate que trabajas en una empresa donde hay que crear un software que atienda a alguna necesidad regulatoria, típicamente aplicar alguna ley de protección de datos o alguna norma de algún organismo estatal o legislativo. Está claro que ahí tienes los requisitos iniciales perfectamente establecidos y sin posibilidad de que te los cambie el cliente (por lo menos a corto-medio plazo).

Por ejemplo, en el mundo del software bancario es muy común atender a regulatorios del Banco de España que se basan en requisitos que admiten poca duda y cuyas fechas de entrega suelen ser inamovibles.

En ese caso, ¿tiene sentido utilizar algo semejante a Scrum, tal que se entreguen Sprint tras Sprint incrementos del producto total? En absoluto.

Quizá puedas beneficiarte de algunas buenas prácticas como por ejemplo las Daily (ya te explicaré más adelante qué significan), pero en general se tratará de un producto que encajará bien con una forma de trabajo predictiva ya que dudo mucho que el Banco de España te admita un Producto Mínimo Viable: o le entregas el producto al 100% terminado, hasta el más mínimo requisito, o te caerá un multazo de aupa.

Por otro lado, la construcción de hardware y en general de cualquier producto físico, sí se adapta bien a un modelo predictivo como el Waterfall. Piensa que en mitad de la construcción de un producto de estas características tenemos poco margen para la modificación sin que resulte en un impacto económico grave. Por tanto, más te vale tener todos los requisitos del producto perfectamente definidos antes de comenzar con la fabricación.

A veces preferimos un mal plan al que aferrarnos…

Para finalizar mi alegato a favor del Modelo Waterfall, me gustaría incidir en una cuestión psicológica: mucha veces las personas prefieren certeza ineficaz a incertidumbre eficaz.

¿Qué quiero decir con esto? Que no todas las organizaciones están preparadas para abrazar la incertidumbre; les tranquiliza comenzar los proyectos con un buen diagrama de Gantt y con la ilusión de que todo irá conforme al plan preestablecido. Y si las cosas no salen como se planeó en un principio, tratará de readaptarse el plan a la realidad (o la realidad al plan mediante un sobreesfuerzo) y se asumirá dicha desviación como algo inherente a la construcción de software.

Tratar de hacer planes lo más detallados posible y a partir de ahí comenzar a caminar es algo muy humano, de modo que no siempre es posible, ni recomendable, imponer un cambio de paradigma tan radical como supone el agile.

Reflexión final

Quizá todo esto que has leído de la gestión waterfall vs agile te choque un poco. No me extraña, a mí me pasó igual.

Estamos tan acostumbrados a tratar de definir planes que el enfoque agile puede parecer que nos lleva a la deriva, a tú lánzate a la piscina y ya se verá. De modo que entiendo perfectamente tu escepticismo.

No te preocupes, es un cambio de paradigma muy profundo, así que es lógico que tengas esas reservas. En este blog te llevaré de la mano por la senda de la agilidad y verás como, poco a poco, todo irá encajando.

Por otra parte, no caigas en el fanatismo agile. Soy un convencido defensor de la gestión ágil, pero antes de aplicarlo en tu proyecto o empresa piensa si tiene sentido implantarlo en función de tus circunstancias, idiosincrasia, cultura corporativa y necesidades.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario