Agilidade em arquitetura exige menos ritual e mais capacidade de adaptação

Agilidade perde utilidade quando vira sinônimo de cerimônia. Na palestra de Joshua Kerievsky sobre arquitetura de software, a palavra é recolocada como adjetivo: agir com rapidez, facilidade, graça, recurso e adaptação. O exemplo inicial de Richard Branson fretando um avião para passageiros presos no aeroporto serve para separar comportamento ágil de pacote metodológico. A crítica mira a redução do termo a sprints, stand-ups, pontos de história ou modelos de escala. Para Kerievsky, esse vocabulário pode existir, mas não define a capacidade real de sair de um impasse com uma solução adequada ao contexto.

O mecanismo aparece melhor nos casos concretos. Ao considerar um chat em uma plataforma de e-learning, sua equipe não construiu a funcionalidade: colocou uma simulação na interface, mediu o interesse e descobriu que poucos usuários a usariam. A decisão ágil foi não construir. Em outro extremo, ele defende que problemas conhecidos podem justificar análise e desenho antecipados. No banco em Wall Street, uma ferramenta genérica de manutenção de tabelas resolvia uma demanda repetida de CRUD para várias áreas. Em relatórios, macros em Excel também foram uma solução aceitável quando o contexto pedia rapidez e baixo custo, não uma arquitetura nobre.

A consequência para arquitetura é incômoda: pressa constante reduz adaptação. O caso da HP, que duplicou firmware para impressoras até tornar correções de bugs um problema distribuído por muitas bases de código, mostra a diferença entre algo rápido e algo gracioso. A saída, segundo Kerievsky, veio quando a empresa investiu em design e em uma base mais preparada para o futuro. O mesmo raciocínio aparece no relato da Nielsen: em vez de integrar tardiamente partes grandes de um relatório complexo, a equipe produziu primeiro uma linha correta, atravessando mainframe, data warehouse, Java e regras de negócio.

Essa visão também impõe um limite à cultura de urgência. Kerievsky associa adaptação a segurança: testes automatizados, refatoração gradual, fatias verticais e desenho suficientemente limpo para trocar uma dependência cara, como no caso do WebSphere, sem paralisar a entrega. A pergunta prática não é se uma organização usa o vocabulário ágil, mas se suas equipes conseguem invalidar uma ideia barata, integrar cedo, reduzir medo técnico e escolher entre experimento, desenho antecipado ou evolução incremental sem ficarem presas ao ritual.

Assistir ao episódio original

Referências encontradas

Livros

• Joy Of Agility: How To Solve Problems And Succeed Sooner (English Edition), de Joshua Kerievsky — Ver livro na Amazon
• Scaling Lean & Agile Development: Thinking And Organizational Tools For Large-Scale Scrum — Ver livro na Amazon
• Rapid Application Development, de James Martin — Ver livro na Amazon
• Uma Linguagem de Padrões, de Christopher Alexander; Sara Ishikawa; Murray Silverstein — Ver livro na Amazon

Séries

• Ted Lasso — Ver no TMDB

Este post contém links de afiliado. Se você comprar por eles, eu posso receber uma pequena comissão sem custo adicional para você.