✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
Bellacosa Mainframe e as metodologias Ageis para um coboleiro
☕ Um Café no Bellacosa Mainframe
Alan Turing Entra na Sala de Mudanças — O Dia em que o Agile Descobriu que um Programa COBOL Não Chega Sozinho à Produção
Ou: por que uma sprint não termina quando o compilador sorri, o que RACF, Db2, JCL, UX e Operação estão fazendo na mesma história e como não transformar Agile em Waterfall de post-it
Imagine Alan Turing entrando numa sala de projeto em 2026. Há um quadro com colunas coloridas: To do, Doing, Done. Alguém aponta para um cartão e anuncia, muito satisfeito: “acabou; o COBOL compilou”. Turing olha para o cartão, para o café frio ao lado do terminal e faz a pergunta que estraga metade das celebrações corporativas:
“Acabou para quem?”
O programa compilou. Ótimo. Mas o pacote Db2 foi validado? O acesso RACF existe e obedece ao menor privilégio? O job está no scheduler correto? A operação sabe interpretar um RC=8? A massa de testes representa o volume de fim de mês? A interface explica ao cliente que o processamento é assíncrono? Existe um plano de retorno se a alteração abrir um buraco no universo — ou, pior, na conciliação financeira?
Para o programador COBOL iniciante, esta é uma descoberta importante: em um projeto mainframe, você não entrega apenas um programa. Você entrega uma mudança dentro de um ecossistema que processa dados valiosos, conversa com muitas plataformas e, em vários casos, não pode errar por cinco minutos sem alguém perceber no extrato, no caixa, na folha ou no jornal.
Este artigo é um mapa para entender a diferença entre Agile e Waterfall, o papel dos dados e da IA, e por que o mainframe exige uma forma mais adulta de agilidade: rápida para aprender, rigorosa para produzir.
1. Agile não é correria; Waterfall não é vilão
O modelo Waterfall — a famosa cascata — costuma organizar o projeto em grandes etapas sequenciais:
Ele faz sentido quando o problema é estável e bem conhecido. Uma adequação regulatória com regras fechadas, uma troca controlada de infraestrutura ou uma alteração obrigatória de layout podem exigir muito planejamento antes de escrever a primeira linha. Em sistemas críticos, isso não é burocracia por esporte; é controle de risco.
O defeito aparece quando tratamos algo incerto como se estivesse completamente decidido. O time passa meses documentando, desenvolve por meses adicionais e só no fim descobre que o cliente não entendia o fluxo, que uma integração não suporta a carga ou que a regra de negócio tinha uma exceção escondida num e-mail de 2017.
O Agile trabalha diferente. Ele divide a jornada em partes pequenas: construir, testar, mostrar, aprender e ajustar. Não é ausência de planejamento. É planejamento em fatias, com aprendizado antecipado.
Pergunta
Waterfall
Agile maduro
Quando aprendemos se a solução serve?
Mais perto do fim
Em entregas curtas
O requisito pode mudar?
Tende a virar exceção formal
Pode ser repriorizado com evidência
Como o risco aparece?
Às vezes tarde
Deve surgir em cada ciclo
O que significa progresso?
Fase concluída
Valor entregue, testado e operável
Nem todo projeto precisa ser 100% de um modelo. No mainframe, o mais comum e sensato é um híbrido: Agile para construir e validar valor; controles mais sequenciais para governança, auditoria, segurança, janela de mudança e produção.
O problema não é usar Waterfall. O problema é fingir que ele continua funcionando quando o negócio ainda está descobrindo o que quer. E o problema do Agile não é ter ritos; é fingir que uma daily de quinze minutos resolve uma dependência que atravessa cinco departamentos.
2. Quando os dados entram: a agilidade deixa de ser opinião
O infográfico que motivou nossa conversa diz que o futuro do Agile será orientado por dados e IA. A frase é boa, desde que não seja traduzida como “compremos uma plataforma e ela decidirá por nós”.
Dados úteis respondem perguntas simples e duras:
Quanto tempo uma mudança leva desde o pedido até a produção?
Em qual fila o trabalho fica parado?
Quantos defeitos escapam para produção?
O cliente usa a funcionalidade entregue?
O batch ainda cabe na janela?
A nova consulta Db2 aumentou CPU ou I/O?
Qual permissão RACF foi solicitada, por quem, para quê e até quando?
No Kanban, por exemplo, lead time mede a espera do solicitante; cycle time, o tempo de trabalho ativo; throughput, quantos itens foram concluídos; e WIP (work in progress), quantos itens estão abertos ao mesmo tempo. Se há trinta histórias abertas e três concluídas por semana, o quadro não está “agitado”: está congestionado.
Em Scrum, a velocidade pode ajudar o próprio time a planejar. Mas cuidado: story point não é hora, salário, inteligência nem medalha. Comparar a velocidade de duas equipes é como comparar o número de páginas de dois livros para decidir qual é melhor. A métrica serve para observar tendência local, não para fabricar ranking e medo.
IA pode resumir incidentes, classificar chamados, sugerir testes, localizar padrões em logs e apontar que uma fila está crescendo. Ela é um ótimo Dr. Watson de silício: organiza pistas. Mas não substitui Sherlock, muito menos o dono da regra de negócio. Um modelo pode prever atraso; não sabe, sozinho, que a causa real é a única DBA estar em férias ou que a regra depende de um contrato assinado há vinte anos.
3. XP, Scrum, Kanban e os parentes menos convidados para o café
As metodologias citadas no infográfico não são feitiços concorrentes. Cada uma ilumina uma parte do problema.
Extreme Programming (XP) reforça engenharia: TDD, integração contínua, programação em pares, pequenas mudanças e refatoração. Para COBOL, isso significa abandonar a ideia de que teste é apenas executar um job e olhar se “não deu abend”. Teste unitário, dados conhecidos, validação de regras e regressão tornam uma mudança mais segura. Se alterou juros, decimal, data, sinal ou arredondamento, tenha casos que provem o comportamento antes e depois.
Scrum organiza trabalho em sprints: backlog priorizado, planejamento, revisão e retrospectiva. É útil quando há produto evoluindo e necessidade de alinhamento frequente. Mas uma história Scrum não pode ser “codificar o programa X” se a produção depende também de autorização, bind, operação e homologação. Isso é só uma tarefa de desenvolvimento disfarçada de entrega.
Kanban é excelente para sustentação e fluxo contínuo: incidentes, pequenas manutenções, pedidos de acesso e correções. Ele mostra onde o serviço enrosca. Se todo cartão fica parado em “aguardando validação”, não adianta cobrar mais velocidade de quem codifica; é necessário corrigir o gargalo.
Feature-Driven Development (FDD) puxa a conversa para funcionalidades de negócio: “consultar saldo”, “calcular limite”, “emitir boleto”. Isso protege o time de entregar componentes tecnicamente elegantes que não resolvem nada importante. Dados de uso e feedback ajudam a priorizar, mas não eliminam criticidade: um processo usado uma vez por mês pode ser vital para uma obrigação legal.
APF, ASD, DSDM e XPM lembram que há projetos onde a incerteza é parte do trabalho. Eles valorizam adaptação, protótipos, colaboração e aprendizado. Em modernização, isso é ouro: primeiro confirme se a API atende, se a tela faz sentido e se o legado suporta a carga; depois escale. Um protótipo bonito não prova que há segurança, transação, recuperação ou capacidade de produção.
4. A história que atravessa o mainframe
Uma funcionalidade bancária aparentemente modesta — “permitir consultar uma fatura no aplicativo” — pode envolver Business Analyst, UX/UI, desenvolvedor, DBA, RACF, qualidade, gerente de sistemas e operações.
O Business Analyst traduz objetivo em regra. Não basta escrever “mostrar fatura”; é preciso dizer quais clientes podem consultar, quais períodos, o que acontece para fatura fechada, renegociada, indisponível ou protegida por sigilo.
O UX/UI desenha a jornada. Mas precisa saber se a resposta é imediata, se depende de batch, se há limites de consulta e qual mensagem humana será exibida quando um serviço estiver indisponível. A tela não pode prometer “pronto agora” quando o processo real conclui à noite.
O System Developer implementa lógica, integrações, programas COBOL, copybooks, APIs, CICS, MQ, JCL ou o que a arquitetura pedir. Seu trabalho inclui analisar impacto: quem chama este programa? Qual layout será alterado? Um campo novo quebra um consumidor antigo? Há tratamento para valor nulo, arquivo ausente e retorno inesperado?
O DBA olha além do resultado correto. A consulta funciona com cem registros? E com cinquenta milhões? Ela usa índice? Há risco de lock, timeout, deadlock, aumento de CPU ou alteração de plano de acesso após o BIND? Uma query que “funciona na homologação” pode virar o monstro da janela noturna em produção.
O especialista de RACF e segurança desenha identidade e autorização. Quem acessa? Pessoa, aplicação, job batch ou ID de serviço? Qual dataset, transação CICS, recurso Db2 ou certificado é necessário? A regra é menor privilégio, segregação de funções e prazo claro para acessos temporários. RACF não é uma cancela colocada no fim da estrada; é parte da arquitetura.
Qualidade cria cenários positivos, negativos, integrados e de volume. “O caminho feliz funcionou” é apenas o primeiro capítulo. E se o arquivo chegar vazio? E se houver caractere inválido e surgir um S0C7? E se o job receber RC=8? E se a atualização parcial precisar de rollback?
System Manager avalia plataforma, versões, capacidade, configuração e impacto de mudança. Operações prepara execução, agendamento, monitoração e resposta ao incidente. Se a equipe operacional precisa telefonar ao desenvolvedor para descobrir o que significa um erro, a mudança chegou sem manual de sobrevivência.
5. O cadáver na sprint: “pronto” para desenvolvimento, incompleto para produção
Eis o defeito mais comum: cada área usa uma definição privada de pronto.
Para Desenvolvimento, pronto é código compilado. Para Qualidade, teste executado. Para Segurança, perfil aprovado. Para Operações, job agendado e monitorado. Para o negócio, pronto é cliente receber o resultado correto. Todas as definições são legítimas — mas isoladas formam um Frankenstein organizacional.
Uma Definition of Done comum deve estabelecer, proporcionalmente ao risco, que a mudança possui:
regra e critérios de aceite validados;
código revisado, versionado, compilado e testado;
análise de impacto em copybooks, programas, arquivos, APIs e consumidores;
revisão Db2, EXPLAIN e BIND quando aplicável;
permissões RACF e segregação de funções definidas;
testes integrados, negativos e de regressão;
JCL, PROC, GDG, dataset, parâmetros e scheduler revisados;
plano de implantação e backout;
monitoração, logs, códigos de retorno e runbook operacional;
evidência de homologação e validação pós-produção.
Isso não obriga uma correção de rótulo de tela a passar pelo mesmo rito de uma alteração de saldo. O segredo é uma matriz de impacto. Marque, no refinamento: toca Db2? RACF? CICS? MQ? VSAM? JCL? dados pessoais? scheduler? interface externa? auditoria? Quanto maior o impacto, maior a necessidade de envolvimento antecipado.
6. Passo a passo: como levar uma história até produção sem ritual de pânico
1. Comece pelo valor e pelas exceções. O BA e o dono do negócio descrevem o que muda e como medir sucesso. “Reduzir ligações sobre segunda via” é melhor que “criar tela de segunda via”. Acrescente cenários de erro e regras de borda.
2. Faça análise de impacto antes de prometer a data. Desenvolvimento identifica módulos, layouts, chamadas, tabelas, jobs e interfaces. Segurança, DBA e operação entram cedo somente quando houver impacto real. Não coloque vinte pessoas na daily; coloque as pessoas certas no refinamento certo.
3. Divida verticalmente. Em vez de uma sprint para tela, outra para API e outra para COBOL, entregue uma pequena jornada completa. Talvez apenas consulta de uma fatura recente, com autorização, rastreabilidade e erro bem tratado. A fatia prova valor e reduz a hipótese.
4. Automatize o repetível. Build, testes, análise estática, promoção de artefatos e registro de evidências não deveriam depender de e-mails e memória humana. Em ambiente z/OS, ferramentas e pipelines modernos ajudam, mas automação só presta se respeitar os controles da organização.
5. Teste como se a produção fosse real. Use massa protegida e representativa. Teste volume, falha de integração, retorno inesperado, recuperação e janela batch. O objetivo não é provar que o sistema funciona em condições ideais; é descobrir como ele falha e se recupera.
6. Entregue para operação antes da operação precisar socorrer você. O runbook deve informar o que mudou, jobs e transações afetados, entradas e saídas, RCs esperados, alertas, validação pós-implantação e retorno. É conhecimento operacional, não papelada decorativa.
7. Observe e aprenda. Após produção, acompanhe uso, tempo de resposta, erro, custo e chamados. Se o recurso foi entregue e ninguém o usa, a equipe produziu software; ainda não produziu valor.
7. Easter egg de Turing: a máquina não entende intenção
Turing nos deixou uma lição que vale para COBOL e para IA: máquinas executam regras e padrões; intenção humana precisa ser expressa, validada e verificada.
Um compilador não sabe que um campo deveria ter duas casas decimais. Ele só sabe o que foi codificado. Um modelo de IA não sabe que uma permissão concedida por conveniência viola segregação de funções. Ele só encontra padrões nos dados que recebeu. Um dashboard não sabe que um item parado há dez dias representa o pagamento de pensão de milhares de pessoas.
Portanto, use IA como copiloto: para sugerir cenários de teste, resumir tickets, encontrar padrões em logs e apontar anomalias. Não a use como autorização para abandonar revisão humana, testes, controles de acesso ou responsabilidade profissional.
Epílogo — o verdadeiro Done
O jovem programador COBOL costuma imaginar que seu programa termina no GOBACK. Em uma empresa real, ele só começa ali. A alteração atravessa banco de dados, controles de acesso, testes, operação, negócio, tela, integração, auditoria e pessoas que acordarão se algo der errado às duas da manhã.
Agile bem aplicado ao mainframe não é um ataque à governança. É a forma de trazer segurança, DBA, qualidade e operações para mais perto do momento em que a decisão ainda é barata.
Turing provavelmente olharia novamente para o cartão marcado como Done e faria a pergunta final:
“O sistema apenas executa, ou a organização consegue explicar, operar, proteger e recuperar o que acabou de mudar?”
Quando a resposta for “sim”, então o cartão pode, finalmente, atravessar a última coluna.
Bellacosa Mainframe e RAD rapid application development
☕ Um Café no Bellacosa Mainframe
RAD (Rapid Application Development)
A Metodologia que Mudou a Engenharia de Software e Continua Transformando o IBM Mainframe
Você não está estudando apenas uma metodologia criada nos anos 90. Está entendendo a origem de grande parte das práticas modernas de desenvolvimento de software.
"O Mainframe nunca foi lento. Lento sempre foi o processo de desenvolvimento ao seu redor."
Introdução
Quando alguém fala em desenvolvimento ágil, Scrum, DevOps, Low-Code, No-Code ou Inteligência Artificial, normalmente imagina que essas tecnologias surgiram praticamente do nada.
Na realidade, muitas dessas ideias nasceram décadas antes.
Entre elas está o RAD (Rapid Application Development), metodologia criada para reduzir o tempo entre uma necessidade do negócio e a entrega de software funcionando.
Seu princípio continua extremamente atual.
Não desenvolver mais rápido.
Aprender mais rápido.
Para quem trabalha com COBOL e IBM Mainframe, compreender o RAD significa entender que velocidade nunca dependeu apenas da linguagem de programação. Ela depende principalmente da organização do trabalho, da automação, da participação do usuário e da capacidade de evoluir continuamente.
Esta série apresenta o RAD sob a ótica do profissional IBM Z, mostrando que seus princípios continuam mais vivos do que nunca.
O que você aprenderá nesta série
Ao longo dos três capítulos veremos:
a origem do RAD;
por que ele revolucionou a Engenharia de Software;
como implementar RAD na prática;
metodologias derivadas;
ferramentas clássicas e modernas;
integração com Low-Code, DevOps e IA;
aplicação em COBOL, CICS, DB2, IMS e IBM Z;
oportunidades profissionais para desenvolvedores Mainframe.
Capítulo 1 — O que é RAD e por que ele revolucionou o desenvolvimento de software
Resumo
O primeiro capítulo apresenta a história do Rapid Application Development, criado por James Martin em 1991.
Mostra o cenário da época, dominado pelo modelo Cascata (Waterfall), em que projetos levavam anos para serem concluídos e frequentemente chegavam ao usuário já desatualizados.
Também explica os quatro pilares do RAD:
desenvolvimento iterativo;
prototipação;
participação constante do usuário;
equipes pequenas e multidisciplinares.
O capítulo compara RAD com Waterfall e demonstra como suas ideias influenciaram praticamente todas as metodologias modernas.
Leia o capítulo completo:
👉 RAD (Rapid Application Development) – Parte 1: O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente
Depois de entender os conceitos fundamentais, chega o momento de colocar o RAD em funcionamento.
Este capítulo apresenta um roteiro completo de implementação.
Você aprenderá:
como dividir projetos em pequenas entregas;
como montar equipes enxutas;
como construir protótipos;
como utilizar MVP (Minimum Viable Product);
como medir resultados;
indicadores de sucesso;
governança;
segurança;
documentação enxuta.
Também apresenta as metodologias influenciadas pelo RAD:
Scrum;
Extreme Programming (XP);
Lean Software Development;
DevOps;
Agile.
Além disso, faz um panorama das principais ferramentas RAD da história, como PowerBuilder, Delphi, Oracle Forms e GeneXus, chegando às plataformas atuais como Mendix, OutSystems, Power Apps, Oracle APEX e soluções baseadas em Inteligência Artificial.
Leia o capítulo completo:
👉 RAD (Rapid Application Development) – Parte 2: Como Implementar RAD na Prática, Principais Metodologias, Ferramentas e o Papel da Inteligência Artificial
O terceiro capítulo aproxima definitivamente o RAD do universo IBM Z.
Mostra que o Mainframe nunca foi incompatível com desenvolvimento rápido.
Na verdade, muitos bancos já aplicavam práticas semelhantes ao RAD antes mesmo da popularização do Agile.
Entre os assuntos abordados estão:
RAD aplicado ao COBOL;
modularização;
COPYBOOKs;
reutilização;
APIs REST;
z/OS Connect;
CICS;
DB2;
IMS;
VSAM;
Git;
DevOps;
CI/CD;
testes automatizados;
observabilidade;
Inteligência Artificial aplicada ao código legado.
O capítulo também discute o futuro do desenvolvimento Mainframe e mostra como a combinação entre COBOL, IA e automação cria novas oportunidades para profissionais especializados em IBM Z.
Leia o capítulo completo:
👉 RAD (Rapid Application Development) – Parte 3: RAD no IBM Mainframe: Como Aplicar Desenvolvimento Rápido em COBOL sem Perder a Confiabilidade do IBM Z
Ao final da leitura, fica evidente que o RAD nunca foi apenas uma metodologia para acelerar projetos.
Ele representa uma mudança de mentalidade.
Seus princípios continuam presentes em praticamente todas as práticas modernas de Engenharia de Software:
entregas incrementais;
feedback contínuo;
automação;
integração contínua;
testes automatizados;
prototipação;
foco no usuário;
redução de desperdícios;
melhoria contínua.
No ambiente IBM Mainframe, esses conceitos tornaram-se ainda mais relevantes graças à integração com APIs, Git, DevOps, z/OS Connect e Inteligência Artificial.
O desenvolvedor COBOL moderno não precisa abandonar décadas de conhecimento.
Precisa ampliar sua caixa de ferramentas.
Quanto mais automatizado for o processo, menor será o tempo entre uma ideia de negócio e sua implementação.
Esse sempre foi o verdadeiro objetivo do RAD.
Trinta anos depois, continua sendo uma das maiores lições da Engenharia de Software.
Próximas leituras recomendadas
Se você gostou desta série, acompanhe também os artigos do ☕ Um Café no Bellacosa Mainframe sobre:
DevOps para IBM Mainframe;
Low-Code para Programadores COBOL;
No-Code e Modernização;
Arquitetura Transformer para Mainframe;
Engenharia de Dados para Desenvolvedores COBOL;
CASE Tools;
APIs REST no IBM Z;
Inteligência Artificial aplicada ao COBOL;
Git e CI/CD no z/OS;
Modernização de aplicações IBM Z.
Esse artigo funciona como uma página pilar (Pillar Page) para SEO, concentrando a autoridade do tema RAD e distribuindo links para os três capítulos da série.
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.
Bellacosa Mainframe apresenta a rapid application development parte i
☕ Um Café no Bellacosa Mainframe
RAD (Rapid Application Development)
O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente
Você Não Está Descobrindo uma Ideia Nova. Está Descobrindo uma Tecnologia que Influenciou Quase Tudo o Que Veio Depois.
"Toda geração acredita que inventou uma forma mais rápida de desenvolver software. Poucos percebem que muitas dessas ideias nasceram há mais de trinta anos. O RAD foi uma delas."
Introdução
Quem começou a trabalhar com desenvolvimento de software nos anos 80 e 90 certamente ouviu falar de uma promessa bastante ousada.
"Vamos desenvolver sistemas em poucos meses."
Naquela época isso parecia impossível.
O desenvolvimento tradicional era lento.
Primeiro vinha o levantamento de requisitos.
Depois a documentação.
Depois o projeto.
Depois a programação.
Depois os testes.
Depois a homologação.
E finalmente... meses ou anos depois... o usuário via o sistema funcionando.
Não era raro um projeto durar dois ou três anos.
O problema?
Quando finalmente ficava pronto, o negócio já havia mudado.
As regras eram outras.
As necessidades eram diferentes.
E boa parte do software já nascia desatualizada.
Foi justamente para resolver esse problema que surgiu o Rapid Application Development, mais conhecido como RAD.
Muitos desenvolvedores mais jovens imaginam que desenvolvimento rápido começou com Agile, Scrum, DevOps, Low-Code ou Inteligência Artificial.
Na verdade, todos esses movimentos herdaram conceitos que o RAD apresentou décadas antes.
Para quem trabalha com COBOL, isso é especialmente interessante.
Durante muito tempo criou-se o mito de que Mainframe significa desenvolvimento lento.
Na prática, diversos bancos brasileiros entregavam sistemas críticos em velocidade impressionante utilizando conceitos extremamente próximos do RAD, mesmo antes de adotarem oficialmente essa metodologia.
O segredo nunca foi apenas a linguagem.
O segredo sempre foi o processo.
O cenário antes do RAD
Para entender o RAD precisamos voltar aos anos 1980.
A informática corporativa vivia um momento curioso.
Os computadores estavam ficando mais poderosos.
As empresas dependiam cada vez mais dos sistemas.
Mas o desenvolvimento continuava extremamente burocrático.
O modelo dominante era o famoso Waterfall, ou Cascata.
Sua lógica era simples.
Primeiro termina uma fase.
Depois começa a próxima.
Jamais volte atrás.
Na teoria fazia sentido.
Na prática...
Nem tanto.
Imagine desenvolver um sistema bancário durante dezoito meses.
Durante esse período:
novas leis aparecem;
novos produtos financeiros surgem;
a inflação muda;
concorrentes inovam;
clientes mudam de comportamento.
Quando o software finalmente chega à produção...
Ele resolve um problema que talvez nem exista mais.
Era uma época em que modificar requisitos era quase um pecado.
Qualquer alteração significava:
alterar documentos;
alterar diagramas;
alterar especificações;
alterar programas;
alterar testes.
Tudo isso custava muito dinheiro.
Foi nesse ambiente que algumas pessoas começaram a fazer uma pergunta aparentemente simples.
"E se desenvolvêssemos junto com o usuário?"
Essa pergunta mudaria a história da Engenharia de Software.
O nascimento do RAD
O principal responsável pela popularização do RAD foi James Martin.
James Martin era um dos maiores especialistas em Engenharia de Software da época.
Consultor.
Autor.
Pesquisador.
Visionário.
Em 1991 publicou um livro que se tornaria referência mundial:
Rapid Application Development.
Naquele momento ele propôs algo bastante diferente.
Ao invés de gastar meses planejando cada detalhe do sistema...
Construa uma primeira versão.
Mostre ao usuário.
Receba feedback.
Melhore.
Repita.
Hoje isso parece absolutamente normal.
Na época era revolucionário.
Martin defendia que o software não deveria nascer perfeito.
Deveria nascer útil.
Existe uma enorme diferença entre essas duas ideias.
O grande problema que o RAD resolveu
Imagine um gerente de banco.
Ele pede um sistema.
Durante meses responde entrevistas.
Participa de reuniões.
Assina documentos.
Depois desaparece.
Um ano depois recebe o software.
Ao abrir a aplicação percebe algo curioso.
"Não era exatamente isso que eu queria."
Essa frase custava milhões de dólares.
Não porque os programadores eram ruins.
Mas porque pessoas têm dificuldade em imaginar um sistema apenas olhando documentação.
Quando veem uma tela funcionando...
Tudo muda.
Elas descobrem novas necessidades.
Percebem erros.
Lembram regras esquecidas.
Propõem melhorias.
O RAD transformou essa descoberta em metodologia.
Em vez de lutar contra mudanças...
Passe a utilizá-las como parte natural do desenvolvimento.
O princípio mais importante do RAD
Se fosse necessário resumir o RAD em apenas uma frase, seria esta:
O usuário entende melhor um sistema funcionando do que um documento descrevendo esse sistema.
Esse conceito parece óbvio hoje.
Mas revolucionou a forma de desenvolver software.
Em vez de produzir centenas de páginas de documentação...
Construa rapidamente um protótipo.
Mesmo incompleto.
Mesmo simples.
Mesmo temporário.
Porque um protótipo gera discussões muito mais produtivas do que um documento.
É muito mais fácil dizer:
"Esse botão deveria estar aqui."
Do que imaginar onde ele deveria ficar lendo uma especificação técnica.
O que significa "Rapid"
Muita gente interpreta o nome errado.
Rapid não significa:
"Programar correndo."
Nem:
"Escrever código sem qualidade."
Nem:
"Ignorar documentação."
Nem:
"Fazer gambiarra."
Rapid significa reduzir desperdícios.
Eliminar atividades que não agregam valor.
Descobrir erros cedo.
Corrigir rapidamente.
Automatizar tarefas repetitivas.
Construir somente aquilo que realmente será utilizado.
Em outras palavras...
Ser rápido porque o processo ficou melhor.
Não porque os programadores trabalham mais horas.
Os quatro pilares do RAD
Embora existam diversas interpretações, praticamente todas compartilham quatro fundamentos.
1. Desenvolvimento iterativo
Ao invés de entregar tudo no final...
Entregue pequenas partes continuamente.
Cada versão adiciona funcionalidades.
Cada ciclo reduz riscos.
Cada entrega aproxima o produto da necessidade real.
Esse conceito mais tarde inspiraria boa parte do Agile.
2. Prototipação
O protótipo é talvez a característica mais conhecida do RAD.
Ele não precisa ser bonito.
Nem completo.
Seu objetivo é validar ideias.
Quanto antes o usuário interagir...
Melhor.
Hoje fazemos isso com wireframes.
Mockups.
Aplicações Low-Code.
Ferramentas de UX.
Nos anos 90 isso já existia, apenas com tecnologias diferentes.
3. Participação intensa do usuário
No RAD o cliente deixa de ser apenas aprovador.
Ele participa continuamente.
Isso reduz um problema clássico.
Desenvolver exatamente aquilo que ninguém precisava.
Quanto mais próximo estiver o usuário...
Maior a chance de sucesso.
4. Times pequenos e multidisciplinares
Equipes enormes costumam gerar burocracia.
RAD prefere grupos pequenos.
Com autonomia.
Decisão rápida.
Comunicação simples.
Responsabilidade compartilhada.
Décadas depois...
Scrum repetiria praticamente o mesmo conceito.
O ciclo de vida do RAD
Embora existam variações, normalmente encontramos quatro grandes fases.
Planejamento
Define objetivos.
Escopo inicial.
Equipe.
Restrições.
Não tenta prever absolutamente tudo.
Planeja apenas o suficiente para começar.
Design colaborativo
Usuários e desenvolvedores trabalham juntos.
Modelam processos.
Criam protótipos.
Validam telas.
Ajustam regras.
É uma fase extremamente dinâmica.
Construção rápida
Os desenvolvedores começam imediatamente.
Ferramentas de geração automática.
Componentes reutilizáveis.
Bibliotecas.
Frameworks.
Tudo é utilizado para acelerar o trabalho.
Transição
Depois das validações...
O sistema entra em produção.
Mas o ciclo continua.
Novas versões aparecem.
Novos ajustes são realizados.
O software evolui continuamente.
RAD e Engenharia de Software
Existe um mito curioso.
Algumas pessoas acreditam que RAD significa abandonar Engenharia de Software.
Na verdade ocorre exatamente o contrário.
O RAD depende fortemente de boas práticas.
Arquitetura.
Modelagem.
Reutilização.
Padronização.
Automação.
Sem isso...
O desenvolvimento rápido se transforma rapidamente em caos.
Quanto maior a velocidade...
Maior deve ser a disciplina.
RAD versus Waterfall
A comparação mais comum é entre RAD e Cascata.
Waterfall
RAD
Planejamento extenso
Planejamento suficiente
Documentação pesada
Protótipos
Entrega única
Entregas frequentes
Mudanças caras
Mudanças esperadas
Usuário distante
Usuário presente
Descobre erros tarde
Descobre erros cedo
Nenhum modelo é perfeito.
Projetos extremamente regulados ainda utilizam Cascata.
É curioso observar quantas metodologias modernas possuem DNA do RAD.
Scrum utiliza iterações.
Kanban utiliza fluxo contínuo.
Lean elimina desperdícios.
XP incentiva feedback constante.
DevOps aproxima desenvolvimento e operação.
Low-Code acelera construção.
No-Code reduz codificação.
IA Generativa cria protótipos em minutos.
Nenhuma dessas ideias nasceu isoladamente.
Todas beberam, em maior ou menor grau, da mesma fonte: a busca por ciclos curtos de entrega e validação.
Vantagens do RAD
Para o negócio, os benefícios são claros:
redução do tempo de entrega;
menor custo de mudanças;
maior participação do cliente;
melhor alinhamento com o negócio;
menor risco de desenvolver funcionalidades desnecessárias;
maior satisfação dos usuários;
retorno mais rápido do investimento;
possibilidade de corrigir erros antes que se tornem caros.
Para os desenvolvedores, o ganho também é significativo.
Ver o sistema funcionando cedo aumenta a motivação da equipe.
O feedback deixa de ser uma surpresa no final do projeto e passa a orientar o trabalho desde o primeiro ciclo.
Desvantagens e limitações
Nenhuma metodologia resolve todos os problemas.
O RAD também possui limitações.
Projetos gigantescos, envolvendo centenas de equipes e forte dependência regulatória, podem exigir maior formalismo.
Além disso, o sucesso depende da disponibilidade do usuário.
Se o cliente não participa, o principal benefício do RAD desaparece.
Outro ponto crítico é a arquitetura.
A pressa para entregar não pode comprometer a qualidade estrutural da solução.
Sem uma boa arquitetura, cada nova iteração aumenta a dívida técnica.
Mitos sobre o RAD
Ao longo dos anos, alguns equívocos se tornaram comuns.
"RAD é programar sem planejamento." Não. O planejamento existe, mas é adaptativo.
"RAD elimina documentação." Não. Ele elimina documentação desnecessária.
"RAD serve apenas para sistemas pequenos." Não. Grandes organizações o utilizam, desde que combinado com boa governança.
"RAD gera software de baixa qualidade." Também não. Quando bem aplicado, tende a produzir software mais aderente às necessidades do negócio justamente porque recebe feedback constante.
O que um programador COBOL deve aprender com o RAD?
Talvez a maior lição do RAD seja esta:
A velocidade de um projeto não depende apenas da linguagem.
COBOL continua processando bilhões de transações diariamente com confiabilidade incomparável.
O desafio moderno não é substituir COBOL, mas reduzir o tempo entre uma ideia de negócio e sua implementação em produção.
É aí que entram os princípios do RAD.
Prototipação.
Integração contínua.
Automação de testes.
Reutilização de componentes.
Participação ativa do usuário.
Entrega incremental.
Esses conceitos funcionam tão bem em aplicações web quanto em ambientes IBM Z.
Um programa COBOL que expõe serviços por meio do z/OS Connect, integra APIs REST, participa de pipelines DevOps e recebe feedback frequente do negócio está muito mais próximo do espírito do RAD do que muitos sistemas escritos com tecnologias consideradas "modernas".
No fim, o RAD nunca foi sobre velocidade pela velocidade.
Sempre foi sobre reduzir desperdícios, aprender mais cedo e entregar valor continuamente.
Essa ideia nasceu há mais de três décadas, atravessou gerações de linguagens, frameworks e plataformas, e continua moldando a forma como construímos software.
No próximo café, veremos como colocar o RAD em prática: metodologias, ferramentas clássicas e modernas, métricas, governança, performance, integração com Low-Code, IA e um passo a passo completo para implementar RAD com sucesso — inclusive em ambientes IBM Mainframe.
Micky Rosa Entra na Sala de Planning — O Dia em que o Time COBOL Descobriu que Estimar Não É Apostar no Prazo
Ou: por que uma carta “8” não significa oito horas, como uma alteração de três linhas pode esconder um S0C7 internacional e por que o verdadeiro blefe da TI é prometer data antes de entender o programa
Há dois tipos de reuniões que fazem um programador COBOL iniciante olhar para a tela verde e pensar: “eu devia ter aberto uma padaria”.
A primeira é a reunião em que alguém diz:
“É só acrescentar um campo.”
A segunda é a reunião em que alguém responde:
“Quanto tempo leva?”
As duas frases podem parecer inocentes. As duas podem também acordar um monstro adormecido entre uma copybook de 1998, uma tabela Db2 com quarenta colunas, um job noturno que ninguém documentou e um arquivo enviado a uma empresa parceira que só descobre a mudança quando o lote volta com RC=12.
É aqui que entra Agile Estimation: estimativa ágil. Não como ritual para encher um mural de post-its ou como uma competição de quem escolhe o número mais baixo. Estimativa é uma ferramenta para tornar o trabalho visível antes de ele virar incidente.
E, para conduzir esta mesa, chamamos Micky Rosa, o professor de pôquer de Quebrando a Banca.
Micky não entra no CPD usando gravata de gerente e apresentando um cronograma colorido de PowerPoint. Ele olha para o backlog, vê uma história escrita como “adequar sistema à nova regra”, pede um café, olha para o time e pergunta:
“Vocês estão lendo as cartas ou só torcendo para que a próxima seja boa?”
No Agile, estimar é ler as cartas que já estão sobre a mesa: tamanho, incerteza, dependências, risco técnico, conhecimento do time e valor de negócio. Não é prever o futuro com precisão de vidente. É diminuir a chance de entrar em produção sem saber onde fica a saída de emergência.
Prólogo — “Só uma pequena alteração”, disse alguém que nunca abriu uma copybook
Imagine a solicitação:
“Incluir o campo PERCENTUAL-DESCONTO no cadastro de clientes.”
Para uma pessoa que está começando em COBOL, parece uma mudança modesta:
01 WS-PERCENTUAL-DESCONTO PIC 9(3)V99.
Pronto. Uma linha nova. Talvez duas, se houver edição. Cinco minutos, certo?
Micky Rosa baixa as cartas. O analista experiente abre o ISPF. A história começa a revelar suas cartas escondidas.
O campo precisa:
aparecer na tela CICS;
receber validação;
ser gravado na tabela Db2;
entrar no SELECT, no INSERT e no UPDATE;
talvez exigir alteração de DCLGEN;
aparecer em relatórios;
ser enviado para um arquivo de integração;
ser lido pelo batch noturno;
afetar cálculo de faturamento;
ser registrado para auditoria;
passar por teste integrado;
ser promovido por uma cadeia de homologação;
ter plano de retorno caso a mudança cause erro.
Aquela “linha nova” deixou de ser uma linha. Ela agora é uma alteração transversal.
No universo mainframe, o programa COBOL raramente vive sozinho. Ele mora num condomínio antigo, muito eficiente, com regras, vizinhos e portaria.
Usuário
↓
Tela CICS
↓
Programa COBOL
↓
Copybook / validações
↓
Db2 ou VSAM
↓
JCL batch / arquivos / MQ / sistemas parceiros
↓
Auditoria, operação e reconciliação
A estimativa boa não pergunta apenas “quanto código será escrito?”. Ela pergunta:
“Quais sistemas, regras, dados, pessoas e riscos acordam quando mexemos nesta parte?”
1. Estimativa não é prazo, não é promessa e não é produtividade individual
Essa é a primeira regra que Micky escreveria na parede da sala de planning.
Uma estimativa é uma avaliação de tamanho ou esforço provável. Um prazo é uma data no calendário. Um compromisso é uma decisão explícita de entrega. Produtividade é outra conversa ainda.
Misturar tudo cria a clássica tragédia corporativa:
o time dá uma estimativa;
alguém transforma a estimativa em data;
alguém transforma a data em promessa;
alguém transforma a promessa em cobrança;
o time aprende a inflar números para sobreviver;
a empresa conclui que “Agile não funciona”.
Não foi o Agile que falhou. Foi o uso da estimativa como arma contratual.
Pontos não são horas
Muitas equipes usam Story Points, pontos de história. Eles representam tamanho relativo, não tempo exato.
Se uma pequena correção conhecida vale 1 ponto e uma mudança com impacto em COBOL, Db2 e batch parece cinco vezes mais complexa, ela pode receber 5 pontos.
Isso não significa:
5 pontos = 5 horas
Nem:
8 pontos = 8 dias
Pontos são como fichas de pôquer: seu valor é compreendido pela mesa, não por quem chega de fora querendo converter tudo para reais.
Uma equipe pode concluir, após algumas sprints, que normalmente entrega cerca de 20 a 25 pontos por sprint. Isso é sua velocidade histórica. Ajuda a fazer previsões coletivas.
Mas cuidado: velocidade não é placar individual.
Comparar desenvolvedores por pontos é como avaliar um cirurgião pela quantidade de pontos que ele deu no paciente. A métrica pode até crescer; o resultado que importa pode piorar muito.
2. O que o time realmente estima?
Uma boa estimativa mistura pelo menos quatro cartas.
Esforço
Quanto trabalho será necessário: análise, código, testes, documentação, implementação, acompanhamento.
Complexidade
Quantas partes interagem? Há regras de cálculo? Há várias tabelas? Existem caminhos alternativos? O fluxo CICS chama outros módulos?
Risco
O que pode falhar? Há mudança em tabela crítica? Existe janela batch apertada? A alteração afeta folha, crédito, PIX, cobrança ou relatório regulatório?
Incerteza
O que ainda não sabemos? Há documentação? O dono de negócio confirmou a regra? O fornecedor respondeu? Alguém sabe quem consome aquele arquivo?
Uma história com pouco código pode ser grande porque tem alto risco ou alta incerteza. É por isso que a estimativa feita apenas olhando o número de linhas COBOL costuma ser uma armadilha.
Um MOVE pode ser simples. Um MOVE dentro de um programa que alimenta liquidação financeira às 2h da manhã talvez seja um convite para conhecer a equipe de operação antes do café.
3. Antes de estimar: refinamento, o detector de blefe
Em Quebrando a Banca, ninguém deveria entrar numa mesa sem observar o jogo. Em Agile, ninguém deveria estimar uma história que ainda é uma névoa poética.
Veja este item:
“Modernizar o sistema de cadastro.”
Isso não é uma história pronta. É uma declaração de intenções, talvez um pedido de socorro, talvez o começo de uma tese de doutorado.
Compare com:
“Como analista de atendimento, quero visualizar o percentual de desconto aprovado no cadastro CICS para conferir a regra aplicada antes de confirmar a operação.”
Agora já existe usuário, necessidade e contexto. Ainda faltam detalhes, mas existe algo conversável.
Antes da estimativa, faça perguntas simples e devastadoras.
Qual problema de negócio será resolvido?
Quem usa a função?
Qual é o critério de aceite?
Onde o dado nasce?
Onde ele é validado?
Onde ele é persistido?
Que programas o leem?
Há impacto em Db2, VSAM, CICS, IMS, MQ ou arquivos?
Há batch noturno?
Existe integração externa?
Quem testa?
Como a alteração será desfeita se algo der errado?
Há requisito de auditoria, segurança ou LGPD?
Qual é a dependência mais perigosa?
Se ninguém sabe responder, não chute um número. Crie uma spike.
Spike: a investigação com crachá e prazo
Uma spike é uma tarefa curta de descoberta. Ela não entrega a funcionalidade final; ela reduz incerteza.
Exemplo:
“Em até dois dias, mapear programas COBOL, tabelas Db2, layouts de arquivo e jobs afetados pelo novo percentual de desconto.”
No fim da spike, a equipe deve produzir algo útil:
lista de componentes impactados;
riscos encontrados;
opções técnicas;
protótipo;
decisão de arquitetura;
nova história mais clara e estimável.
A spike é o momento em que o time deixa de perguntar “quanto custa?” e passa a perguntar “o que estamos comprando?”.
4. As oito técnicas de estimativa — e o que elas fazem de verdade
A imagem original apresenta oito técnicas úteis. Algumas são excelentes para estimar; outras funcionam melhor para organizar ou priorizar. A diferença importa.
Vamos percorrê-las como se Micky Rosa estivesse ensinando uma equipe COBOL a perceber que não existe “uma técnica mágica”, apenas ferramentas adequadas para cada mesa.
4.1 Affinity Mapping — agrupar antes de numerar
No Affinity Mapping, o time coloca várias histórias lado a lado e agrupa itens que parecem ter tamanho parecido.
Você pode começar com colunas como:
Muito pequeno | Pequeno | Médio | Grande | Muito grande | Incerto
Depois, caso necessário, converte para Story Points:
1 | 2 | 3 | 5 | 8 | 13
Imagine estas solicitações:
corrigir texto de mensagem CICS;
ajustar máscara de data;
incluir validação de CPF;
acrescentar campo em tabela Db2;
criar novo extrato batch;
alterar cálculo de juros e reprocessar histórico.
Mesmo antes de discutir números, o grupo enxerga que as duas primeiras são pequenas, a alteração Db2 é média ou grande, e o reprocessamento histórico pode ser uma criatura de 13 pontos ou maior.
Quando usar
Use Affinity Mapping quando houver muitas histórias e pouco tempo. É excelente para organizar backlog antes de um planejamento de release.
Cuidado mainframe
Não agrupe apenas pelo “tipo de tecnologia”. Duas histórias que mexem em Db2 podem ter tamanhos totalmente diferentes:
adicionar um índice pode ser previsível;
mudar uma chave de negócio pode afetar integridade, performance, batch, replicação e reconciliação.
O nome da tecnologia não informa o risco sozinho.
4.2 Big, Small, Unclear — a triagem que salva a sprint
Esta técnica é quase um raio-X do backlog. Em vez de fingir precisão, o time separa itens em três grupos:
Big: grande demais, provavelmente precisa ser quebrado;
Small: entendido e manejável;
Unclear: ainda não sabemos o suficiente.
É simples e poderoso porque normaliza uma frase que deveria ser mais comum em TI:
“Ainda não sabemos.”
Isso não é incompetência. É honestidade operacional.
Exemplo:
Solicitação
Classificação
Por quê?
Corrigir título de tela CICS
Small
Escopo local e claro
Implantar nova tabela de tarifas
Big
Regras, dados, telas, batch e integração
Adequar à norma regulatória
Unclear
Norma, escopo e impactos precisam ser entendidos
O erro mais comum é tratar “Unclear” como “8 pontos”. Não. “Unclear” pode virar 2, 13 ou uma iniciativa inteira. Primeiro investigue.
4.3 Ordering Protocol — colocando as cartas em ordem
No Ordering Protocol, o grupo ordena itens do menor para o maior. Não começa discutindo se algo é 3 ou 5. Começa perguntando:
“Esta história é maior ou menor que aquela?”
A equipe move os cartões até formar uma sequência coerente.
Exemplo:
Ajustar texto
↓
Validar data
↓
Incluir campo em tela e COBOL
↓
Alterar tabela Db2 e batch
↓
Reprocessar histórico financeiro
Por que funciona?
Porque seres humanos costumam comparar melhor do que medir em absoluto. É mais fácil dizer que um cachorro é maior que um gato do que definir precisamente seu “índice universal de cachorridade”.
No desenvolvimento, comparar reduz discussões artificiais. Se todos concordam que uma história é maior que outra, a escala final fica mais natural.
Dica Bellacosa
Mantenha algumas histórias de referência, conhecidas e já entregues:
“Alteração simples em CICS” = 2 pontos;
“Novo campo Db2 com batch” = 5 pontos;
“Nova regra financeira com integração” = 8 pontos.
Elas funcionam como marcos de quilometragem para a equipe.
4.4 Bucket System — o facilitador organiza, o time decide
O Bucket System acelera a estimativa de uma grande lista de itens. Colocam-se “baldes” de tamanho:
0 | 1 | 2 | 3 | 5 | 8 | 13 | 21 | ?
O facilitador organiza a dinâmica, mas não deveria sair distribuindo pontos sozinho como professor corrigindo prova. A equipe posiciona as histórias, depois revisa os casos controversos.
É ótimo para uma sessão de planejamento trimestral, quando há dezenas de demandas.
Regra de sobrevivência
Quando uma história cai em 21, XL ou “maior que isto”, ela está mandando um recado:
“Quebre-me antes que eu quebre a sprint.”
Uma história grande deve ser fatiada por valor e por fluxo de negócio, não simplesmente por camada técnica.
Ruim:
criar tabela;
criar programa;
criar tela.
Melhor:
permitir registrar desconto manual até determinado limite;
permitir consultar desconto aplicado;
gerar desconto aprovado no arquivo de faturamento.
O segundo corte produz partes testáveis e úteis. O primeiro cria uma sequência técnica que só entrega valor no final.
4.5 Planning Poker — a técnica em que a divergência é ouro
Planning Poker é o clássico. Cada pessoa escolhe sua carta em silêncio, todos revelam ao mesmo tempo e as diferenças são discutidas.
Uma escala comum é Fibonacci:
0, 1, 2, 3, 5, 8, 13, 21, ?
Por que Fibonacci? Porque a incerteza cresce junto com o tamanho. A diferença entre 1 e 2 é pequena; entre 13 e 14 quase ninguém conseguiria justificar com seriedade.
Imagine a história:
“Adicionar desconto especial ao cadastro e usar o valor no faturamento.”
O desenvolvedor A escolhe 3. O desenvolvedor B escolhe 13.
Antes de escolher “8, para fazer média”, Micky Rosa interrompe:
“Por que 3? Por que 13?”
Talvez o A tenha pensado apenas na tela e no programa online. B talvez saiba que o faturamento é batch, que existe reprocessamento, que o arquivo vai para uma parceira externa e que a alteração exige homologação regulatória.
A divergência revelou conhecimento que não estava no ticket.
Essa é a verdadeira função do Planning Poker: transformar conhecimento individual em consciência coletiva.
Como conduzir bem
Leia a história e os critérios de aceite.
Tire dúvidas essenciais.
Cada pessoa escolhe uma carta sem mostrar.
Todos revelam ao mesmo tempo.
Quem escolheu o menor e o maior número explica o raciocínio.
Discuta impactos, riscos e suposições.
Vote novamente.
Registre decisões e pendências.
Não é necessário unanimidade religiosa. É necessário entendimento suficiente para trabalhar com responsabilidade.
4.6 Three-Point Estimation — otimismo, realidade e o fantasma do pior caso
A estimativa de três pontos é útil quando risco e prazo precisam ser discutidos de forma mais explícita.
Você calcula três cenários:
Otimista (O): tudo ocorre bem;
Mais provável (M): cenário normal;
Pessimista (P): problemas realistas acontecem.
Uma fórmula PERT bastante usada é:
Exemplo: descobrir impacto de uma mudança em arquivo bancário.
O = 2 dias, se houver documentação e nenhum consumidor oculto;
M = 5 dias, se for necessário validar programas e testes;
P = 12 dias, se houver fornecedor, layout antigo e reconciliação histórica.
A conclusão não é “prometa 5,7 dias”. A conclusão é:
“A previsão central é próxima de seis dias, mas existe risco considerável. Precisamos tratar as causas que levam ao cenário de doze.”
Talvez a ação correta seja envolver o fornecedor cedo, recuperar layout oficial do arquivo ou fazer uma spike.
Curiosidade
A técnica vem de ideias usadas em PERT, método criado para lidar com projetos complexos e incertos. Ela continua relevante porque reconhece algo que alguns cronogramas tentam esconder: o futuro não vem em linha reta.
4.7 Dot Voting — escolha o que vem antes, não o que “dá mais trabalho”
Dot Voting é uma ótima técnica, mas é frequentemente colocada no lugar errado.
Ela é mais útil para priorização do que para estimativa.
Cada pessoa recebe, por exemplo, três pontos adesivos e vota nas iniciativas que acredita terem maior valor, urgência ou redução de risco.
Você pode perguntar:
qual item reduz maior risco operacional?
qual atende obrigação legal?
qual elimina maior volume de trabalho manual?
qual beneficia mais usuários?
qual precisa ser descoberto primeiro?
Considere este backlog:
Item
Valor
Esforço
Corrigir falha RACF
Alto
Médio
Modernizar cores de tela
Baixo
Pequeno
Adequar obrigação legal
Muito alto
Grande
Automatizar conciliação manual
Alto
Médio
Os votos ajudam a escolher o que vem primeiro. A estimativa ajuda a entender quanto custa. As duas coisas não são iguais.
O item mais urgente pode ser o maior. O item mais fácil pode ter valor mínimo. Confundir prioridade com tamanho é como escolher uma rota de avião apenas pela distância, ignorando tempestade, combustível e aeroporto de destino.
4.8 T-shirt Sizing — o roadmap de camiseta
T-shirt Sizing usa tamanhos:
XS | S | M | L | XL
É uma maneira rápida de discutir tamanho em níveis altos, antes de existir detalhe suficiente para Planning Poker.
Tamanho
Interpretação prática
XS
mudança local, muito conhecida
S
alteração pequena e previsível
M
vários pontos de impacto, caminho claro
L
regra complexa ou integração relevante
XL
grande demais; dividir ou investigar
É especialmente bom em conversas de roadmap com negócio e gestão. Ninguém precisa fingir que já sabe o número de horas de uma iniciativa que será feita daqui a seis meses.
Micky Rosa diria:
“Você não precisa saber a carta exata antes de ela ser virada. Mas precisa saber se está apostando uma ficha ou a mesa inteira.”
5. Como estimar uma história COBOL: passo a passo
Vamos usar uma história completa:
“Como analista de crédito, quero aplicar percentual de desconto autorizado ao cálculo da parcela, para que clientes elegíveis recebam a condição comercial aprovada.”
Passo 1 — Entenda o fluxo de negócio
Antes de abrir o código, descubra:
quem autoriza o desconto;
qual limite é permitido;
o desconto vale para todas as parcelas?
existe validade?
há necessidade de trilha de auditoria?
é permitido alterar desconto depois de faturado?
Passo 2 — Mapeie os componentes técnicos
Procure:
programa COBOL online;
BMS map e tela CICS;
copybooks;
tabelas Db2;
SQL embutido;
DCLGEN;
jobs JCL;
arquivos de interface;
programas batch;
relatórios;
rotinas de auditoria;
testes existentes.
A ferramenta pode mudar — ISPF, IDz, VS Code com extensões, busca em repositório —, mas a pergunta é a mesma: “onde esse dado vive e para onde ele viaja?”
Passo 3 — Liste riscos e dependências
Por exemplo:
alteração de tabela exige DBA;
mudança no arquivo exige acordo com parceiro;
o batch tem janela curta;
não existe ambiente de teste representativo;
o cálculo é usado por vários produtos;
há massa histórica que precisa ser preservada.
Passo 4 — Quebre a história, se necessário
Talvez ela seja grande demais. Você pode separar:
cadastrar e consultar o desconto;
validar limites e registrar auditoria;
usar desconto em novo faturamento;
avaliar necessidade de reprocessamento histórico.
Não esconda o reprocessamento dentro da história principal como se fosse uma nota de rodapé. Reprocessamento financeiro é quase sempre uma carta que merece ser vista.
Passo 5 — Escolha a técnica
poucas histórias importantes: Planning Poker;
muitas histórias parecidas: Affinity Mapping ou Buckets;
muita incerteza: Spike e Three-Point Estimation;
roadmap inicial: T-shirt Sizing.
Passo 6 — Registre suposições
Uma estimativa sem suposição documentada vira discussão de memória seletiva depois.
Exemplo:
Estimativa de 8 pontos, assumindo que não haverá alteração retroativa de parcelas já faturadas e que o layout externo não muda.
Se a regra mudar, a estimativa muda. Não é “o time errou”. O escopo foi alterado.
6. Os erros que fazem a estimativa virar cassino sem Micky Rosa
Estimar sem critério de aceite
“Criar relatório” pode significar qualquer coisa entre um DISPLAY em batch e um documento regulatório com reconciliação, assinatura, distribuição e retenção.
Usar estimativa para pressionar pessoas
Quando a estimativa vira cobrança individual, todos aprendem a se defender, não a colaborar.
Transformar pontos em horas
Pontos são comparativos. Horas são calendário e disponibilidade. Ambas podem coexistir, mas não são sinônimos.
Esquecer trabalho invisível
Análise, testes, revisão, documentação, deploy, acompanhamento pós-produção e correção de falhas fazem parte da entrega.
Se um time estima apenas “tempo de codar”, está tratando o desenvolvimento como se COBOL compilasse, sorrisse e se promovesse sozinho.
Aceitar histórias XL dentro da sprint
Uma história gigante diminui previsibilidade, dificulta teste e costuma terminar com a frase “está 90% pronto” durante três semanas.
Em sistemas críticos, 90% pronto pode significar 0% entregável.
Confundir estimativa com adivinhação
Uma estimativa muda quando aparece informação nova. Isso é esperado.
O erro não é atualizar a previsão; erro é fingir que a informação nova não existe para proteger uma data antiga.
7. O verdadeiro poder escondido da estimativa Agile
A maior entrega de uma boa sessão de estimativa não é o número 5, 8 ou 13.
É o time descobrir, antes da produção:
que há uma copybook compartilhada;
que o campo também precisa existir no arquivo;
que a tabela Db2 possui dependências;
que existe uma regra de auditoria;
que o batch usa uma lógica diferente da tela;
que outro sistema consome o dado;
que a regra de negócio ainda não foi decidida.
A estimativa cria conversa técnica. A conversa técnica cria entendimento. O entendimento diminui retrabalho, incidentes e aquela famosa reunião de crise em que todos dizem “ninguém avisou”.
No mundo COBOL, em que décadas de regra de negócio podem estar preservadas dentro de programas, JCL, CICS e Db2, isso vale ouro.
Epílogo — a lição de Micky Rosa para o programador iniciante
O programador iniciante muitas vezes acha que estimar é uma tarefa de gerente, Scrum Master ou analista. Não é. Sua visão técnica é parte essencial do processo.
Quando você pergunta:
“Esse campo também entra no arquivo de fechamento?”
ou:
“Há programas batch que leem esta tabela?”
ou ainda:
“Como vamos testar o retorno se a atualização Db2 falhar no meio?”
você não está “complicando”. Está evitando que a mesa inteira aposte sem ver as cartas.
Agile não pede que você prometa o impossível com um sorriso e um post-it. Ele pede que o time enxergue o trabalho com clareza suficiente para tomar decisões melhores.
Então, na próxima vez que alguém disser “é só uma alteração pequena”, faça como Micky Rosa: observe a mesa, confira o histórico, pergunte o que está escondido e só então coloque sua ficha.
Porque, no mainframe, a alteração pequena quase sempre começa pequena.
O restante da história costuma estar escondido em alguma copybook.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
