Autora: Maite Moreno

Podemos considerar las metodologías tipo Waterfall pertenecientes a las metodologías tradicionales. Si se aconseja que cuando empecemos a enfocar un proyecto debemos elegir la metodología más adecuada (Waterfall o Agile), de ello se desprende que no podemos desechar ninguna de las dos metodologías. Esto es, dependerá básicamente de los requerimientos del proyecto.

La metodología Waterfall es el método que se ha venido utilizando tradicionalmente y que consiste en desarrollar un proyecto de forma línea y secuencial:

– Captura de requisitos

– Diseño

– Desarrollo

– Testing

– Ajustes

– Producción

Antes de empezar una nueva fase, debemos haber finalizado la anterior, así como liberar los hitos que nos impidan avanzar. Waterfall permite una planificación más sencilla del proyecto; como conocemos el final, permite más fácilmente medir; el equipo puede participar en otros trabajos durante la fase de desarrollo dependiendo de la fase activa del proyecto; una vez capturados los requisitos no se requiere de la presencia del cliente; el diseño se completa al principio del desarrollo, y se produce una comprensión más completa de todos los deliverys.

Sin embargo, como los requisitos suelen fallar y es posible que al final el cliente no esté contento con el delivery, pero como ya estaremos en el final, entonces hacer cambios puede resultar muy costoso.

Así como Waterfall es línea y secuencial, Agile es iterativo, lo que permite un rápido delivery. Los Sprints tienen una determinada duración y una lista de entregables que se planifican al principio. Estos están priorizados en función del valor que tienen para el cliente. Si el equipo no ha podido finalizar todo el trabajo planificado para el Sprint, entonces para el próximo se vuelven a replanificar. Conforme se va completando el trabajo, el cliente puede ir revisándolo.

Agile es customer centric porque el cliente está presente a lo largo de todo el desarrollo del proyecto (concretamente en dichas revisiones). Con Agile, el cliente tiene un fuerte sentimiento de pertenencia al proyecto, forma parte de él, tiene la oportunidad de ver cómo se está desarrollando desde el principio y, por ende, de solicitar cambios si lo considera oportuno. Por otro lado, si el time to market es muy corto, se puede producir una versión beta que se puede ir completando conforme se va iterando.

Sin embargo, si vamos a abordar un proyecto en el cual:

– El cliente no tiene tiempo ni/o interés

– Los miembros del equipo no pueden estar focalizados en ese proyecto

– Los plazos son muy estrictos

– El presupuesto es cerrado

– Los miembros del equipo están diseminados en distintos espacios físicos

En esos casos, posiblemente es mejor utilizar una metodología tradicional tipo Waterfall.

Por otro lado, si el proyecto tiene unas fases de desarrollo muy conocidas y, por ende, la incertidumbre es baja, posiblemente será mejor una metodología tradicional. Son ejemplo de ello los proyectos desarrollados en sectores como el automóvil, ferroviario o aeronáutico en los que la innovación es más incremental. En cambio, si el proyecto tiene un producto definido con cierta ambigüedad o alta incertidumbre, debe salir al mercado un MVP para ver como éste responde al mismo y el time to market es corto (debemos salir rápidamente al mercado), entonces serían aconsejables las metodologías Ágiles. Sirvan de ejemplo los proyectos basados en la innovación disruptiva desarrollados en sectores como el tecnológico o el marketing.