Agile vs. Cascada (Parte 4 de 5). Por qué la cascada puede ser el mejor enfoque

Le damos la bienvenida a la parte 4 de Agile vs. Cascada. 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. En esta parte compararé los positivos y negativos de los dos enfoques y le daré nuestra visión para que sepa cuándo un método es adecuado para algún tipo de proyecto.

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í.

¡Vayamos a la comparación!

Los Aspectos Positivos de la Cascada

La planificación, diseño y arquitectura son más directos ya que el cliente y el desarrollador están de acuerdo en lo que debe ser entregado en el ciclo de vida temprano. Debido a que el alcance completo del trabajo es conocido, el proceso puede medirse fácilmente.

Dependiendo en la fase del proyecto, todos los trabajadores no necesitan estar atrapados en el mismo. Como ejemplo, los analistas de negocios (BAs) pueden continuar trabajando en otras partes u otros proyectos completamente, luego de que los requisitos hayan sido escritos y viceversa, los desarrolladores no necesitan estar involucrados antes que los Bas sepan lo que necesita entregarse. En base a los requisitos de los BAs, los probadores pueden preparar scripts de prueba mientras los desarrolladores están codificando, etc.

Luego de la fase de requisitos ya no hay una fuerte necesidad para el cliente de estar presente y, por lo tanto, puede enfocarse en cosas más pertinentes. El cliente básicamente solo necesita involucrarse para revisiones, aprobaciones, etc.

Si se necesita integrar y ejecutar al mismo tiempo múltiples sistemas/componentes/paquetes de software, un diseño temprano es usualmente requerido. Esto se adapta perfectamente al enfoque escalonado de la Cascada.

Arquitectura, un intercambio usualmente olvidado o descuidado en el desarrollo moderno de softwares, puede también ser diseñara mejor para escalabilidad, coherencia general e integridad ya que hay un entendimiento más completo de todas las partes de todo el sistema. El código no necesita ser reescrito una y otra vez, lo que algunas veces sucede en el caso del Scrum, lo que a veces resulta en un sistema fragmentado.

Los recursos de los proyectos no son tan críticos, ya que la planificación y la documentación ya ha sido realizada, por lo tanto, si un desarrollador abandona, es fácil que otro tome su posición y continúe rápidamente con el plan.

Debido a que el método en Cascada requiere una planificación inicial, el software puede ser lanzado rápidamente luego del desarrollo. Las estimaciones de horarios y presupuestos pueden hacerse con mayor precisión, lo que definitivamente tiende a complacer a los clientes.

Los Aspectos Negativos de la Cascada

Reunir y documentar los requisitos para que el cliente entienda lo que significan es muy difícil. A menudo, los clientes se sienten intimidados por los detalles y los detalles específicos deben ser proporcionados temprano en el proyecto antes de que se realice algún proyecto. Los clientes usualmente no pueden visualizar una aplicación de un documento de requisitos. Los esquemas y las maquetas ayudan, pero la mayoría de los usuarios finales tienen dificultad de entender estos elementos con suficiente detalle para visualizar claramente el producto final.

Este problema significa que un cliente puede no estar satisfecho con su producto entregado una vez se haya finalizado. Dado que todas las entregas se basan en requisitos documentados, es posible que el cliente no vea lo que se entregará hasta que se hayan terminado grandes partes del proyecto. En ese momento, los cambios son complicados y costosos.

La retroalimentación y las pruebas se diferirán hasta que se completen las partes más importantes del proyecto. Esto significa que los problemas y las deficiencias pueden ser más difíciles de cambiarse sin cantidades considerables de tiempo y esfuerzo.

Los Aspectos Positivos de Scrum

Dado que el cliente tiene oportunidades frecuentes y tempranas para ver el trabajo que se está presentando, y pueden hacer decisiones y cambios a través del proyecto, el cliente gana un sentido de propiedad. El cliente trabaja extensivamente y directamente con el equipo del proyecto a través del mismo.

Scrum producirá una versión base simple más rápido que la Cascada, lo que algunas veces es adecuado para la creación de prototipos.

El desarrollo está enfocado en el usuario y los cambios debido a problemas o insuficiencias pueden ser remediados más rápido y a un menor costo. Debido a que el diseño es flexible, el proyecto tendrá una vida más evolutiva y menos estricta. Esto tiene un número de ventajas, especialmente en los ambientes del proyecto, donde las necesidades de desarrollo deben poder responder a los cambios en los requisitos de forma rápida y efectiva.

Scrum puede ser especialmente beneficioso en situaciones donde las metas finales de los proyectos no estén claramente definidas. SI no es posible que el cliente proporcione una meta clara en la parte temprana del proyecto, Scrum trabajará bien ya que esto puede ser aclarado a medida que el proyecto avanza

