Cascata ou Caos? Desvendando o Modelo Clássico de Desenvolvimento! 😱

O modelo Cascata 🌊 é um veterano no mundo do desenvolvimento de software. Sua abordagem passo a passo, como uma cachoeira descendo 🏞️, pode ser tentadora pela simplicidade. Mas cuidado! Essa rigidez pode se tornar uma armadilha 🪤 se os requisitos mudarem no meio do caminho.

Imagine construir uma casa 🏠 sem poder alterar a planta depois que a fundação foi lançada. Parece um pesadelo, certo? O mesmo pode acontecer com um projeto de software usando o modelo Cascata. Se os requisitos não forem 100% claros e estáveis desde o início, você pode acabar com um produto que não atende às necessidades do cliente.

Mas nem tudo são espinhos! 🌹 O Cascata funciona bem para projetos menores e com escopo bem definido. Sua documentação detalhada 📝 é um ponto forte, facilitando a manutenção e o entendimento do sistema.

Então, quando usar o Cascata? 🤔

  • Requisitos claros e estáveis ✅
  • Projeto de curto prazo ⏱️
  • Equipe experiente com o modelo 💪

Se o seu projeto não se encaixa nesses critérios, considere metodologias ágeis como Scrum ou Kanban. Elas oferecem mais flexibilidade para lidar com mudanças e entregar valor ao cliente mais rapidamente. 🚀

manierohá 22 dias

Algumas observações:

  • Waterfall full quase nunca foi usado, então essa luta é contra um fantasma, as pessoas falam para não usar algo que ela ouviu falar, leu em algum lugar que é ruim.

    Waterfall só foi usado nos primórdios da computação quando os projetos tinham que ser minúsculos porque o computador não tinha capacidade de lidar com projetos grandes, quase tudo eram jobs, quase um precursor dos microsserviços*. Em poucos projetos maiores foram usados e se percebeu logo que ele era complicado e não funcionava bem na maioria deles. Alguns projetos funcionavam porque o usuário era alguém ali do departamento de computação mesmo, eles podiam congelar os requisitos com facilidade. A maioria das pessoas falam sem entender o contexto, mais ou menos o que acontece com comentários, nomes de variáveis e outras coisas, vira tudo "boa prática" que a pessoa não entede o que é.

  • Uma pergunta provocativa minha no SOpt teve boas respostas, escolhi a que foi postada antes entre as melhores, mas muitas são complementares e devem ser lidas como um todo (é assim que se usa o SO), e ver também a Wikipedia e outras fontes (é assim que se aprende algo sem viés). https://pt.stackoverflow.com/q/3274/101.

    Lá fala como é virtualmente impossível usar Waterfall nos dias de hoje ou mesmo no passado em boa parte dos cenários, então nem deveria se discutir isso. Outra resposta fala em usar o que foi chamado de Micro Watterfall (bom nome), que no fundo é quase o oposto do full Waterfall e muito próximo de Agile. Se pesquisar nos locais já citados verá que existem modificações no Waterall tradicional que o torna bem mais interessante, e a mudança é quase que apenas dois detalhes.

  • São faz sentido comparar Waterfall com Scrum porque o primeiro é um modelo de desenvolvimento e o segundo é uma ferramenta de gereciamento do processo.

  • Veja como são as tais cascatas que a metodologia prega. Você faz diferente disto?

    Fases da cascata de Waterfall - Requisitos - Projeto - Implementação - Verificação - Manutenção

    Se você fizer isso em ciclos pequenos e não o projeto todo, que é o que "todo mundo" "sempre" fez, de forma mais estruturada ou não, e se não quiser documentar cada detalhe, está fazendo essencialmente a mesma coisa mas de forma Ágil.

    Existe uma necessidade de um grupo destruir o que existia antes para se consolidar, mas no fundo quase tudo que é moda hoje é só uma variação do que já existia, não tem muito como inventar coisas completamente novas.

    Existem outras variações que seguem a mesma linha do Waterfall mas não são consideradas Ágeis e talvez encaixe melhor em algum cenário. Só uma pessoa experiente, livre de viés, consegue decidir oque é melhor. Isso é raro, eu e váriaas pessoas que conheço que estão na área há décadas não costumam ter experiência com tudo, portanto não conseguímos escolher o que é melhor com propriedade, vamos no que parece mais sensato. Há 40 anos atrás eu segui esses passos e fazia em pequenos ciclos sem burocracia, ou seja eu sou Ágil antes do termo ser cunhado.

  • Scrum é considerado por muitos como uma ferramenta não Ágil e que burocratiza e engessa o desenvolvimento sem trazer nenhuma vantagem expressiva. Só o fato de existir um livro que fala em entregar o dobro na metade do tempo já mostra como é algo marketeiro demais. Veja mais: https://www.tabnews.com.br/MisterF/scrum-nao-e-bala-de-prata-como-a-agilidade-mal-aplicada-destroi-equipes. Boa parte dos softwares mais destacados do mercado não usam Scrum e são feitos por quem sabe muito bem o que está fazendo. Talvez o Scrum ajude mais equipes disfuncionais. O tal do Micro Waterfall talvez seja quase a mesma coisa que o Scrum. Já o Kanban+Lean talvez seria o Scrum realmente Ágil ou próximo disto.

  • TDD, que é tido como uma das ferramentas Ágeis, é algo que incentiva o Waterfall, mesmo que seja o Micro. Ou seja, você precisa de requisitos congelados para funcionar bem. Se você tem que ficar mudando os requisitos, mudar os testes do TDD e depois implementar a novidade, mas em cima do que já existe, pra mim não é TDD mais. Ou a pessoa engessa o desenvolvimento ou ele está fazendo outra coisa. Até compiladores de linguagens de programação que tem requisitos claros e estáveis não costumam usar TDD.

  • Ser Ágil não é ser rápido, é ser adaptável. Falou em velocidade já está fazendo errado. Inclusive ser ágil tende a ser mais lento. Claro que se fizer Waterfall tradicional e depois algo der errado pode consumir muito mais tempo, e claro que se documentar demais fica mais lento. Por falar nisso, muitos dos chamados Agile coaches pregam muita burocracia, porque senão eles têm um trabalho muito pequeno a fazer e serão pouco necessários.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).