fbpx

Agile o Waterfall, ¿qué debemos elegir?

01 Jul 2020

Como parte de la transformación digital de una empresa muchas organizaciones se embarcan también en una transformación agile, adoptando prácticas ágiles en sus departamentos. Suelen emerger de los departamentos de TI donde la agilidad hace años que ha calado, y se aplican tanto al proceso de desarrollo como a la gestión de proyectos, extendiéndose más tarde a otras áreas como las de recursos humanos o negocio. Debido a esta tendencia cada vez es más frecuente encontrarnos con proyectos que quieran ser gestionados de forma ágil, pero ¿es nuestro proyecto candidato a ser un proyecto ágil?

Cuando surge un proyecto debemos hacernos una serie de preguntas que nos permitan determinar qué metodología es la que mejor se adapta a las necesidades del proyecto: ¿el proyecto tiene un alcance cerrado?, ¿está bien definido lo que queremos construir?, ¿es probable que el proyecto sufra cambios con frecuencia?, ¿podemos recoger el feedback del usuario sobre nuestro producto frecuentemente?, ¿estamos dispuestos a asumir cierto riesgo en la construcción?, ¿tenemos un Time to Market ajustado?

En la gestión de proyectos existen dos conceptos fundamentales: el triángulo de hierro y el cono de incertidumbre.

El triángulo de hierro determina que, un proyecto software se ve afectado principalmente por tres variables: alcance, coste y tiempo. Para no comprometer la calidad en un proyecto (cosa que debería ser innegociable) una de las tres variables debería quedar libre.

El cono de incertidumbre determina el nivel de incertidumbre que tenemos a lo largo de la vida de un proyecto, reduciéndose progresivamente conforme avanzamos en nuestro desarrollo.

En los proyectos tradicionales, la teoría dice que se suele fijar el alcance y el tiempo, quedando el coste como variable condicionada a las dos anteriores. La realidad no es tal y se acaban fijando las tres variables de tal modo que, si aparece un problema no contemplado inicialmente, se compensa en base a sobreesfuerzos, tomando atajos y reduciendo la calidad, o bien con arduas negociaciones entre el cliente y proveedor para ver quien asume los cambios. La incertidumbre en la ejecución de estos proyectos está más acotada ya que la fase inicial está concebida para realizar un análisis exhaustivo de toda la funcionalidad a desarrollar.

En los proyectos ágiles, la variable que suele quedar libre es el alcance, quedando condicionada al tiempo que dura cada una de las iteraciones y al presupuesto disponible. En otras ocasiones queda libre el presupuesto generándose un modelo de financiación iteración a iteración hasta cumplir el objetivo. El nivel de incertidumbre en estos proyectos suele ser muy elevado ya que no se establecen fases previas para realizar este análisis, sino que se asume la imposibilidad de conocer en detalle todo el proyecto desde los inicios y se espera que el propio vaya ganando conocimiento con el tiempo exponiéndolo a los usuarios.

¿Cuándo utilizar Waterfall?

La metodología en cascada aplica en proyectos de ámbito complicado. Un proyecto complicado es aquel sobre el qué tenemos muy poco grado de incertidumbre sobre qué debemos hacer y cómo lo debemos hacer. Requiere de una gran planificación inicial que permita definir las entradas y salidas de cada una de las fases que se ejecutarán de manera secuencial: Análisis, Diseño, implementación, verificación y mantenimiento, siendo la salida de una fase la entrada de la siguiente.

La construcción de un avión puede ser un ejemplo en el que aplicaría Waterfall. Desde el inicio conocemos el resultado esperado y qué debe cumplir para ser un avión. Los pasos que dar para transitar de una etapa a otra deben estar perfectamente definidos desde el inicio para obtener el resultado esperado en el tiempo deseado. Si surgen complicaciones, puede decirse que están dentro de “lo esperado”.

¿Cuándo podemos aplicar prácticas ágiles? 

Agile encaja muy bien en entornos con alto nivel de incertidumbre ya que sus prácticas empíricas permiten ir adaptando nuestro producto a las necesidades que se van descubriendo. El centro de todo proyecto ágil es el usuario final, por tanto, podemos deducir que, para poder sacarle el máximo partido, uno de los requerimientos es que este usuario final esté disponible y participe durante todo el proyecto. ¿Vamos a poder hacer partícipes a los usuarios finales de la evolución de nuestro producto para que nos de feedback y nos ayude a orientarlo hacia algo que realmente le aporte valor?

¿Estamos preparados para recoger todos estos cambios e ir construyendo nuestro producto incrementalmente conforme vamos descubriendo qué necesitamos? Esto choca frontalmente con una planificación inicial y un alcance cerrado.

El desarrollo de una nueva red social podría ser un buen ejemplo de un proyecto que debería realizarse bajo algún marco ágil. El feedback temprano de los usuarios y la medición de la utilización de sus prestaciones deberían determinar la evolución de nuestro producto, adaptándolo según se va descubriendo qué requiere el mercado.

Con todo esto podemos concluir que, los proyectos ágiles aplican cuando desconocemos bastante sobre lo que queremos construir y debemos irlo descubriendo; son proyectos sujetos a una gran cantidad de cambios a los que nos debemos adaptar (y con adaptar no me refiero sólo al equipo de desarrollo, el contrato de proyecto debe también contemplar esta situación de manera que sea beneficiosa para ambas partes); y que son proyectos centrados en el usuario. El usuario debe ser el centro y debe poder implicarse como parte del desarrollo.

Las bondades que aportan las prácticas ágiles en entornos muy definidos pueden no compensar con la dificultad que conlleva adoptar sus prácticas en equipos no experimentados.

Implementar un proyecto aplicando una metodología totalmente pura o “de libro” es altamente complicado y normalmente se realizan y se adaptan partes de estas a las necesidades de nuestros proyectos o de nuestros clientes, pero si somos capaces de plantearnos estas cuestiones antes de tomar una decisión podemos adoptar las bondades de la metodología que mejor se adapte a nuestras necesidades.

Silvia Madrid

Scrum Master and QA Manager at Delivery Cross

INSIGHTS RELACIONADOS