 |
| Bellacosa Mainframe apresenta o rad parte ii |
☕ Um Café no Bellacosa Mainframe
RAD (Rapid Application Development)
Parte II — Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial
"Desenvolver rapidamente nunca significou programar rapidamente. Significou aprender rapidamente."
Recapitulando
Na primeira parte desta série vimos que o RAD nasceu como resposta a um problema que ainda existe.
Empresas mudam rapidamente.
Os negócios mudam rapidamente.
Os clientes mudam rapidamente.
O software precisa acompanhar esse ritmo.
James Martin percebeu isso no início dos anos 90, muito antes de ouvirmos falar de Scrum, DevOps, Cloud Computing ou Inteligência Artificial.
Mas existe uma pergunta ainda mais importante.
Como colocar RAD em prática?
É exatamente isso que veremos agora.
Porque conhecer a teoria é relativamente simples.
O verdadeiro desafio está em transformar uma equipe tradicional em uma equipe capaz de entregar software continuamente.
A filosofia do RAD
Antes de falar de ferramentas precisamos compreender uma característica importante.
RAD não é uma ferramenta.
RAD não é uma linguagem.
RAD não é um framework.
RAD é uma filosofia de desenvolvimento.
Essa diferença muda tudo.
Uma empresa pode utilizar Java.
Outra COBOL.
Outra Python.
Outra C#.
Outra JavaScript.
Todas podem aplicar RAD.
O que muda não é a tecnologia.
É a maneira como ela é utilizada.
O primeiro passo: definir um problema pequeno
O maior erro cometido por equipes iniciantes é querer desenvolver todo o sistema de uma única vez.
RAD faz exatamente o contrário.
Começa pequeno.
Muito pequeno.
Imagine um banco.
Ao invés de desenvolver todo o Internet Banking...
Começa apenas pela consulta de saldo.
Depois extrato.
Depois PIX.
Depois investimentos.
Depois cartões.
Cada funcionalidade nasce praticamente como um pequeno projeto.
Essa abordagem reduz riscos.
Se algo der errado...
O prejuízo é pequeno.
Segundo passo: montar uma equipe enxuta
RAD funciona melhor quando existe pouca burocracia.
Normalmente encontramos equipes compostas por:
Analista de Negócios
Usuário-chave
Desenvolvedor
Especialista em Banco de Dados
Testador
Arquiteto
Não significa que grandes empresas trabalhem apenas com seis pessoas.
Significa que cada módulo possui autonomia.
Quanto menor a cadeia de aprovação...
Maior a velocidade.
Terceiro passo: envolver o usuário desde o primeiro dia
Este talvez seja o segredo mais importante.
No desenvolvimento tradicional o usuário aparece em três momentos.
Levantamento.
Homologação.
Produção.
No RAD ele participa praticamente todos os dias.
Imagine um gerente de crédito.
Na segunda-feira ele vê uma tela.
Na terça sugere mudanças.
Na quarta recebe uma nova versão.
Na quinta encontra outro detalhe.
Na sexta aprova.
Foram cinco dias.
Não cinco meses.
Quarto passo: criar um protótipo
Muitos desenvolvedores acreditam que um protótipo precisa funcionar.
Nem sempre.
Às vezes basta desenhar as telas.
Hoje existem dezenas de ferramentas para isso.
Figma.
Balsamiq.
Adobe XD.
Draw.io.
PowerPoint.
Até papel e caneta funcionam.
O objetivo não é impressionar.
É descobrir rapidamente se a ideia faz sentido.
Quinto passo: construir um MVP
Outro conceito herdado pelo desenvolvimento moderno.
MVP significa:
Minimum Viable Product
Ou Produto Mínimo Viável.
É a menor versão possível capaz de gerar valor.
Não significa software incompleto.
Significa software focado.
Imagine um sistema de empréstimos.
Ao invés de desenvolver quarenta funcionalidades...
Construa apenas cinco.
Se resolverem o problema principal...
O MVP cumpriu seu papel.
Sexto passo: validar rapidamente
Depois do MVP vem o momento mais importante.
Mostrar ao usuário.
Sem apresentações longas.
Sem centenas de slides.
Sem documentos enormes.
Coloque o sistema na frente dele.
Observe.
Escute.
Anote.
Melhore.
Repita.
Esse ciclo acontece inúmeras vezes.
Sétimo passo: melhorar continuamente
RAD nunca considera o software terminado.
Sempre existe espaço para melhorias.
Esse conceito influenciou diretamente o DevOps.
A aplicação evolui continuamente.
Pequenas melhorias.
Pequenos ajustes.
Pequenas correções.
Pequenas entregas.
O resultado costuma ser muito superior a uma única entrega gigantesca.
Como medir se o RAD está funcionando?
Toda metodologia precisa de indicadores.
Caso contrário ela vira opinião.
Algumas métricas importantes são:
Tempo até a primeira entrega
Quanto tempo levou para o usuário ver algo funcionando?
Dias?
Semanas?
Meses?
Quanto menor esse tempo...
Melhor.
Tempo de resposta às mudanças
Quanto tempo leva para alterar uma regra?
Horas?
Dias?
Semanas?
Se pequenas alterações exigem meses...
O processo ainda é pesado.
Número de retrabalhos
Se o usuário rejeita constantemente o software...
Algo está errado.
RAD busca reduzir retrabalho através do feedback constante.
Satisfação do usuário
Talvez seja o indicador mais importante.
Software existe para resolver problemas.
Não para produzir documentação.
As metodologias que herdaram conceitos do RAD
Embora o RAD seja uma metodologia própria, diversos movimentos posteriores incorporaram suas ideias.
Scrum
Sprint.
Incrementos.
Revisões.
Backlog.
Todos esses conceitos possuem enorme afinidade com RAD.
A principal diferença é que Scrum adicionou uma estrutura mais formal para gerenciamento.
Extreme Programming (XP)
XP talvez seja a metodologia que mais herdou conceitos do RAD.
Ela enfatiza:
feedback constante;
integração contínua;
programação em pares;
testes automatizados;
pequenas entregas.
Na prática, XP leva o RAD para um nível técnico ainda maior.
Lean Software Development
O Lean nasceu inspirado no Sistema Toyota.
Seu foco é eliminar desperdícios.
Curiosamente...
RAD também fazia exatamente isso.
Ambos valorizam aquilo que gera valor ao cliente.
DevOps
Muitos imaginam que DevOps trata apenas de infraestrutura.
Não.
DevOps também reduz o tempo entre desenvolver e colocar em produção.
Essa busca pela velocidade é um dos princípios centrais do RAD.
Agile
Podemos dizer que o RAD foi um dos grandes precursores do movimento ágil.
Nem todos concordam com essa afirmação.
Mas basta observar os princípios.
Feedback rápido.
Cliente presente.
Entregas frequentes.
Iterações.
Tudo isso já aparecia no RAD.
Ferramentas clássicas do RAD
Nos anos 90 existia uma verdadeira explosão de ferramentas RAD.
Algumas desapareceram.
Outras evoluíram.
Outras continuam presentes.
Entre elas:
PowerBuilder
Uma das maiores referências da época.
Construía aplicações corporativas rapidamente.
Oracle Forms
Durante muitos anos dominou aplicações empresariais.
Principalmente no ambiente Oracle.
Visual Basic
Talvez o maior símbolo do RAD para plataformas Windows.
Arrastar componentes.
Criar telas.
Conectar banco.
Gerar aplicações em poucas horas.
Delphi
Um dos ambientes RAD mais famosos da história.
Compilação extremamente rápida.
Excelente desempenho.
Grande produtividade.
Até hoje possui uma comunidade fiel.
GeneXus
Muito conhecido na América Latina.
Gera aplicações automaticamente para diversas plataformas.
Utilizado inclusive em grandes instituições financeiras.
Magic xpa
Ferramenta RAD voltada ao ambiente corporativo.
Muito utilizada em integração de sistemas.
Ferramentas modernas
O conceito continua vivo.
Mudaram apenas os nomes.
Hoje encontramos:
Microsoft Power Apps
Google AppSheet
OutSystems
Mendix
ServiceNow App Engine
Salesforce Lightning
Oracle APEX
Retool
FlutterFlow
Bubble
Appian
Zoho Creator
Todas seguem praticamente a mesma ideia.
Construir rapidamente.
Validar rapidamente.
Entregar rapidamente.
RAD e Low-Code
É impossível falar de RAD sem mencionar Low-Code.
Na prática...
Low-Code tornou o RAD muito mais poderoso.
Imagine criar uma tela.
Conectar um banco.
Criar APIs.
Publicar na nuvem.
Tudo isso praticamente sem escrever código.
O RAD encontrou no Low-Code um parceiro natural.
RAD e No-Code
O No-Code leva esse conceito ainda mais longe.
Usuários de negócio conseguem construir soluções simples.
Sem depender completamente da TI.
Isso acelera protótipos.
Validações.
Experimentos.
Naturalmente, sistemas críticos ainda exigem desenvolvimento profissional.
Especialmente no Mainframe.
Inteligência Artificial e RAD
Talvez este seja o maior salto desde os anos 90.
Hoje a IA consegue:
Gerar código.
Criar documentação.
Escrever testes.
Produzir APIs.
Criar consultas SQL.
Explicar código legado.
Converter linguagens.
Criar protótipos.
Documentar regras de negócio.
Isso reduz drasticamente o tempo de desenvolvimento.
Mas existe um detalhe importante.
A IA acelera.
Ela não substitui engenharia.
Alguém continua precisando tomar decisões arquiteturais.
Performance no RAD
Existe outro mito bastante conhecido.
"Software desenvolvido rapidamente é lento."
Não necessariamente.
Performance depende muito mais da arquitetura.
Uma aplicação construída em RAD pode apresentar excelente desempenho quando possui:
arquitetura bem definida;
banco de dados otimizado;
índices corretos;
consultas eficientes;
cache adequado;
testes de carga;
monitoramento constante.
O problema não está na velocidade do desenvolvimento.
Está na ausência de engenharia.
Governança
Projetos RAD também precisam de controle.
Sem governança surge o caos.
Algumas práticas recomendadas:
Versionamento no Git.
Code Review.
Integração Contínua.
Pipeline automatizado.
Testes automatizados.
Documentação mínima.
Monitoramento.
Catálogo de APIs.
Padronização de componentes.
Segurança
Outro erro comum.
"Ainda é protótipo."
Quantos incidentes começaram exatamente assim?
Mesmo durante prototipação devemos considerar:
Autenticação.
Autorização.
Criptografia.
Proteção de dados.
LGPD.
Auditoria.
Logs.
Quanto antes a segurança entrar no projeto...
Menor o custo.
Quando RAD não é a melhor escolha?
Existem situações em que outras abordagens podem ser mais adequadas.
Por exemplo:
Projetos militares.
Sistemas embarcados extremamente críticos.
Software aeroespacial.
Equipamentos médicos.
Aplicações certificadas.
Ambientes altamente regulados.
Nesses casos o custo da documentação extensa pode ser menor que o risco de falhas.
Mesmo assim, muitos princípios do RAD continuam sendo utilizados durante prototipação e validação.
O erro mais comum
Muitos gestores acreditam que RAD significa fazer tudo mais rápido.
Na realidade significa aprender mais rápido.
Existe uma enorme diferença.
Velocidade sem aprendizado produz retrabalho.
Aprendizado contínuo produz velocidade.
Essa talvez seja a maior lição deixada por James Martin.
O que um programador COBOL pode aproveitar hoje?
Mesmo trabalhando exclusivamente com IBM Z, praticamente todos os conceitos desta parte podem ser aplicados.
Você pode criar protótipos de telas antes de desenvolver transações CICS.
Pode validar regras de negócio com usuários antes de alterar programas COBOL.
Pode utilizar APIs simuladas para testar integrações.
Pode automatizar builds, testes e deploys em pipelines DevOps.
Pode expor programas COBOL como serviços REST por meio do z/OS Connect e receber feedback em ciclos curtos.
Pode utilizar Inteligência Artificial para documentar código legado, sugerir refatorações e acelerar a criação de testes.
O ambiente mudou muito desde 1991, mas o objetivo continua exatamente o mesmo: reduzir a distância entre a necessidade do negócio e a entrega de uma solução funcional.
No próximo café entraremos definitivamente no universo IBM Mainframe. Veremos como aplicar RAD em aplicações COBOL, CICS, IMS, DB2, VSAM e z/OS, como integrar essa metodologia com DevOps, Git, APIs, z/OS Connect, testes automatizados e modernização, além de entender por que o RAD continua extremamente relevante na era do IBM Z e da Inteligência Artificial.
