Metodología Cascada: Definición, Proceso y Ejemplos
Vivimos en un mundo donde la metodología Ágil es ubicua. Desde grandes gigantes tecnológicos hasta pequeñas startups, todos la utilizan para construir sus productos. Al aprender sobre Ágil, puede que te hayas encontrado con el término “metodología en cascada”.
La mayoría de los jefes de proyecto que usan Ágil consideran la metodología en cascada como algo anticuado que ya no tiene cabida en 2023. ¿Pero es esto realmente cierto?
Como gerente senior de producto, tengo mucha experiencia tanto en Ágil como en cascada. En defensa de la metodología en cascada, vamos a adentrarnos en qué consiste, cómo funciona y cuándo es apropiado utilizarla.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
¿De qué trata la metodología de gestión de proyectos en cascada?
La cascada representa el concepto de gestionar proyectos de desarrollo dividiéndolos en fases distintivas y abordando cada una de forma secuencial.
Si bien dividir grandes trozos de trabajo en partes más pequeñas es un concepto utilizado por los humanos desde el principio de los tiempos, el “nacimiento” formal de la metodología en cascada ocurrió mucho después—en 1970, cuando el Dr. Winston W. Royce, un destacado científico informático de esa época, la describió en su libro “Gestión del desarrollo de grandes sistemas de software”.
Desde entonces, se convirtió en la principal manera en que las compañías de software gestionaban sus proyectos hasta que el mundo empezó a inclinarse hacia Ágil a principios de los 2000.
Cómo es el ciclo de vida de desarrollo de software (SDLC) con el método en cascada
A diferencia de la estructura iterativa e incremental de Ágil, el SDLC para cascada tiene tanto un inicio como un final definidos. Divide todo el proceso de creación de software en cinco fases o hitos diferentes y el trabajo en cada fase no comienza hasta que la anterior se ha completado. Visualmente, se ve así:
El trabajo fluye de una fase a otra, luego llega al final y el proyecto se considera “completo”, lo que lo hace visualmente similar a una cascada (de ahí el término).
Ahora echemos un vistazo a cada fase en este enfoque lineal y veamos de qué se tratan.
Fase #1: Recopilación de Requisitos
Todo comienza recogiendo los requisitos del proyecto de todas las partes interesadas. Durante la fase de requisitos, los jefes de proyecto crearán un documento exhaustivo y muy detallado que cubre todos los aspectos del proyecto, desde los requisitos funcionales hasta el presupuesto y el plan de riesgos.
Fase #2: Diseño de la Solución
Con base en los requisitos recopilados en la fase anterior, el equipo del proyecto comenzará a formular la solución y diseñarla. El término “diseño” aquí se refiere a la estructura técnica del producto (diseño del sistema), el diseño visual e interactivo del producto (Diseño UI/UX), y el diseño físico (si se trata de un producto físico).
Fase #3: Implementación
Aquí es donde se realiza la codificación propiamente dicha. Los integrantes de tu equipo de desarrollo comenzarán a construir el producto en base a los entregables que creaste en la fase de diseño.
A diferencia de Ágil, donde eres libre de cambiar el alcance y el diseño de tu proyecto constantemente, la metodología en cascada asume que seguirás el documento de diseño y no "evolucionarás" tu producto durante la fase de implementación.
Fase #4: Pruebas
Tan pronto como el equipo de ingeniería de software haya terminado de construir el producto, podemos pasar a la siguiente fase de nuestro plan de proyecto: las pruebas. Tu equipo comenzará a revisar el producto en busca de errores, fallos de seguridad o problemas de experiencia de usuario.
Durante la fase de pruebas, también comprobarás si la funcionalidad y el diseño del producto final se ajustan a los documentos de requisitos del proyecto que creaste en las dos primeras fases.
Fase #5: Despliegue y Soporte Post-lanzamiento
Suponiendo que tu equipo ha encontrado y corregido todos los problemas significativos en tu producto, es momento de lanzarlo y entregar la solución a tus clientes y usuarios finales.
Tus programadores ahora pasarán a la fase de mantenimiento, recopilando constantemente retroalimentación de los clientes, realizando los arreglos necesarios y publicando nuevos parches y actualizaciones de tu producto.
¡Eso es todo, tu proyecto está completo y puedes pasar al siguiente!
Entonces, ¿deberías utilizar el método en cascada?
Si tú, el PM de mentalidad Ágil (al menos eso supongo), piensas que esta metodología está pasada de moda y que nunca deberías considerarla, (respetuosamente) no estoy de acuerdo contigo y sostengo que el enfoque en cascada es en realidad la mejor opción para determinados tipos de proyectos.
Déjame darte un par de ejemplos para demostrar mi punto.
Estudios de Caso: El Método Waterfall en Acción
Como ocurre con cualquier concepto complejo, algunos ejemplos concretos pueden ser útiles para entender cómo funciona la metodología en la vida real. Así que aquí tienes algunos ejemplos basados en proyectos reales (en los que puede que haya trabajado o no) para ayudarte a cristalizar cómo funciona el enfoque waterfall en la práctica.
Caso n.º 1: Una Plataforma de Despacho de Aduanas para el Gobierno de Egipto
Imagina que eres parte de una empresa que ha ganado el contrato para modernizar los sistemas de comercio internacional y despacho de aduanas de un país relativamente grande, digamos Egipto.
Lo que el gobierno egipcio quiere es un sistema de autoridad portuaria que gestione todos los manifiestos de los barcos (un documento aduanero que contiene información sobre toda la carga y pasajeros a bordo de ese barco) que ingresan a los distintos puertos de Egipto.
Además, quieren que este sistema se integre directamente con otro producto que desean que desarrolles, el cual gestionará todas las declaraciones de aduana (también conocidas como SADs o documentos administrativos únicos) en el país. El formulario es bastante complejo para que la gente común lo complete, por lo que quieren que lo automatices por ellos.
Egipto tiene un sistema de impuestos y aranceles aduaneros complejo que cambia las tasas según el tipo de bienes que se importan, su cantidad y otros factores. Como los ciudadanos comunes no tienen idea sobre estas tasas, el gobierno egipcio quiere que tu aplicación calcule todo automáticamente para sus ciudadanos según lo que hayan declarado, y que puedan pagar en línea usando sus tarjetas de crédito.
Esto parece una tarea inmensa, ¿verdad? Pues bien, al final de los detalles de implementación, los directivos (e incluso tal vez el propio gobierno egipcio) acudirán a ti, el gestor de proyectos, y te preguntarán cómo deseas organizar la implementación de este proyecto.
Por qué y cómo deberías usar el método waterfall en este escenario:
Todo lo que construyas para un gobierno nacional probablemente estará basado en una ley o en una decisión que el parlamento haya ratificado. Estas decisiones incluirán desde los términos generales del proyecto (por ejemplo, su coste y cronograma) hasta los detalles más minuciosos de cómo funcionará todo.
¿No suena y se ve como un documento de requerimientos de la primera fase de waterfall? De hecho, sí, y también significa que realmente no puedes cambiar detalles de implementación, diseño y requisitos sobre la marcha como sucede en el desarrollo ágil.
Solía liderar un producto así. Un día, nos dimos cuenta de que podíamos mejorar considerablemente la experiencia de usuario haciendo un par de pequeños ajustes en la lógica de negocio. Inmediatamente compartimos nuestra idea con el representante de la autoridad aduanera que trabajaba con nosotros.
Pues bien, él dijo que no. Podrías pensar que rechazar esa oferta era una mala idea, pero tenía una buena razón por la que no podían hacerlo.
Nuestros pequeños ajustes implicarían un cambio en la fórmula que utilizaba el gobierno para calcular los impuestos de un producto en particular. La fórmula estaba fijada por ley, así que cambiarla significaría reunir a todo el parlamento nacional y votar sobre ello.
More Articles
Caso n.º 2: El Sistema de Control de Vuelo del Helicóptero Ingenuity
Ingenuity es el nombre que la NASA dio al helicóptero de alta tecnología que construyeron y enviaron a Marte en 2021. Así es como se ve esta pequeña maravilla.
Pues imagina que fuiste el afortunado gestor de proyectos a cargo del desarrollo del software para este increíble aparato tecnológico. En particular, tu equipo debía escribir el código que controlaría el vuelo del helicóptero.
Crear un sistema de control de vuelo para una aeronave (especialmente un helicóptero) es sumamente difícil. Debes considerar todas las leyes de la física que interactúan con tu aeronave durante el vuelo y calcular la velocidad necesaria de rotación de las palas, el ángulo de estas y un millón de cosas más.
Pero tu tarea es aún más compleja. Tu helicóptero tendrá que volar sobre la superficie de otro planeta con una atmósfera 100 veces menos densa que la de la Tierra.
Por qué y cómo deberías usar el método waterfall en este escenario:
En mi opinión, el desarrollo waterfall es tu única opción aquí. A diferencia de la gestión de proyectos ágil, en la cual construyes algo pequeño (tu MVP), lo implementas, lo usas en la vida real, recopilas comentarios y vas mejorando gradualmente tu solución en base a ese feedback, aquí los riesgos son demasiado altos en un proyecto como este.
¿Realmente puedes arriesgarte a construir un MVP defectuoso de Ingenuity y enviarlo a 140 millones de millas a Marte? Simplemente, nadie estaría de acuerdo con eso.
Por lo tanto, tendrás que construir la versión final y luego probar rigurosamente todos sus sistemas antes de tener la confianza necesaria para colocarlo en un cohete rumbo al planeta rojo.
¡El modelo Waterfall está vivo y coleando!
De hecho, es mucho más popular de lo que podrías esperar, con la mitad de todos los proyectos a nivel mundial que aún utilizan esta metodología de desarrollo.
Aunque la llegada de Agile ha hecho el mundo un mejor lugar para muchos gerentes de proyecto permitiéndoles lanzar productos mucho antes y construir sobre el feedback de sus usuarios, Waterfall sigue siendo una metodología sumamente valiosa que puedes emplear para proyectos con flexibilidad limitada y una baja tolerancia a errores.
Espero que te haya gustado nuestra cobertura sobre la metodología Waterfall. Si también deseas leer un poco más sobre Agile, esto es lo que puedo recomendarte:
- Nuestra guía sobre Gestión de Productos Ágil.
- La recopilación de mejores prácticas para la Gestión de Portafolios Ágil.
- Nuestra lista seleccionada de las mejores Herramientas para la Gestión de Productos Ágil.
Estos son solo tres de los muchos artículos y guías que tenemos sobre gestión de productos y proyectos. Para más información, suscríbete a nuestro boletín.
