Agile: sem as ferramentas certas, é só mais uma forma desorganizada de produzir software
Published: 2024-03-27 12:10:58

Olá, Dev/Agilista! Começo pedindo que não dê muita bola para o título desse post, ele é mais uma provocação do que uma verdade em sua totalidade :)

Sabemos que as metodologias e práticas ágeis, especialmente quando bem aplicadas, trazem contribuições significativas para os projetos e as organizações como um todo. Principalmente, quando comparamos com as alternativas mais burocráticas, seus predecessores. Quando temos um time maduro, que foi além das técnicas e das cerimônias, e incorporou a mentalidade ágil, essa diferença é absolutamente gritante. Na verdade, podemos dizer que é incomparável.

As metodologias ágeis estão conosco há vários anos, a publicação do famoso [Manifesto Ágil](https://agilemanifesto.org/), realizada em 2001, já ultrapassou suas duas décadas. Ao longo deste tempo, é quase impossível que durante sua carreira você não tenha atuado em ao menos um projeto onde se tenha adotado (ou tentado adotar) alguma metodologia ágil.

Da mesma forma, baseado na minha própria vivência, acredito que seja também improvável que em ao menos uma dessas experiências as coisas não tenham saído como esperado. Mesmo observando de forma bastante disciplinada todos os ritos e cerimônias, elas não garantem o sucesso de um projeto de desenvolvimento. Como já citamos anteriormente e voltamos a repetir, as metodologias ágeis entregam seu valor máximo não com a mera adoção de técnicas e cerimônias, mas quando a mentalidade do time é convertida para uma cultura ágil.

Contudo, meu ponto é que isso não cobre tudo. Existe uma questão fundamental em projetos de software que não pode ser superada apenas com técnicas, processos ágeis ou mentalidade: a técnica de produzir código de programação, código com qualidade. E já que estamos falando de agilidade, de aproveitar as janelas do mercado, temos que admitir que essa produção de software com qualidade não pode demorar o tempo que Michelangelo levou para pintar a abóboda da Capela Sistina.

Ainda que o time siga de forma disciplinada o beabá do SCRUM ou qualquer adaptação mais elaborada, abrace e se adapte às mudanças, faça entregas contínuas e frequentes, que o Dono do Produto esteja presente, especifique e priorize bem seu backlog, se o time de desenvolvimento não for capaz de codificar rapidamente e, claro, sem bugs que impeçam a publicação do software em ambiente produtivo, haverá uma lacuna importante que frustará as ambições agilistas e, em última instância, da direção e dos clientes da organização.

Talvez por isso as plataformas No-Code e Low-Code tenham ganhado holofotes nos últimos anos. Elas oferecem um ambiente onde o time pode produzir telas com lógica de negócio incorporada de forma rápida, em um ambiente controlado onde, supostamente, não haverá grandes riscos técnicos. Não há dúvidas que essas ferramentas estão entregando valor e contribuindo para os projetos avançarem, mas elas não são balas de prata (nenhuma é, certo?). Ao mesmo tempo que este ambiente controlado mitiga riscos técnicos, pois as peças deste “Lego” já estão definidas, ele também pode limitar ou impedir soluções mais criativas. E não vamos nem entrar em questões como vendor lock-in.

Antes de seguir, vou enfatizar: é indiscutível que essas plataformas No-Code e Low-Code têm contribuído significativamente para o avanço de inúmeros projetos ao redor do mundo e seu sucesso não é em vão, têm entregado valor, o software tem chegado em produção e os objetivos de negócio têm sido alcançados.

Entretanto, em muitos projetos essa estratégia não será a mais adequada. Nós precisaremos do bom e velho “High Code”, e precisaremos produzir rápido para aproveitar as janelas de oportunidade. Sabidamente, não bastará simplesmente produzir volumes monstruosos de código em espaço de tempo reduzido, é essencial que esse código produzido tenha qualidade. Do contrário, isso levará a débitos técnicos, retrabalho, impacto no tempo de entrega, perda de oportunidades de mercado, prejuízos …

A proposta deste post é introduzir uma série de outros posts onde iremos explorar uma ferramenta já experimentada no mercado que se propõe a automatizar a produção de software com qualidade, software com conceitos modernos, seguindo as melhores práticas de mercado, construído sobre os melhores e mais difundidos frameworks, bibliotecas e ferramentas de mercado: o JHipster.

Temos a ousada pretensão de ajudar tornar realidade os sonhos e promessas dos agilistas :)

Aqui está a lista de links para a série de posts desta jornada que pretendemos incrementar ao longo do tempo:

[Introdução ao JHipster](https://dev.to/meucodigoagil/introducao-ao-jhipster-4hcb)

[JHipster 8 - Criando uma aplicação monolítica](https://dev.to/meucodigoagil/jhipster-8-criando-uma-aplicacao-monolitica-1gl)

[JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 1/3](https://dev.to/meucodigoagil/jhipster-8-analisando-o-codigo-da-nossa-primeira-aplicacao-monolitica-parte-13-2380)

[JHipster 8 - Analisando o código da nossa primeira aplicação monolítica - Parte 2/3](https://dev.to/meucodigoagil/jhipster-8-analisando-o-codigo-da-nossa-primeira-aplicacao-monolitica-parte-23-2kan)