Agile vs. Cascada (Parte 5 de 5). Entonces, ¿Cuál es el mejor método?

Le damos la bienvenida a la parte 5 de Agile vs. Cascada, esta es la última parte de la serie de publicaciones. Nuestra primera parte presentó el Modelo de Cascada, la segunda presentó el modelo Scrum de Agile y la tercera describió la relación entre el costo, la funcionalidad y el tiempo. La cuarta parte realizó una comparación directa entre los dos enfoques y sugirió cuándo usar cada uno. En esta última parte, le daré información acerca de cuál modelo funciona mejor y cómo combinar lo mejor de ambos mundos.

Si no ha leído la parte 1, la puede encontrar aquí.

Si no ha leído la parte 2, la puede encontrar aquí.

Si no ha leído la parte 3, la puede encontrar aquí.

Si no ha leído la parte 4, la puede encontrar aquí.

No perdamos más tiempo, ¡Vayamos a la conclusión!

¿Cuál método es mejor?

A medida que agile ha aumentado su popularidad y las organizaciones de todo el mundo están luchando para adoptar este paradigma, principalmente en la forma de Scrum, también se ha demostrado que hay momentos en los que los proyectos toman más tiempo son más costosos y tienen menos características al seleccionar Agile sobre el modelo en Cascada.

Al llegar a este punto, podemos decir que ni Agile con Scrum ni el método de Cascada son inherentemente uno mejor que el otro. Dicho eso, cada método tiene sus méritos. La cascada tiende a ser mejor para proyectos que no tengan muchos cambios durante el proceso de desarrollo y que no aceptan errores. Scrum tiende a ser una opción mejor para proyectos más pequeños donde los cambios son ya sea rápidos o fáciles de implementar durante el proceso o con proyectos que puedan ser modularizados.

En scrum, la expansión del alcance no es un problema, porque se trata de obtener funcionalidades, en el orden correcto y en base a las necesidades del negocio, Pero, en práctica, Scrum puede llegar a ser desarticulado y sin dirección, una excusa para la ausencia de procesos internos y caos organizacional. A menudo se asume que Scrum no necesita una visión estratégica, lo que es un error fatal.

Si los equipos del proyecto están localizados en diferentes lugares y zonas horarias, la coordinación del trabajo necesita ser relativamente detallada para evitar confusiones y pérdidas de tiempo. En este caso, el método de Cascada es el más apropiado, ofreciendo entregables, hitos y dependencias claras. Cuando los proyectos requieren conocimientos especializados únicos y estos recursos no están disponibles inmediatamente, una buena planificación es requerida. Si esto es costoso o difícil de organizar, es importante asegurarse que el recurso se utilice plenamente durante su uso programado. Para esto, la cascada es un mejor enfoque, ya que la planificación es mucho más confiable para asegurar una máxima eficiencia de uso.

Mientras que cada modelo tiene sus fortalezas y defectos, los conceptos erróneos reinan sobre ambos. Es una desorganización debido a la falta de disciplina o una complejidad innecesaria arraigada en una creencia irracional de que uno puede eliminar el riesgo. Las empresas eficientes y maduras entienden cuándo aplicar cualquiera de estos métodos. En práctica, las organizaciones con ciclos de desarrollo exitosos usualmente emplean un enfoque híbrido, tomando un poco de cada metodología.

Lo mejor de ambos mundos

El enfoque híbrido puede ser concebido con un diseño tomado de la metodología de Cascada, inicialmente, pero luego cambiando a Scrum como método de producción. Esto le dará una vista general del proyecto completo, pero permitirá el desarrollo con retroalimentaciones constantes basadas en los requisitos de los usuarios. Esto permite que un equipo gane conocimientos sobre el panorama general con un análisis y diseño preliminar, al tiempo que permite cambios incrementales durante las fases de desarrollo e implementación. El equipo puede ofrecer una funcionalidad completa, pero enfocada que comprende una pequeña parte del conjunto. Esto mantendrá al negocio ocupado y responsivo, mientras que, al mismo tiempo, asegura que el BA y los equipos de prueba tengan una mejor conexión con el progreso del proyecto. Esto asegura que una planificación apropiada puede hacerse y se pueden establecer estimaciones realistas para todo el proyecto.

Se requiere la adopción de un enfoque general de arquitectura para minimizar las brechas de los requisitos. Los talleres de soluciones deben ser llevados a cabo con todas las partes interesadas, como Negocios, marketing, IT, para asegurar la congruencia en los requisitos actuales y la solución final. Los controles de cambios y riesgos deben estar estrictamente aplicados, con el fin de controlar y manejar la influencia del alcance. Los cambios mayores deben ser tomados a una junta de revisión con los interesados principales, especialmente para proyectos grandes o de transformación.

Y, finalmente, ¡el patrocinio ejecutivo debe ser fuerte para que todos, hasta los proyectos tengan éxito!

Realmente, cuando se trata de escoger un método, no hay opción correcta o equivocada. Usted solo necesita entender cuál método es el más adecuado para su proyecto y sus necesidades, ya sea el de Cascada, el Scrum o un enfoque híbrido.

Diferentes situaciones obviamente requerirán diferentes enfoques. Pero, una cosa que es cierta y es que el uso de cualquiera de las metodologías aumentará enormemente el éxito a comparación de no seguir ningún proceso o simplemente ir a ad hoc.

Esta fue la parte final de la serie Agile vs. Cascada. Espero haya sido una lectura iluminadora, útil e informativa.

Luego de leer esta serie, ahora debe tener una opinión sana y objetiva sobre ambos modelos con sus pros y sus contras y ya debe tener una mentalidad para no dejarse influir por “expertos” que a menudo pueden causar confusiones. Como se puede ver, la Cascada no es del todo mala y el Scrum no es del todo bueno. Nosotros en Forecast.it proponemos cualquiera de los tres modelos dependiendo de lo que quiera alcanzar.