Bom, o Método Waterfall , também conhecido como o Método Cascata , ganhou força no mercado a partir da década de 1970, sendo por muito tempo considerado como a metodologia tradicional de planejamento e desenvolvimento de software. De acordo com esse método, o projeto é dividido em etapas, onde uma etapa depende da finalização da etapa anterior, sendo que em cada uma delas só pode seguir a partir da aprovação dos stakeholders. Por isso, as dificuldades encontradas na Metodologia Waterfall no desenvolvimento de um Software são:
- Inflexibilidade - Trata-se de um método rígido, onde o teste do software é realizado apenas nas últimas fases, o que significa que para modificar qualquer coisa se faz necessário voltar pras etapas anteriores e finalizar as pendências geradas devido às modificações;
- Não há como voltar nas etapas - A única maneira de contornar essa desvantagem é encontrar uma maneira de concluir o trabalho na etapa atual em que ocorreram as dificuldades. Se isso não for possível, a equipe terá que reiniciar todo o projeto para acrescentar as novas informações ou corre o risco de invalidar as etapas anteriores, pois elas têm dependências em cascata;
- Exclui usuários finais e clientes - O modelo em cascata enfoca os processos internos do trabalho, valorizando a eficiência do projeto e da equipe, sem levar em conta os desejos e necessidades do cliente (que talvez até mudem ao longo do processo). Não há espaço para compartilhar ideias ou opiniões porque os esboços passam a fazer parte das etapas de planejamento;
- Produto testado apenas na conclusão do projeto - No Waterfall, quaisquer problemas ou obstáculos só são vistos na hora do teste. Até lá, há muito espaço para que as dificuldades passem despercebidas por toda a equipe, que fica mais focada em aspectos técnicos e no escopo;
- Projeto com prazo longo - Como cada fase requer a conclusão de 100% de todas as tarefas e documentação antes da transição para a próxima etapa, os projetos podem levar muitos meses para serem entregues. Essa desvantagem é a razão pela qual projetos complexos evitam o uso do modelo em cascata. Se ocorrer algo inesperado, como já dito nas outras 4 razões acima, algumas equipes podem ter que voltar ao ponto de partida, criando um déficit de tempo ainda mais significativo;
- Grande custo com Mão de Obra e tempo - Se a equipe esperar meses até que o time tenha realmente desenvolvido o produto – ou mesmo um Mínimo Produto Viável (MVP) –, antes de ver se é comercial e tecnicamente operável, e que o usuário ficará satisfeito, o risco todo ficará para o final do processo. Resultado: todo mundo gastou tempo e dinheiro para construir um produto que pode ser inviável.
