14 de abril de 2026
RIP Agile, mal conhecíamos você.
E quero dizer isso literalmente – porque ninguém nunca soube ao certo o que era.
O Agile invadiu nossa indústria como um tsunami. Mas sempre que era questionado, uma voz (talvez emanando de uma brecha nas nuvens?) invariavelmente nos dizia “ah, mas isso não é True Agile – O Manifesto não diz nada sobre Daily Standups, nem Agile Coaches”. No entanto, se alguém ler o Manifesto Ágil (2001), esta fonte da nossa iluminada Nova Era do Software, inevitavelmente descobrirá que ele não nos diz muita coisa. Na melhor das hipóteses, era uma sequência de lugares-comuns vagos (“Colaboração do cliente acima da negociação de contratos”) e, na pior, era comercialmente impraticável (“Mudanças de requisitos bem-vindas, mesmo no final do desenvolvimento”).
Portanto, se a indústria ágil não estava praticando Agile corretamente e o manifesto em si era quase desprovido de significado, então o que era exatamente?
“Um espectro assombra o Software, o espectro da Cachoeira”
Agile sempre foi definido principalmente em termos do que não era – e o que não era era Waterfall. Se você não estava fazendo Agile, você está fazendo Waterfall, e Waterfall Did Not Work.
Exceto que sabíamos que o Waterfall não funcionava desde 1970; e Winston W. Royce explicaram exatamente o porquê, recomendando, em vez disso:
- Comece com um design de programa.
- Faça um protótipo do software para coletar informações para refinar os requisitos.
- Envolver o cliente (“o envolvimento deve ser formal, profundo e contínuo”).
Todas essas coisas foram posteriormente reivindicadas como inovações Agile. Na realidade, foram escritos um ano após o pouso na Lua.
E mesmo nessa década não foi a única obra que se afastou de Cachoeira. Um artigo de 1976 de Bell e Thayer – que primeiro cunhou o termo “Cachoeira” – nos diz ao final de um estudo empírico:
Os tipos de problemas detectados nos requisitos mudaram durante a vida de um projeto de desenvolvimento de software. Os desenvolvedores de sistemas geralmente determinavam a deficiência de requisitos apenas quando tentavam atender aos requisitos com um projeto.
Portanto, está claro que o desenvolvimento iterativo não era novo e continuaria a ser refinado nas décadas anteriores ao Agile.. Cachoeira não era o estado da arte antes do Manifesto nos libertar. E ninguém duvidou seriamente da eficácia dos requisitos e especificações.
Desenvolvimento baseado em especificações
Para o bem ou para o mal, a disponibilidade de LLMs baratos treinados em enormes conjuntos de dados de programação alterou a forma como muitos de nós programamos computadores e, sem dúvida, mudou o espírito do software.
Um desenvolvimento inequivocamente positivo que se seguiu é que os profissionais de software estão escrevendo especificações novamente. LLMs – como muitos de nós – não funcionam bem com ambiguidade, e a especificação de problemas está provando ser uma ferramenta eficaz para gerar código correto. Agile nos disse “Software funcional com documentação abrangente”. O Spec-Driven Development está nos dizendo “Documentação abrangente cria software funcional”. E realmente, com LLM ou não, não há nada de novo sob o sol. Citação Royce:
Até o início da codificação, esses três substantivos (documentação, especificação, design) denotam uma única coisa. Se a documentação for ruim, o design será ruim. Se a documentação ainda não existe, ainda não existe design, apenas pessoas pensando e falando sobre o design, que tem algum valor, mas não muito.
Lendo 1970 e 1976, é preciso perguntar o que 2001 realmente nos traz. Ágil foi definido vagamente e comercializado como uma solução para algo já resolvido há meio século por engenheiros sérios cujos trabalhos faziam mais sentido. À medida que nosso campo continua a mudar – e esperamos evoluir – é hora de olhar para as coisas com uma nova perspectiva e colocar o Agile na lata de lixo da história, onde ele pertence.
Acha que posso ajudar sua empresa? Entre em contato ou visite meu site de consultoria!
Fonte: theverge
