Cascada vs. ágil: cómo elegir el enfoque para tu proyecto

En muchos equipos la discusión sobre metodología se parece a una guerra de religión: unos defienden el plan detallado, otros juran que "ágil" lo resuelve todo. La realidad es menos dramática: son dos formas de manejar la incertidumbre, y cada una funciona mejor en ciertas condiciones.

Cascada: planear primero, ejecutar después

En el enfoque en cascada (waterfall) el trabajo avanza por fases: requisitos, diseño, construcción, pruebas, entrega. Cada fase termina antes de que empiece la siguiente. Funciona bien cuando:

• Los requisitos son estables y se entienden desde el inicio.
• Cambiar tarde es muy caro (construcción física, hardware, sistemas regulados).
• Hay contratos de alcance y precio cerrados.
• Se exige documentación y trazabilidad formales.

Sufre cuando:

• Los requisitos cambian o no se conocen del todo.
• El usuario solo ve el resultado al final, y ahí descubre que no era lo que necesitaba.
• Los problemas de integración aparecen tarde.

Ágil: entregar en ciclos cortos y aprender

El enfoque ágil, formalizado en el Manifiesto Ágil de 2001, parte de otra premisa: no podemos conocer todo de antemano, así que conviene construir en pedazos pequeños, mostrarlos y ajustar. Valora, como dice el manifiesto, a las personas e interacciones sobre procesos y herramientas, el software funcionando sobre documentación extensa, la colaboración con el cliente sobre la negociación de contratos y responder al cambio sobre seguir un plan. No dice que lo segundo no importe, sino que lo primero importa más. Funciona bien cuando:

• Hay incertidumbre sobre lo que se necesita.
• Se puede entregar valor por partes.
• Los usuarios pueden participar y dar retroalimentación frecuente.
• El equipo tiene autonomía para decidir.

Sufre cuando:

• El cliente exige alcance, precio y fecha fijos desde el día uno.
• No hay quien priorice (no existe un dueño del producto con tiempo).
• Se adopta la ceremonia sin el espíritu: reuniones diarias, pero sin autonomía real.

Comparación rápida

| | Cascada | Ágil | |---|---|---| | Planeación | Completa al inicio | Continua, por ciclos | | Cambios | Costosos, controlados formalmente | Esperados, se priorizan | | Entregas | Una grande al final | Pequeñas y frecuentes | | Retroalimentación | Tardía | Temprana | | Riesgo principal | Construir lo equivocado | Perder la visión de conjunto | | Medida de avance | Contra el plan | Software funcionando |

No es una elección binaria

Muchos proyectos reales son híbridos:

• Planeación general por fases para el presupuesto y los hitos, con ejecución ágil dentro de cada fase.
• Desarrollo ágil con requisitos regulatorios que exigen documentación y aprobaciones formales.
• Equipos ágiles que dependen de proveedores trabajando en cascada.

Lo importante es entender por qué haces cada cosa y no copiar un proceso porque está de moda.

Preguntas para decidir

1. ¿Qué tan claros están los requisitos hoy?
2. ¿Qué tan caro es cambiar de opinión a la mitad?
3. ¿Puedo entregar por partes y obtener retroalimentación?
4. ¿Qué exige el contrato o la regulación?
5. ¿Qué experiencia tiene el equipo con cada enfoque?

Si la mayoría de las respuestas apunta a incertidumbre y cambio, ve por lo ágil. Si apunta a estabilidad y alto costo de cambio, tiene más sentido planear más por adelantado.

Errores comunes

• "Hacer ágil" sin cambiar nada más: mismo control, mismas aprobaciones, solo con otros nombres.
• Usar ágil como excusa para no planear ni documentar.
• Usar cascada con requisitos que se sabe que cambiarán.
• Cambiar de metodología a mitad del proyecto como solución a un problema que no es de metodología.

Dónde me siento más en mi elemento

He gestionado de principio a fin proyectos muy distintos: capítulos y comunidades estudiantiles, congresos, concursos de programación y de redes, el AWS Student Community Day México, un CMMS a la medida y el área de DevSecOps. En la gran mayoría trabajé con metodologías ágiles, y es donde me siento más en mi elemento: ciclos cortos, retroalimentación frecuente y la libertad de ajustar sobre la marcha. Pero hay algo que no negocio con ninguna metodología: la trazabilidad. Poder seguir un requisito hasta lo que se entregó, y un entregable hasta la necesidad que lo originó, me parece una de las cosas más valiosas de gestionar bien un proyecto. Como decía Susana Siller: «Todo con orden». Y el orden, para mí, es compatible con la agilidad.

Para finalizar

Ninguna metodología arregla un equipo sin objetivos claros, sin confianza o sin respaldo. Elige según la incertidumbre del proyecto y el costo del cambio, y adapta con criterio. En los siguientes artículos entro a dos marcos concretos del mundo ágil: Scrum y Kanban.