Fala ARQ 🦅 , no comecinho dos movimentos de migração para o modelo "ágil" que temos hoje, eu fui atrás da grande mãe da agilidade, o Lean, uma metodologia criada pela Toyota para fabricar os seus carros, e de fato eles eram sim mais "rápidos" e a qualidade era top porque o engajamento era muito alto, as startups começaram a adotar adaptações do Lean, os grandes se sentiram ameaçados e bum.

Bem por ter me baseado no Lean, eu achava que sim era para fazer mais rápido afinal não dava para fazer carros meia boca, um MVP jamais poderia ser um carro só com chassi e rodas, afinal ninguém compraria, sem contar que se fala de vidas quando se fala de veículos, então toda a burocracia, documentação, fiscalização precisa existir. Mas o "ágil" de TI é muito diferente, é importante entender e "aceitar" isso.

Bem o meu ponto aqui é, no mercado de TI ágil não é necessariamente rápido, eu diria que é ansioso, obviamente com os benefícios de se entregar os valores mais importantes mais rápido, em contrapartida, na maioria das vezes acabamos deixando de lado a essência, de efetivamente ouvir quem aperta os parafusos para entender e melhorar continuamente e dos processos de engenharia de software incluindo os de qualidade com um foco muito maior em economizar recursos de TI (financeiramente) e em lançar produtos rapidamente. O fruto colhido acaba sendo produtos obsoletos ou com "arquiteturas ruins" muito rápido. No final acabamos muitas vezes entregando valor mais rápido, mas praticamente deixamos de entregar produtos completos como antigamente e com uma longevidade exponencialmente menor.

Concluindo, é lógico que eu sou fã de agilidade, afinal ela engaja muito mais os times, mas sem deixar de pensar nas práticas de fundamentação da engenharia de software e logicamente de qualidade pois sem isso é certo de que o produto não só vai demorar mais para ficar pronto, mas vai se tornar obsoleto rápido demais. Ouça o nosso conteúdo completo em podcast ou no nosso grupo do Telegram.

Forte abraço ARQ 🦅 até a próxima