Si la cascada es tan mala, ¿por qué se ha estado usando durante tanto tiempo? Si Agile es tan bueno, ¿por qué no se usó desde el principio?

¡Hola Adiv!

¡Excelentes preguntas como siempre! Aquí están mis pensamientos.

Creo que podría ayudar verlo como una evolución. Agile fue creado por esos exactos primeros desarrolladores de software que querían hacer un cambio en cómo funcionaba el proceso, porque había defectos. Es una evolución de cierta manera.

Si es así, ¿cómo se actualizaba el software alguna vez?

¿Alguna vez usaste Microsoft Windows 95 en 2000? ;) Proceso largo para hacer cambios aparentemente pequeños, todos lanzados a la vez.

Si el cliente tiene que hacer parte del trabajo por el que está pagando al equipo, ¿no puede exigir legítimamente un precio reducido, verdad?

Este trabajo en diferentes prácticas de desarrollo también es requerido, usualmente al principio a través de documentos de especificación y verificación. Este trabajo, en mi experiencia, casi siempre se aborda con los brazos abiertos, ya que pueden cambiar cosas temprano y frecuentemente. El trabajo se distribuye a lo largo de la vida del proyecto en lugar de cuando es demasiado tarde o demasiado temprano.

¡Espero que eso te ayude!

Si la cascada es tan mala, ¿por qué se ha utilizado durante tanto tiempo? Si Agile es tan bueno, ¿por qué no se utilizó desde el principio?

La cascada no es tan mala para otros campos, y al muy principio no se utilizó, el departamento era tan pequeño que la colaboración entre equipos era imprescindible, había solo 5 tipos que entendían cómo funcionaban las computadoras. Cuando el departamento creció, intentaron forzarla en un sistema previamente utilizado, lo que no era saludable para el producto.

¿No entendieron los primeros desarrolladores de software los problemas que se supone que Agile aborda?

Sí y funcionó lo suficientemente bien, los clientes tendrían que hablar directamente con los programadores, pero como aprendes rápidamente, esta es un área llena de jerga, así que tratar con clientes que no sabían nada de lo que las computadoras podían hacer o lo que querían era un problema. Entonces, para eliminar el colapso en la comunicación, necesitaban a alguien en el medio, el gerente, la persona jefe de cascada se interpuso, y así es como llegamos a donde estamos.

¿Es el método de cascada realmente tan inflexible como se presenta en la presentación? Si es así, ¿cómo se actualizaba el software alguna vez? ¿Cómo maneja una empresa de cascada las especificaciones o objetivos cambiantes del software que construye?

En un método de cascada tradicional, el cliente entraría a la empresa y negociarían términos sobre el producto. Quiero ABC y el cliente obtendría ABC sin importar qué más sucediera. Entonces, si el cliente una semana después volvía diciendo "No necesito A, necesito D", estaban de mala suerte. Podrían establecer otro contrato para poner D en el producto, pero eso toma mucho tiempo.

Si el cliente está pagando a un equipo para desarrollar software, ¿por qué también deben hacer trabajo para sacar el producto? Si el cliente tiene que hacer parte del trabajo por el que está pagando al equipo, ¿no puede exigir legítimamente un precio reducido, verdad?

El cliente no está haciendo trabajo tanto como estar involucrado en la creación del producto para que los desarrolladores entiendan para qué se está utilizando. Quieren que el producto sea lo más útil posible para el cliente, y la única persona que sabe qué es lo más útil para el cliente es, bueno, el cliente.

Espero que esto ayude.

La cascada es excelente para proyectos repetibles probados en el tiempo. Todavía se está utilizando activamente en proyectos de construcción y proyectos llave en mano donde el proceso es altamente predecible debido a la experiencia. Por otro lado, Agile es excelente para el desarrollo de software donde generalmente hay muchas incógnitas cuando comienza el proyecto, los requisitos cambian, la competencia sube el juego y siempre necesitarás una metodología ágil para responder. Como alguien dijo arriba, míralo como una especie de tendencia evolutiva. Saludos

Soy principiante aquí, pero cuando comencé a gestionar proyectos, me dieron un proyecto simple y estaba practicando el método de cascada. Es bastante eficiente y rápido de entregar. Pero luego pasé a un proyecto de nivel medio, entonces usé el método de sprint, y así sucesivamente. La conclusión es, en mi opinión, la cascada se adapta a proyectos simples y es mejor de esa manera.