20,5 Anos de XP e Agile (2020)
Agile e Extreme Programming (XP) são revisitados aqui após mais de 20 anos de prática, com desenvolvedores contrapondo os benefícios genuínos — desenvolvimento iterativo, testes automatizados, refatoração e colaboração mais próxima — ao cansaço da programação em dupla obrigatória e ao dogma rígido de processo. Muitos argumentam que, embora ideias centrais como ciclos curtos de feedback e CI/CD tenham se tornado comuns e valiosas, o “Agile” com A maiúsculo foi cooptado por burocracia, indústrias de certificação e rituais de gestão que aumentam o overhead sem melhorar os resultados. A questão central é se os métodos ágeis ainda ajudam as equipes a entregar software melhor hoje, ou se práticas flexíveis e específicas de contexto silenciosamente substituíram seus frameworks de marca.
Programação em Dupla e Práticas de XP
- Muitos acharam a programação em dupla em tempo integral exaustiva, invasiva ou incompatível com seu estilo de trabalho; alguns disseram que pediriam demissão em vez de fazê-la continuamente.
- Outros relataram produtividade e aprendizado máximos durante a programação em dupla intensa, especialmente no modo “professor/aluno” ou quando havia boa química.
- Vários observaram que a programação em dupla funciona melhor com uma boa cultura e uso voluntário; XP imposto é visto como arrogante ou dogmático.
- XP é elogiada por dar orientação concreta sobre o que os programadores devem fazer (testes, refatoração, design incremental), e não apenas sobre o processo em torno da codificação.
Agile, Scrum e Uso Indevido
- Reclamação comum: Scrum e Agile são frequentemente aplicados de forma dogmática, com “você está fazendo errado” usado para desviar críticas.
- Muitos descrevem “rituais” (daily standups, revisões, sprints) sendo seguidos mecanicamente, sem metas claras, colaboração ou adaptação.
- A interpretação equivocada de sprints como prazos fixos leva a subestimação deliberada, estimativas conservadoras e percepção de lentidão.
- Alguns argumentam que agile em si é sólido, mas foi cooptado pela burocracia e por consultorias; outros dizem que sempre teve a ver com vender serviços e controlar desenvolvedores.
- Kanban é visto por alguns como mais alinhado com trabalho interrompido por demandas.
Testes, TDD e Cobertura
- Testes unitários, refatoração e design consciente de testes são amplamente vistos como grandes ganhos de longo prazo.
- Outros argumentam que testes unitários dão muito trabalho para manter, muitas vezes são redundantes e têm menos valor do que testes de ponta a ponta.
- Debate sobre “100% de cobertura”: alguns veem isso como extremismo prejudicial; outros apontam que os textos de XP dizem explicitamente que nem todo método precisa de teste, focando antes em confiança.
- Preocupação de que projetar para testabilidade possa introduzir backdoors, problemas de desempenho ou vazamento de código de teste para produção.
Evolução das Práticas e das Ferramentas
- Muitas práticas antes consideradas “radicais” (CI, builds/testes automatizados, refatoração, design incremental, controle de versão) agora são mainstream, em parte atribuídas à onda mais ampla de agile/XP.
- Outros contrapõem que essas práticas já existiam antes em ambientes “waterfall” ou pré-agile; agile não as inventou, mas pode ter ajudado a difundi-las.
Indústria Agile e Dinâmicas Organizacionais
- Forte crítica ao “teatro agile”: proliferação de papéis (coaches, scrum masters, product owners) sem remover os verdadeiros impedimentos.
- Desenvolvedores se sentem sobrecarregados com cerimônias, trabalho administrativo e responsabilidade por atrasos fora de seu controle.
- Alguns veem o fracasso do agile como político: a burocracia adaptou a linguagem enquanto subvertia os princípios, resultando em “WaterScrumFall” e implementações rígidas, não ágeis.