 |
| 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:
Requisitos → análise → desenho → desenvolvimento → testes → implantação.
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,
EXPLAINeBINDquando 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.
