Cascada pasa tiempo en un diseño, a continuación, escribir el código, luego las pruebas y, finalmente, la liberación. Pero Agile hace exactamente el mismo conjunto de pasos, es solo que cada uno es más pequeño.
Agile no es una entidad única, sino un paraguas para muchas metodologías diferentes.
En al menos algunos de ellos, como han notado otros, estas "fases" se superponen mucho más y están en un orden normal algo diferente.
De hecho, en XP, el orden es más o menos:
- pruebas (TDD/prueba primero)
- código
- diseño (refactoring)
- de repetición y, finalmente, liberar
que tipo invierte la mayor parte de la secuencia.
Y la prueba, el código y el diseño se realizan en una calidad más fina que la versión.
Una pieza clave del enfoque Agile consiste en aprender de cada lanzamiento y utilizarlo para dejar que el diseño más grande emerja en lugar de tratar de predecirlo al principio.
Pero Waterfall también lo hace. Es solo que en lugar de aprender cada 3 o 4 semanas, el equipo de Waterfall solo aprende cada 6 o 9 meses. Pero el diseño de Waterfall aún emerge. Es decir, la versión 2 de la cascada reflejará lo que se aprendió en la versión 1. Por lo tanto, el proceso no es diferente, es solo que se ejecuta a una velocidad diferente.
Esto depende en gran medida de la práctica. Como se describe en DOD-STD-2167A, (Sección 4.1.1), el modelo de cascada sí permite que las fases del proceso de desarrollo se superpongan e iteren (en resumen, sean algo ágiles). Pero la práctica más real se perdió eso, y no hubo aprendizaje hasta el final del proyecto.
Agile se centra en la estrecha colaboración con el cliente. Pero Waterfall también lo hace. Es solo que dado que la cascada tiene un tiempo de iteración más largo, una lista enumerada de requisitos en la forma de un contrato es más necesaria para mantener a todos en la misma página durante un largo período de tiempo. Pero, de nuevo, esto es solo un artefacto de frecuencia. Cuanto mayor es la frecuencia de la entrega, menor es la necesidad de un contrato.
De nuevo dependiente de la práctica. No veo en la especificación mencionada anteriormente mucha mención de las responsabilidades del cliente, y mucho menos continuamente.
Como señaló Jerry Coffin en un comentario, Waterfall es de hecho un hombre de paja que solía argumentar a favor de Agile (como de hecho lo estoy usando ahora ...), pero vale la pena mirar este documento y pensar en qué implica y cómo se ha aplicado.
Lo que muestra esta especificación es un enfoque intenso en contratos, entregas y mantenimiento de planos y documentos, y siguiendo el plan. Y creo que que sí se llevó a la práctica.
El contraste con ágil no es el timeboxing, sino un cambio en los valores.
Como The Agile Manifesto proclama:
estamos descubriendo mejores formas de desarrollar software por hacerlo y ayudar a que otros lo hagan. A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas
de software que trabajan sobre una amplia documentación
Colaboración con el cliente durante la negociación del contrato
Respondiendo al cambio sobre seguir un plan
Es decir, mientras haya valor en los artículos en a la derecha, valoramos los artículos a la izquierda m mineral.
Curiosamente, esta declaración de valores no dice nada sobre la frecuencia de entrega (aunque la siguiente sección "Principios" lo hace). Es hace Sin embargo, cambia el sistema de valores de planes, documentos y contratos y vuelve a donde pertenece, en realidad la entrega de software en funcionamiento.
La liberación frecuente es un mecanismo para cumplir estos valores.
Si trabajó en "mini-cascadas" sería de hecho un poco más ágil que la cascada BDUF de paja. Pero la frecuencia de la entrega ciertamente no es toda la historia.
Temas de discusión como este deberían ser wikis. –
Hablar de las diferencias con respecto al modelo de cascada es una tontería: desde el primer día ha sido un chapuzón para las personas contrastar con lo que defienden. Creo que la primera descripción del modelo de cascada fue en: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf, que lo describe solo como un contraste con el oh tan inevitablemente superior método defendido por el autor. –
No me repito en una respuesta: debe distinguir entre las versiones y estar listo para ser lanzado: http://www.andybrandt.net/637/to-release-or-not-to-release – Andy