Esqueça o Agile por um minuto, pense no que se entende por "cachoeira".
Há uma fase de requisitos, na qual todos tentam descobrir quais problemas o produto final precisa resolver. As pessoas discutem sobre isso por um tempo e, em seguida, todos assinam um conjunto de requisitos. Nesse ponto, seu escopo é definido, os contratos são assinados e o cliente pode se afastar e esperar que você crie um produto que atenda aos requisitos definidos.
Em seguida, há uma (ou talvez duas) fase (s) de projeto. Os designers (que podem ou não ser os desenvolvedores) discutem sobre COMO o sistema deve se unir para atender aos requisitos de assinatura. Podem ocorrer problemas se eles não entenderem um requisito, o que pode significar que eles precisam voltar ao cliente, potencialmente reabrindo a fase de requisitos (e obtendo outra rodada de aprovação) ou, pelo menos, colocando o gerenciamento de mudanças em ação . Freqüentemente, os designers simplesmente dão seu melhor palpite. Eles podem criar um modelo de dados lógicos e muita UML descrevendo um novo sistema e como ele deve funcionar. Então eles assinam.
Agora, os desenvolvedores começam realmente a codificar, com base no design assinado. Podem ocorrer problemas se eles não entenderem o design, o que pode significar que eles precisam voltar ao designer, potencialmente reabrindo a fase de design (e obtendo outra rodada de aprovação) ou, pelo menos, colocando o gerenciamento de mudanças em ação . Os projetistas, por sua vez, podem perceber que a confusão realmente remonta aos requisitos, o que significa que eles precisam reabrir as discussões sobre os requisitos, aprovações e gerenciamento adicional de mudanças. Freqüentemente, os programadores (que têm um prazo aproximado) simplesmente fazem seu melhor palpite. Eles fazem o que podem para criar código funcional. Em seguida, eles o liberam para teste.
Agora, a fase de teste do sistema é iniciada. Os testadores testam com base em sua compreensão dos requisitos e design e registram o que eles percebem como defeitos em um sistema de rastreamento / gerenciamento de alterações, fazendo com que os desenvolvedores comecem a se desenvolver novamente, a menos que considerem o problema como uma falha de design, que a envia de volta ao design, etc ... Eventualmente, os testes do sistema passam e são desconectados.
Por fim, o cliente volta e faz testes de aceitação do usuário no novo sistema. É aqui que eles decidem se a solução testada pelos testadores, desenvolvedores desenvolvidos e projetados é realmente o que eles querem. Caso contrário, é possível que você volte à fase de design ou mesmo revisite os requisitos.
A idéia por trás da cascata é que é difícil (e muito indesejável) voltar depois que uma fase estiver concluída. Pessoas diferentes geralmente estão envolvidas em diferentes fases, de modo que existem várias transferências - cada uma das quais apresenta muitos riscos de má interpretação e perda de informações. Há também uma lacuna significativa entre quando os clientes dizem o que querem e quando veem o que foi construído; nesse momento, os requisitos reais podem muito bem ter mudado.
As metodologias ágeis concentram-se em uma forte comunicação e cooperação entre todas as partes interessadas. O princípio "Colaboração do cliente sobre negociação de contrato" significa que você não precisa passar por uma série de aprovações e transferências, mas deve simplesmente trabalhar em conjunto com o cliente, cada iteração determinando os requisitos para uma peça do quebra-cabeça. e imediatamente formar testes, um design e um código de funcionamento - com todos os participantes se comunicando o mais diretamente possível (eliminando custos e riscos de transferência). O código de trabalho é rapidamente testável pelo cliente, eliminando os riscos de atraso de tempo. Todas as atividades acontecem em um redemoinho colaborativo, não em um fluxo descendente.
Para uma excelente visão geral do que as metodologias ágeis tentam fazer, eu recomendo o Agile Software Development: The Cooperative Game da Allistair Cockburn .