Dizendo adeus ao Agile
(lewiscampbell.tech)- Uma reavaliação crítica da metodologia Agile que dominou a indústria de software, argumentando que na prática ela não passava de princípios vagos e de uma reembalagem de problemas já resolvidos
- A oposição ao Waterfall é em grande parte ilusória, e conceitos centrais como desenvolvimento iterativo e participação do cliente já haviam sido apresentados em pesquisas da década de 1970
- O Agile sempre foi definido apenas como o oposto do modelo Waterfall, embora as limitações do Waterfall já fossem amplamente conhecidas desde os anos 1970
- Com o surgimento recente dos grandes modelos de linguagem (LLM), o desenvolvimento orientado por especificações (Spec-Driven Development) volta a ganhar importância, impulsionando o desenvolvimento centrado em documentação
- O slogan ágil de “software em funcionamento mais que documentação abrangente” agora está sendo substituído pela percepção de que “documentação abrangente produz software em funcionamento”
- É hora de superar a ambiguidade deixada pelo Agile e voltar a princípios claros e a uma abordagem de engenharia
RIP Agile, we hardly knew ye.
And I mean that literally - because no one was ever clear on what it was.
Agile, descanse em paz. Mal chegamos a te conhecer.
E digo isso literalmente — porque ninguém jamais soube com clareza o que ele era.
O problema de identidade do Agile
- O Agile foi uma grande onda que varreu toda a indústria de software, mas na prática se espalhou mesmo sem que seu significado estivesse claramente definido
- Sempre que surgiam questionamentos, repetia-se a resposta: “isso não é Agile de verdade”
- Ao ler de fato o Manifesto Ágil (2001), quase não há diretrizes concretas; ele se resume a aforismos vagos como “colaboração com o cliente mais que negociação de contratos”
- Princípios como “aceite mudanças de requisitos mesmo no fim do desenvolvimento” são comercialmente irrealistas
- Sob a alegação de um “True Agile”, os problemas da prática foram sendo descartados como se não tivessem relação com o manifesto
- Se a indústria Agile não pratica o Agile corretamente, e o próprio manifesto carece de significado, então fica a dúvida sobre o que o Agile realmente é
“Um fantasma do Waterfall assombra o software”
- O Agile sempre se definiu apenas pelo que não era (Waterfall): se você não faz Agile, então está fazendo Waterfall, e Waterfall não funciona
- Porém, o fato de que Waterfall não funciona já era conhecido desde 1970, e Winston W. Royce explicou exatamente o porquê
- Royce recomendava como alternativa: começar pelo projeto do programa, criar protótipos de software para refinar requisitos e manter a participação formal, profunda e contínua do cliente
- Tudo isso mais tarde foi apresentado como inovação do Agile, mas na verdade já estava escrito em 1970, no ano seguinte à chegada do homem à Lua
- Nota 1: como os programadores do Apollo Guidance Computer conseguiram tal feito sem story points e sem conhecer o princípio de que “atenção contínua à excelência técnica aumenta a agilidade”?
O artigo de Bell-Thayer de 1976 e a história do desenvolvimento iterativo
- O artigo de Bell e Thayer de 1976 é citado como o primeiro a usar o termo "Waterfall", e o próprio termo era usado como exemplo do que não se deveria fazer
- A conclusão do estudo empírico do artigo: defeitos nos requisitos só são descobertos no desenvolvimento de software quando se tenta satisfazer os requisitos por meio do projeto
- O desenvolvimento iterativo não era novidade e vinha sendo refinado continuamente por décadas antes do Agile
- Mesmo antes de o manifesto libertar a indústria, Waterfall já não era estado da arte, e ninguém colocava seriamente em dúvida a efetividade de requisitos e especificações
A ascensão do desenvolvimento orientado por especificações (Spec-Driven Development) e o pós-Agile
- Com a disseminação dos LLM, ganha força novamente a prática de programadores escreverem especificações (specifications)
- Como LLM são vulneráveis a entradas ambíguas, descrever o problema com clareza passou a ser uma forma de ajudar na geração de código correto
- Se o Agile enfatizava “software em funcionamento mais que documentação abrangente”, o desenvolvimento orientado por especificações propõe a tese oposta: "documentação abrangente produz software em funcionamento"
- Royce já apontava em 1970 que documentação, especificação e projeto são o mesmo conceito até o momento da codificação; se a documentação é ruim, o projeto também será ruim
- Ele enfatizava que, se a documentação não existe, o projeto também não existe
- Ao revisitar os estudos de 1970 e 1976, fica evidente que o Manifesto Ágil de 2001 não trouxe um insight novo
- O Agile apenas substituiu abordagens de engenharia já existentes por definições vagas e embalagem comercial, sem produzir progresso substancial
- Os artigos daqueles engenheiros continham um significado muito mais claro
- Agora que o desenvolvimento de software continua mudando e evoluindo, é hora de mandar o Agile para a história e mudar para uma nova perspectiva
- Precisamos voltar aos princípios claros e ao pensamento de engenharia deixados pelos engenheiros sérios do passado
21 comentários
Não sei por que tratam metodologias como se fossem escrituras sagradas. Acho que o autor original também não deixava de ser dogmático, apenas seguia uma direção diferente.
Acho que a conclusão está um pouco exagerada. Comercialização ou formalização podem ser o problema, mas isso não significa que ferramentas como sprint ou backlog tenham deixado de ser úteis. Elas também ajudaram a consolidar uma cultura de reuniões mais horizontal e orientada a objetivos. Concordo que o SDD se tornou mais importante, mas como a própria especificação pode ser escrita de forma rápida e colaborativa com a IA, isso ainda continua sendo ágil. Só que o sprint de duas semanas foi encurtado para algumas horas; a essência de iterar e ir lapidando continua a mesma, na minha opinião.
Concordo.
Só de pensar em romper com a tomada de decisão vertical e em melhoria iterativa em ciclos curtos, a mensagem que isso nos deixa já é enorme (e, claro, o mesmo vale para as técnicas/ferramentas de gerenciamento de projetos).
A conclusão de que 'o Agile em si não trouxe novos insights e acaba distorcendo todos que defendem o Agile como fanboys cegos do Agile' me parece extrema demais.
Concordo. O ágil continua válido. Parece papo de gente que nunca trabalhou na prática e fala ao vento.
Que texto bobo. O ponto principal é que a própria spec. deve ser escrita de forma ágil... Agile é se adaptar rapidamente às mudanças nos requisitos do cliente.
É por causa de pessoas com esse tipo de mal-entendido e imaginações superficiais sobre agile que tanto o agile quanto a cultura de desenvolvimento acabam se desviando do caminho certo.
O que significa exatamente escrever a própria spec de forma ágil?
O ponto principal daquele texto é que, desde o começo, eu simplesmente não entendo o que é agile. Só ficam falando que agile tem essas características e que é preciso fazer isso e aquilo, mas até hoje nunca vi um texto que mostrasse de fato “este é um produto criado com a metodologia agile”. Mesmo olhando o manifesto, achei tudo meio nebuloso. Que tal mostrar um exemplo?
Isso é conteúdo básico que aparece na maioria dos livros sobre métodos ágeis, como Extreme Programming de Kent Beck e Scrum de Jeff Sutherland. Você também pode olhar as user stories. Muita gente aparentemente não sabe que a base do ágil são sprints curtos e demos para se adaptar rapidamente aos requisitos do cliente.
São os itens 3 e 4. Escrever a especificação em detalhes tem profundidade infinita. O ponto é que existe um nível adequado para cada organização. Quando olhamos a história de como serviços de sucesso foram criados, sei que em 99% dos casos o principal é justamente não colocar energia demais em escrever a especificação com precisão absoluta. A ideia é não ficar preso a isso. Basta ver como Summoners War, Dungeon & Fighter, Zigbang e Lineage foram feitos.
E se o ciclo waterfall rodasse em apenas um dia?
Ultimamente tenho visto esse tipo de caso com mais frequência.
Terrivelmente, parece ser o que mais vejo com frequência...
Na Coreia, ágil não é nada além — nem menos — de uma ferramenta para pressionar os prazos dos desenvolvedores.
Dependendo dos critérios, todo mundo é ágil. Fico pensando se já houve uma época como esta, em que fazemos deploy tão rápido e recebemos feedback.
Não sei o que sobra do Agile além das implantações em ciclos curtos.
Backlog e sprint já existiam antes, só que em outros formatos, e a comunicação com o cliente tem muitos pontos que não batem com a realidade. No fim, acho que as melhorias de desenvolvimento vieram muito mais com o aprimoramento de DevOps do que com o Agile.
Este próprio texto não é ágil!
Como não é como se nunca precisássemos ler código, dessa perspectiva a ideia de que código é melhor do que documentação parece válida; e, como documento no papel de instrução precisa ser lido pelo LLM, que é o agente de implementação, nesse ponto também concordo. Portanto, no fim das contas, acho que a conclusão é que ambos são importantes ao mesmo tempo.
O problema atual dos produtos gerados por LLM é a dívida que se acumula na fase de operação. Para uma operação contínua, os desenvolvedores precisam se envolver com o código e, para isso, ainda acho que o código precisa ser capaz de substituir a documentação.
Para apresentar uma objeção com cuidado, eu não acho que código possa substituir documentação. As linguagens de programação ainda não têm a riqueza de expressão e a capacidade de comunicação da linguagem natural e, na prática, quem vai ler todo esse código?
Ter um código que possa substituir documentação é uma esperança e um desejo, mas é uma Torre de Babel impossível de alcançar.
Parece melhor, antes, se dedicar com afinco a OOAD.
Por outro lado, também acho difícil que a linguagem natural substitua o código. A linguagem natural, embora seja mais rápida que o código, é abstrata demais. Para a computação, no fim das contas, é preciso preencher os detalhes, e não parece viável que a linguagem natural cumpra esse papel.
Ao escrever software, o problema não é tanto a abstração, mas a ambiguidade. A linguagem natural é inerentemente ambígua. Também é passível de múltiplas interpretações. Talvez seja por isso que as tentativas de programar com linguagem natural não funcionem muito bem. Nessa situação, a linguagem natural substituir código é algo fora de cogitação.
Entendo e concordo com a sua opinião.
Claramente há partes que não podem ser substituídas por código.
Nesse sentido, tentando explicar de uma forma um pouco diferente, o que eu queria dizer é que um código com alta legibilidade faz com que não seja necessário produzir documentação.
A documentação que se acumula ao longo do tempo no software também gera carga cognitiva para os desenvolvedores. O ponto principal é reduzir o trabalho de ficar alternando entre código e documentação.
Não acho que seja possível deixar apenas o código.
Acredito que isso pode variar conforme o contexto e a situação enfrentada.
Obrigado pelo comentário.
Comentários do Hacker News
Com Agile, vi um fenômeno interessante
Quando falha, a interpretação é do tipo “não fizemos o suficiente”.
Vi o mesmo padrão em nuvem, microsserviços, políticas de austeridade etc. — a causa do fracasso é sempre falta de execução, nunca a abordagem em si; a crença é que ela jamais pode estar errada
Se o time tentou Agile e não deu certo, aparece a defesa de que “aquilo não era Agile de verdade”. No fim, Agile vira um conceito incapaz de falhar
O Agile Manifesto fala apenas de valores e princípios. O problema é a cultura organizacional que tenta forçá-lo a virar processo
Uma estrutura que leva a olhar para dentro quando há fracasso não é necessariamente ruim. Em vez de culpar fatores externos, pode ser um sistema saudável por estimular autorreflexão
O roadmap prometido ao cliente e a capacidade de reagir com flexibilidade dificilmente coexistem. Na prática, organizações centradas em planejamento só imitam Agile
Quando falha, a conclusão vira algo como “deveríamos ter usado mais agentes”. Soa como a piada de que “nunca há tokens suficientes”
Passei a ter medo da formalização do Agile
Já administrei com sucesso um time de 40 pessoas, mas o verdadeiro Agile se resume a só quatro frases — pessoas, software funcionando, colaboração com o cliente e resposta a mudanças
O problema é que o “Agile” com A maiúsculo acabou se degradando em um processo inflexível
Quando o número de pessoas cresce, alinhar objetivos fica difícil e, no fim, controle e procedimentos se tornam necessários
Chegavam até a restringir a permissão para criar tickets, algo muito distante de qualquer flexibilidade
Sem documentação suficiente, a manutenção se torna impossível e tudo acaba virando desenvolvimento YOLO
O Agile nas grandes empresas por onde passei era uma mentira
Um colega dizia: “se você adiantar o trabalho da próxima sprint, sempre termina no prazo”.
Ou seja, Agile na verdade funcionava como um sistema de produção de métricas mais do que de trabalho real
Os gestores ficavam satisfeitos só de ver os números subindo, e o produto virava um subproduto das estatísticas
Vale a pena reler o texto original do Agile Manifesto
Esse é o único ponto de consenso. Também é preciso lembrar o quão terrível era o waterfall antes do Agile
Foi a arma que pôs fim à era em que prazos e entregáveis fixos eram impostos
Se o time trabalha com autonomia, isso ameaça o lugar deles
Como Kent Beck disse em “Extreme Programming”, Agile era uma tentativa de evitar a tirania da onipotência imaginada
O waterfall do passado tentava prever tudo na fase de design e ignorava aprendizado e feedback
Mas, com o tempo, os rituais e formalismos do Agile encobriram sua essência
Eu ainda gosto de Agentic programming, mas no fim o que importa é o papel humano de conectar o contexto
O artigo original era confuso
Dizia que Agile não trouxe nada de novo e depois afirmava que, se LLMs escrevem código, então Agile morreu
Mas o núcleo do Agile é reconhecer especificações incompletas e melhorar iterativamente
Esse princípio continua válido
Agile é apenas uma de suas variações; o que houve foram muitas implementações ruins
Bons produtos no fim surgem do ciclo de especificação → aprendizado → correção
Procedimentos como Backlog Grooming e Sprint Review acabam inibindo mudanças
Desenvolvimento baseado em spec provavelmente não vai durar muito
Ainda é mais rápido criar software funcionando e iterar — no fim, é o retorno do Agile
A qualidade das specs melhorou, e revisar ficou mais fácil do que ler código
Veja o link do GitHub
No manifesto não existe nada como Daily Standup ou Agile Coach
A essência é “não faça microgerenciamento dos programadores”
Em outras palavras, a mensagem é: dê ambiente e confiança a indivíduos motivados
Os criadores, como Kent Beck e Martin Fowler, originalmente queriam diretrizes flexíveis
Mas, com o tempo, isso virou negócio, surgiram seguidores dogmáticos e a confusão aumentou
O sucesso ou fracasso no fim depende da capacidade e da postura das pessoas
Até a duração das sprints deveria ser ajustada ao contexto, e, se não houver spec, o próprio time deve criá-la
Mesmo na era da IA, se houver alguém usando Agile com sabedoria, ele continua válido
Fiquei curioso sobre o que exatamente significa “escrever uma spec”
Todos os projetos Agile em que trabalhei tinham documentos de design, e os tickets derivavam desses documentos
Desenvolvimento orientado a tickets sem documentação deve ser um inferno
Cada um interpreta como quer
Uma abordagem centrada em tickets seria, na verdade, mais próxima do Agile puro
No Agile falso, documentos feitos por PO ou PM fingem ser a verdade
A forma que você descreveu é justamente a mais próxima do que eu quis dizer com “escrever uma spec”