El método de cascada es ciertamente viable y es tan sólido filosóficamente como cualquier otro enfoque. Recuerde que Waterfall ha existido por mucho más tiempo que Agile, pero tenga en cuenta que este no es un argumento para determinar si una metodología es mejor que otra.
Utiliza el método Waterfall cuando se tiene una comprensión muy clara de todo el dominio del problema y lo que el cliente desea lograr en un paquete de software. Probablemente haya cotizado un precio fijo al asumir el contrato, y su cliente entiende 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 distintas etapas de desarrollo, y es a menudo el caso de que cada etapa sea completada por un equipo diferente, a veces incluso una empresa diferente, cada una de las cuales no necesariamente se encuentra en Contacto con los demás. Con frecuencia se ve que Waterfall se aplica con buenos resultados en proyectos militares y gubernamentales cuando se licitan a contratistas externos. Cuando Waterfall y otros enfoques similares obtienen una mala reputación es cuando los desarrolladores se encuentran con 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 culpa de la metodología, sino de su aplicación.
La comparación entre Agile y cualquier metodología es falsa. Agile 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 cree que minimizar el cambio en el software es una opción viable para aquellos que desean entregar software valioso?
Cada oportunidad de minimizar el cambio es valiosa tanto para el desarrollador como para el cliente. Los cambios pueden hacer que un programa se deslice, o que las funciones se omitan para cumplir un programa. Es la forma en que gestiona los efectos del cambio que influye en el valor de sus proyectos.
¿O es realmente la pregunta sobre 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 elige un método que funcione para usted. Si te gusta el enfoque particular, síguelo. Si no se ajusta a tus necesidades, cámbiala. La manera en que se desarrolla el software realmente se reduce a tratar de hacer el mejor uso de los recursos que tiene a mano, y a minimizar las prácticas que pueden llevar a su proyecto al fracaso, y a menudo se da cuenta de que necesita cambiar su método para adaptarlo al proyecto particular a la mano.
Realmente una cosa es decir "Ok, ahora somos ágiles", y otra muy distinta es vivir y trabajar según la filosofía que Agile es. Ya sea que utilice Waterfall, Incremental, Spiral, SCRUM, XP, FDD o cualquier otro método, básicamente está en Agile donde valora:
- Personas e interacciones sobre procesos y herramientas
- Software de trabajo sobre documentación completa
- Colaboración del cliente en la negociación del contrato
- Respondiendo al cambio siguiendo un plan
y donde reúnes tus herramientas, método y experiencia para aplicar estos valores con éxito.