Agile vs. Cascada (Parte 1 de 5). ¿Qué es la Metodología en Cascada?
A medida que las metodologías Agiles han sido adoptadas ampliamente, un debate en curso ha surgido con la duda de si Agile es realmente la mejor metodología a seguir para maximizar el desarrollo de un producto, ejemplo: Características, Retorno de Inversión y estabilidad.
Después de que muchas organizaciones comenzaran a adoptar el movimiento Agile, nos han preguntado cada vez más si Agile es el enfoque correcto.
En esta serie de publicaciones de 5 partes, describiré las diferencias entre la Metodologías de desarrollo de Cascada y Agile, además, se mencionará por qué cada metodología tiene sus propios méritos.
La primera parte (esta) se concentrará en describir el enfoque en Cascada. En las próximas partes describiré el enfoque agile y por qué ambas metodologías no son mutuamente excluyentes para una organización. Me referiré a las limitaciones de los proyectos, como costo, tiempo y funcionalidad. Además, me enfocaré en explicar por qué agile no siempre es la que hay que seguir y por qué la Cascada puede, en algunos casos, ser una solución mucho mejor y más confiable. Finalmente, voy a dar algunos consejos para que usted escoja el enfoque correcto.
¿Está listo para entrar en las trincheras y echar un vistazo a ambos lados?
Para nivelar el campo y primero que todo, Agile y Cascada pueden describirse como dos enfoques diferentes para administrar un proyecto y el proceso de desarrollo de un ciclo de vida. Agile es favorecido por sus seguidores por ser más flexible, colaborativo, enfocado a los cambios y usualmente diseñado para pequeños proyectos donde un Producto Mínimo Viable (PMV) es crucial. Por otro lado, la Cascada es más controlada y estricta, con progresos medidos por metas y objetivos secuenciales claramente definidos. Ambas metodologías han demostrado que pueden funcionar o fracasar dependiendo del tipo de proyecto. Entonces, ¿Cuál elegir?
Para simplificar un poco las cosas, de ahora en adelante me referiré al modelo secuencial como Cascada y al Agile como Scrum.
Desarrollo del Modelo Cascada
La mentalidad tradicional del desarrollo de un software es usualmente llamada el Modelo de Cascada. Utilizando el modelo de cascada un producto no debe moverse de una fase a la siguiente hasta que la fase predecesora haya sido completada a la perfección. No es posible regresar a etapas previamente concluidas. Este modelo de desarrollo se muestra en la imagen más abajo. Un problema con este enfoque es que el riesgo se empuja al proceso de desarrollo y puede, si el software tiene un tamaño significativo causar problemas más adelante en el proceso. Esto puede llevar a un incremento en el costo del proyecto y puede resultar en la terminación del mismo. (Kruchten, 2003).
Para cualquier Proyecto no trivial es difícil tener una fase del ciclo de vida de un producto de software perfeccionada antes de moverse a las siguientes fases y aprender de ellas. Por ejemplo, los clientes pueden no estar conscientes de exactamente qué requisitos quieren hasta que ven un prototipo funcional y pueden realizar sus comentarios. Puede que cambien sus requisitos constantemente y los diseñadores del programa e implementadores deben tener algo de control sobre esto. Si el cliente cambia sus requisitos luego de que el diseño haya sido finalizado, ese diseño debe ser modificado para adaptarse a los nuevos requisitos, lo que a menudo invalida una parte del esfuerzo y las horas invertidas. La siguiente imagen da un modelo típico de un desarrollo en Cascada.
Los diseñadores pueden no estar al tanto de las futuras dificultades de implementación al escribir un diseño para un producto de software no implementado. Puede volverse claro en la fase de implementación que un área en particular de la funcionalidad el programa es extraordinariamente difícil de implementar. En este caso, es mejor revisar el diseño que persistir utilizando un diseño hecho basado en predicciones erradas y que no tiene en cuenta las áreas problemáticas recién descubiertas.
A menos que aquellos que especifican los requisitos y aquellos que diseñan el sistema de software en cuestión tengan un gran conocimiento del problema a resolver, es difícil saber exactamente lo que se necesita en cada fase del proceso antes de pasar algo de tiempo en la fase siguiente.
Si no ataca activamente los riesgos en su proyecto, estos lo atacarán activamente a usted (Tom Gilb, 1988).
La retroalimentación de las fases siguientes es usualmente necesaria para completar las fases precedentes. Puede ser difícil estimar el tiempo y costo de cada fase del proceso de desarrollo sin hacer una especie de “prueba de concepto” en esa fase, a menos que aquellos estimando el tiempo y los costos tengan una amplia experiencia en el tipo de producto de software en cuestión. Vale la pena mencionar que, sin embargo, con la experiencia y aprendizaje de proyectos anteriores, ¡Se puede hacer con gran precisión!
Cuando se piensa en la metodología de Cascada, usualmente esta se ve como un enfoque de peso pesado a la gestión de proyectos con un Diseño Detallado por Adelantado (“Big Design Up Fromt” BDUF) que no tiene ningún punto de control en el camino, llevado a cabo sin tener en cuenta las condiciones cambiantes. Esto no es necesariamente cómo se debe trabajar y no significa que usted no puede evaluar su progreso y cambiar el curso a lo largo del camino. No significa que usted no puede medir dónde usted se encuentra o comparar eso contra las expectativas que se realizaron por adelantado.
La Cascada puede ser muy superior cuando el cliente sabe exactamente lo que quiere y nada cambia sustancialmente más allá de los arreglos de errores. La metodología en Cascada es muy desacreditada porque la mayoría de los clientes no saben lo que quieren (lo que es perfectamente normal, siempre y cuando haya alguien que los guíe).
Este es el final de la primera parte. Espero la encuentre esclarecedora.
Vuelva para leer la parte 2. Agile vs Cascada. ¿Qué es la metodología Agile?
