Modelos de gestión de proyectos: Método Ágil vs Cascada
En un contexto como el actual, el creciente ritmo evolutivo de los mercados ha obligado a muchas empresas a entregarse al pragmatismo, acelerando sus procesos y priorizando los resultados. Una muestra de ello es que el Project Management está adoptando una tendencia hacia modelos de gestión cada vez más ágiles frente a los tradicionales. En términos generales, los modelos ágiles se centran más en el ‘qué’ y no en el ‘cómo’, apostando por una gestión flexible que permite realizar los cambios necesarios para garantizar unos resultados satisfactorios para el cliente.
Pero, ¿significa eso que ya no sirvan los modelos más tradicionales? A pesar de que la metodología ágil ha ganado popularidad en los últimos años, lo cierto es que ambos modelos tienen sus pros y sus contras, y resulta difícil asegurar con rotundidad cuál es mejor en cada caso. Para tener alguna clave más, a continuación comparamos dos modelos de gestión de proyectos: Método Ágil y Método Cascada.
Método Ágil vs Cascada
Método Ágil
La metodología ágil se basa en un desarrollo incremental e iterativo (es decir, el proceso de planificación es evolutivo y se va detallando a medida que avanza el proyecto). Fue diseñada para dotar de más autonomía a los miembros del equipo de trabajo frente a las limitaciones que presentan los métodos tradicionales en este sentido. En un proyecto ágil, el equipo está facultado para tomar decisiones, mientras que en los proyectos tradicionales se ejerce un mayor control de arriba hacia abajo.
En el caso de los proyectos de desarrollo de software, el modelo más empleado es el método Scrum. En él, el proceso de diseño se divide en modelos individuales en los que trabajan los diseñadores. Como hemos visto, no existe un plan de acción concreto sino que los desarrolladores son libres de cambiar los requisitos cuando lo consideren conveniente y aplicar las modificaciones necesarias mientras el proyecto avanza.
En los modelos de gestión de proyectos ágiles, los equipos son multifuncionales y trabajan de manera simultánea durante periodos de tiempo fijos. El valor de negocio es prioritario, por lo que si es necesario se pueden cambiar los requisitos para obtener de manera realista el mejor producto final posible sin alterar el tiempo de entrega ni el coste de producción. Esto obliga a mantener un flujo de comunicación constante entre el equipo, la empresa y los clientes.
Este método es especialmente indicado en proyectos cuyos objetivos finales no están claramente definidos o que simplemente prevén un final abierto, es decir, que no preconciben la forma del producto final mientras este sea de la mejor calidad posible según los recursos disponibles. Esto ocurre, por ejemplo, en el diseño de software experimental y en los proyectos que se desarrollan en entornos de trabajo en equipo: los actores implicados trabajan en módulos diferentes y después se emplean para integrar dichos módulos en un producto final único.
Método cascada
La metodología en cascada es un modelo tradicional que, como su nombre permite intuir, es un proceso lineal y secuencial: de manera muy definida existe un punto inicial que nos llevará a un punto final en distintas etapas: Concepción, Inicio, Análisis, Diseño, Construcción, Pruebas, Implementación y Mantenimiento. Como se puede observar, este método está más orientado a la planificación, por lo que es menos flexible pero a la vez más seguro que los métodos ágiles. Los posibles contratiempos se pueden prever y arreglar con cierta normalidad a través del plan de desarrollo y el proyecto puede tomar forma de manera más rápida si los plazos y los costes están estimados de manera precisa, lo cual suele gustar bastante a los clientes.
Para hacernos una idea, el método cascada ofrece un mayor control de la acción, aunque no es impermeable al cambio, puesto que, como hemos dicho, dedica esfuerzos a prever los problemas. Los métodos ágiles cuentan con un margen más amplio para modificar, ampliar o reducir las expectativas que lo hacen más adaptable al cambio.
Suele ser habitual que los proyectos que empiezan con equipos novicios opten por esta metodología más conservadora, ya sea porque sus miembros no han trabajado de manera conjunta previamente o porque el nivel de experiencia no permite adoptar un método ágil que otorgue más poder de decisión de manera individual. En este caso, el método cascada es más entendible para todas las partes implicadas.
Conclusión
Como se ha dicho antes, es arriesgado aventurarse a decir que un método es más válido que el otro, si bien es cierto que la tendencia nos indica que los métodos tradicionales están cayendo en desuso. La razón es obvia: sobre todo en el sector tecnológico, la rápida evolución del software está a la orden del día y los proyectos son fácilmente mutables en el transcurso de su desarrollo, por lo que se necesitan métodos ágiles y equipos altamente preparados. Si lo miramos bajo la óptica de la productividad, en cambio, ambos modelos tienen sus pros y sus contras. En algunos casos, los proyectos ágiles pueden llevar más tiempo por carecer de una exhaustiva planificación previa, mientras que en otros casos, la excesiva documentación de los procesos y la estricta planificación de los métodos tradicionales puede provocar que el proyecto avance más lentamente. En términos de beneficios, los proyectos ágiles tienen más potencial, aunque también tienen más riesgo y probabilidad de fallo si el equipo en su totalidad es inexperto o no está suficientemente implicado.
Por lo tanto, para saber qué metodología es más apropiada, primero deberemos entender bien qué tipo de proyecto y necesidades tenemos delante. Para proyectos estáticos donde es improbable que surjan muchos cambios nos servirá el método cascada, mientras que para proyectos pequeños donde los cambios son habituales en el proceso de diseño será mejor optar por el método ágil.
Y para terminar, nos hacemos otra pregunta: “¿se pueden implementar de manera complementaria sin ser excluyentes?”
Algunos expertos dicen que ambos métodos pueden coexistir en la gestión de proyectos aunque no exista una fórmula definida para ello. El éxito de probar nuevas fórmulas depende del margen de error y de las consecuencias que se esté dispuesto a asumir.
Y a ti, ¿qué modelos de gestión de proyectos te parecen mejor? ¡Cuéntanoslo!