El método de la cascada es ciertamente viable y es tan filosóficamente sólido como cualquier otro enfoque. Recuerde que Waterfall ha existido mucho más tiempo que Agile, pero tenga en cuenta que este no es un argumento para afirmar si una metodología es mejor que otra.
Utiliza el método Cascada cuando tiene una comprensión muy clara sobre todo el dominio del problema y lo que el cliente quiere lograr en un paquete de software. Probablemente haya cotizado un precio fijo al contratar el contrato, y su cliente comprende que no puede desviarse de los requisitos acordados. Su proceso es estrictamente uno que fluye a través de una serie de aprobaciones entre las diversas etapas de desarrollo, y a menudo es el caso de que cada etapa la complete un equipo diferente, a veces incluso una compañía diferente, cada una de las cuales puede no necesariamente en contacto con los demás. A menudo se ve que Waterfall se aplica con buenos resultados en proyectos militares y gubernamentales cuando se licitan a contratistas externos. Donde Waterfall y otros enfoques similares obtienen una mala reputación es cuando los desarrolladores tienen problemas, como una estimación deficiente, horarios planificados sin tiempo de contingencia o una comprensión deficiente o incompleta del dominio del problema. El problema nunca es realmente una falla de la metodología, sino de su aplicación.
La comparación entre Agile y cualquier metodología es falsa. Ágil no es una metodología, es una filosofía, o quizás sería mejor decir que es un término general que representa una forma diferente de ver cómo se desarrolla el software. Una metodología es simplemente una herramienta, y como tal su valor siempre será menor que los individuos y las interacciones que están en el corazón de lo que significa ser ágil .
¿Alguien realmente piensa que minimizar el cambio en el software es una opción viable para aquellos que desean entregar un software valioso?
Cada oportunidad para minimizar el cambio es valiosa tanto para el desarrollador como para el cliente. Los cambios pueden hacer que un cronograma se deslice o que se omitan funciones para cumplir con un cronograma. Es cómo maneja los efectos del cambio lo que impacta en el valor de sus proyectos.
¿O se trata realmente de qué tipo de prácticas funcionan mejor en nuestras situaciones para gestionar el cambio inevitable?
Sus prácticas pueden ayudar en la gestión del cambio, o pueden ignorar el cambio por completo. Lo que importa es la combinación de sus prácticas de desarrollo y la gestión de su relación con sus clientes, y si estas cosas funcionan juntas de manera efectiva para todas las partes involucradas.
Aquellos de nosotros que somos para todos los efectos Agile entendemos que usted elige un método que funcione para usted. Si te gusta un enfoque particular, síguelo. Si no se ajusta a tus necesidades, cámbialo. La forma en que elabora el software realmente se reduce a tratar de hacer el mejor uso de los recursos que tiene a mano, y minimizar esas prácticas que pueden conducir a su proyecto hacia el fracaso, y a menudo descubre que necesita cambiar su método para adaptarse a proyecto particular a la mano.
Realmente es una cosa decir "Ok, así que ahora somos ágiles", y otra totalmente distinta es vivir y trabajar según la filosofía que es Agile. Ya sea que use Waterfall, Incremental, Spiral, SCRUM, XP, FDD o cualquier otro método, básicamente es ágil donde valora:
- Individuos e interacciones sobre procesos y herramientas
- Software de trabajo sobre documentación completa
- Colaboración del cliente sobre negociación de contrato
- Responde al cambio sobre el siguiente plan
y dónde reúne sus herramientas, método y su experiencia todos juntos para aplicar estos valores con éxito.