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

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?

  

  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).