Usualmente con Scrum hay más interacción y comunicación, lo que usualmente toma prioridad en el diseño. Dado que las partes están más involucradas, es especialmente propicio para entornos de trabajo en equipo. Diferentes desarrolladores trabajan en diferentes módulos a través del proceso de desarrollo y luego trabajan para integrar todos estos módulos en una pieza cohesiva de software al final del proyecto.

Los Aspectos Negativos de Scrum

No todos los clientes tienen ya sea el deseo o el tiempo de estar muy involucrados en el proyecto. Scrum funciona mejor cuando todos los miembros del equipo están completamente dedicados al proyecto. Por lo tanto, no es una buena idea tener menos del 100% de los recursos dedicados para este tipo de proyecto.

Scrum se enfoca en entregas en tiempo real y cambios frecuentes en las prioridades, por lo que algunos puntos pueden no ser completados dentro del marco de tiempo determinado para el proyecto. Puede que se necesiten sprints adicionales para completar las características, lo que por supuesto se añade al costo total. Además, el alto grado de participación del cliente usualmente lleva a peticiones adicionales de características a través del proyecto, extendiendo el tiempo necesario para completarlo.

Los clientes usualmente tienen dificultades para mantenerse al día con la rápida iteración y ciclos de pruebas del Scrum. Esto puede poner el proyecto en riesgo ya que, mientras más tiempo pasen los desarrolladores sin una retroalimentación, más difícil será recuperar si no están desarrollando exactamente lo que el cliente espera.

Debido a que Scrum es altamente flexible y no tiene la estructura del método en Cascada, los proyectos de Scrum tienden a ser más difíciles de predecir, desde tiempos de entrega hasta presupuestos. Sin un plan concreto y un conjunto completo de requisitos, todo se mantiene un poco vago.

El trabajo en equipo en Scrum es más fácil de manejar cuando todos los miembros del equipo se encuentran localizados en el mismo espacio físico. Además, la colaboración intensa y los requisitos menos complejos resultan en problemas catastróficos si algún miembro del equipo deja el proyecto.

Scrum tiene menos énfasis en entender el sistema finalizado como un todo en la parte temprana del proyecto, lo que puede llevar a una reducción de la calidad y desempeño general del sistema. Esto es especialmente cierto para implementaciones a gran escala o con sistemas que incluyen un gran nivel de puntos de integración.

Este método de desarrollo puede ser bastante lento, mucho más que el desarrollo en Cascada. Hay muchos códigos que se deben reescribir debido a cambios de requisitos y problemas en la funcionalidad. A menudo, los requisitos no son claros al principio, lo que puede resultar en una arquitectura poco óptima que no es lo suficientemente flexible para alcanzar los requisitos finales. A menudo, se pasa mucho tiempo puliendo detalles para los usuarios antes de que comience la programación.

Como el proyecto final no tiene un plan definitivo, el producto terminado puede ser muy diferente a lo que se pretendía inicialmente. Esto además se relaciona con la incapacidad de dar una fecha máxima al momento que se firma un contrato.

Cuando Seleccionar la Cascada Sobre Scrum

Algunas cosas para considerar:

• Si el tamaño del proyecto y la complejidad son grandes, ejemplo, una gran migración de sistemas involucrando sistemas diferentes.
• El cliente no se puede comprometer a una extensa participación.
• Las integraciones de sistemas externos son numerosas, con muchos puntos (incluyendo los sistemas heredados).
• El presupuesto y el calendario son fijos o difíciles de modificar.
• Se requiere el proyecto completo antes del lanzamiento.
• Los desarrolladores necesitan orientación, gestión y supervisión.
• El cliente no espera cambios mayores en el ámbito del proyecto
• EL cliente sabe exactamente lo que quiere.

Cuando Seleccionar Scrum Sobre la Cascada

Algunas cosas que considerar:

• El tamaño y la complejidad del proyecto son pequeños (puede utilizarse en proyectos grandes en ciertas circunstancias). Ejemplo, tiendas online pequeñas, sitios web, desarrollo de apps.
• El cliente está disponible frecuentemente durante la duración del proyecto.
• Las integraciones con sistemas externos son simples o no necesarias.
• El presupuesto y el horario son flexibles a los cambios y son bienvenidos por los clientes.
• Se requiere un prototipado y despliegue rápido. El proyecto/producto puede ser lanzado sin tener todas las características.
• No hay una imagen clara de cómo debe ser el producto final.
• Los desarrolladores son habilidosos y se adaptan fácilmente sin la necesidad de ser supervisados
• Cuando el producto está destinado para una industria con estándares en constante cambio.

Esta fue la parte 4. Espero que fuera fácil de entender, informativa y que haya aprendido lo básico para escoger el método correcto para su proyecto.

Vuelva para leer la última parte (parte 5) de “Agile vs. Cascada. Entonces, ¿Cuál es el mejor modelo?”, donde le daré algunas ideas más profundas y la consideración de cómo una combinación de ambos mundos podría ser preferida.