 |
| Bellacosa Mainframe agile sem misterios no ibm z |
☕ Um Café no Bellacosa Mainframe
Agile sem Mistérios no IBM Z
O Guia Definitivo do Programador COBOL Padawan para Sobreviver ao Mundo Ágil sem Esquecer as Lições da Tela Verde
"Um Jedi não luta contra a mudança. Ele aprende a usá-la a seu favor."
Existe um momento na vida de praticamente todo programador COBOL em que alguém entra na sala e anuncia:
"A partir da próxima semana vamos trabalhar em Agile."
Imediatamente surgem dezenas de pensamentos.
"Mas COBOL não é batch?"
"Como fazer Sprint se meu programa roda quatro horas?"
"Quem inventou Daily Meeting?"
"O Product Owner entende o que é um SQLCODE -904?"
"Como colocar DevOps num ambiente onde existe Change Management, CAB, RACF, CICS, Db2, IMS e três ambientes de homologação?"
Respire.
A boa notícia é que praticamente todos os grandes bancos do planeta trabalham hoje utilizando alguma adaptação de Agile sobre IBM Z.
Na verdade...
Existe uma ironia curiosa.
O mainframe já fazia diversas coisas "ágeis" muito antes do Manifesto Ágil existir.
Vamos descobrir por quê.
A Grande Mentira Sobre Agile
Muitos iniciantes acreditam que Agile significa:
trabalhar rápido.
Não.
Outros acreditam que significa:
fazer reuniões.
Também não.
Outros imaginam:
não existe documentação.
Errado novamente.
Agile significa algo muito mais simples.
Reduzir o custo da mudança.
Essa é a verdadeira definição.
Quanto mais cedo você descobrir um erro...
...mais barato ele fica.
O Mundo Antes do Agile
Imagine desenvolver um sistema bancário em 1988.
O fluxo era mais ou menos assim:
Levantamento
↓
Análise
↓
Especificação
↓
Projeto
↓
Programação
↓
Testes
↓
Homologação
↓
Produção
Tudo parecia organizado.
O problema?
O cliente só via o sistema depois de um ano.
Quando via...
Descobria que queria outra coisa.
Dinheiro perdido.
O Manifesto Ágil
Em 2001, dezessete especialistas reuniram-se nas montanhas de Utah.
Eles perceberam algo curioso.
Os projetos que davam certo...
...quase nunca seguiam o processo enorme definido nos livros.
Então criaram quatro valores famosos.
Pessoas acima de processos.
Software funcionando acima de documentos gigantes.
Colaboração acima de contratos.
Adaptabilidade acima de seguir planos cegamente.
Observe.
Eles nunca disseram que documentação é ruim.
Disseram apenas que ela não pode ser mais importante que entregar valor.
O IBM Z Sempre Foi Mais Ágil do Que Parece
Aqui vem um dos primeiros easter eggs.
Muito antes do Scrum existir...
o operador de produção já fazia ciclos extremamente curtos.
Imagine.
Executa Job
↓
Analisa JESMSGLG
↓
Corrige JCL
↓
Executa novamente
Isso é um loop.
Agile adora loops.
Outro exemplo.
Compile
↓
Linkedit
↓
Teste
↓
Erro
↓
Corrige
↓
Compile novamente
Outro Sprint.
Sem ninguém perceber.
O Backlog no Mainframe
Imagine um banco.
Backlog:
Novo PIX
Nova TED
Mudança no boleto
Correção fiscal
Nova regra do BACEN
Mudança LGPD
Novo relatório
Integração Open Finance
Atualização cambial
Tudo isso entra numa única fila.
Essa fila é o Product Backlog.
Ela muda diariamente.
Quem Decide?
No mundo COBOL existe uma figura curiosa.
O usuário de negócio.
Ele normalmente conhece:
contas
empréstimos
cartões
seguros
Mas talvez nunca tenha ouvido falar em:
DSNHLI
SQLCA
RACF
IMS
CICS
VSAM KSDS
É exatamente por isso que existe o Product Owner.
Ele traduz o negócio.
Você traduz tecnologia.
Sprint
Agora imagine um Sprint de duas semanas.
Objetivo:
Permitir PIX Agendado.
Não é:
Modificar programa COBOL.
Observe a diferença.
O Sprint entrega valor.
Não código.
O Trabalho do Padawan COBOL
Durante o Sprint você pode receber tarefas como:
Modificar programa COBOL.
Criar novo COPYBOOK.
Alterar tabela Db2.
Criar PACKAGE.
Executar BIND.
Modificar CICS.
Atualizar MQ.
Criar API via z/OS Connect.
Tudo isso pertence ao mesmo Sprint.
A Daily Meeting
Aqui nasce uma das maiores lendas do Agile.
A Daily NÃO existe para o gerente descobrir quem trabalhou.
Ela serve para sincronizar conhecimento.
Imagine dez desenvolvedores.
Sem Daily.
Todos alteram o mesmo COPYBOOK.
Caos.
Com Daily.
Todos sabem quem está mexendo em quê.
User Story
No Agile quase tudo começa assim.
Como cliente
Quero agendar um PIX
Para realizar pagamentos futuros.
Isso parece simples.
Mas escondido existem dezenas de tarefas.
COBOL.
Db2.
MQ.
Logs.
SMF.
Segurança.
RACF.
Auditoria.
Rollback.
Monitoramento.
Performance.
Definition of Done
Esse conceito salva projetos.
Pronto significa:
Compila?
Sim.
Testado?
Sim.
Code Review?
Sim.
Documentado?
Sim.
Pipeline passou?
Sim.
Deploy aprovado?
Sim.
Agora sim.
Agile no Batch
Muitos acreditam:
"Batch não combina com Agile."
Grande engano.
Imagine um processamento noturno.
Antes:
8 horas
↓
ABEND S0C7
↓
Descobre de manhã.
Hoje:
Testes automatizados.
Validação.
Mock.
Datasets de teste.
Pipeline.
Muito menos risco.
Agile e CICS
Imagine uma transação bancária.
Sprint:
Criar nova tela BMS
↓
Modificar COBOL
↓
Atualizar MAPSET
↓
Testar CEDF
↓
Publicar
Tudo acontece dentro de um Sprint.
Agile e Db2
Outro exemplo.
Nova tabela
↓
DDL
↓
RUNSTATS
↓
BIND PACKAGE
↓
BIND PLAN
↓
Testes
↓
Deploy
Observe.
Não existe "programar".
Existe entregar uma funcionalidade.
Agile e DevOps
Hoje praticamente todo ambiente moderno IBM Z trabalha próximo disso:
Git
↓
Commit
↓
Pipeline
↓
Compile COBOL
↓
DBB
↓
Testes
↓
Code Review
↓
Deploy automático
↓
Validação
↓
Produção
Isso é Agile em estado puro.
O Grande Inimigo
O maior inimigo do Agile não é o waterfall.
É o multitasking.
Imagine.
Você começa:
Projeto A.
Parou.
Projeto B.
Parou.
Projeto C.
Parou.
Projeto D.
No fim...
Nada termina.
O Custo da Mudança
Existe um gráfico famoso.
Quanto mais tarde um erro aparece...
Mais caro fica.
No mainframe isso é ainda mais verdadeiro.
Imagine descobrir em produção:
MOVEs invertidos
↓
Saldo incorreto
↓
Milhões de contas afetadas
Quanto custou?
Muito.
Testes Automatizados
O Padawan moderno aprende rapidamente:
Testar manualmente não escala.
Hoje temos:
ZUnit.
Galasa.
IBM Z Virtual Test Platform.
Frameworks internos.
Tudo isso reduz riscos.
Integração Contínua
O velho fluxo:
sexta-feira
↓
deploy
↓
rezar
Foi substituído por:
Commit
↓
Pipeline
↓
Testes
↓
Deploy
Muito menos adrenalina.
Easter Egg nº 1
Você sabia?
O conceito de Sprint lembra muito os ciclos usados pela NASA durante o Projeto Apollo.
Os engenheiros entregavam pequenas evoluções sucessivas em vez de esperar a conclusão de todo o sistema.
Embora o Scrum moderno tenha outra origem, essa abordagem iterativa já aparecia em grandes projetos décadas antes.
Easter Egg nº 2
O próprio JES2 já trabalha em filas priorizadas.
Jobs possuem classes.
Prioridades.
Filas.
Dependências.
Curiosamente...
Muito parecido com um Backlog.
Easter Egg nº 3
O famoso ciclo
Editar
↓
Compile
↓
Execute
↓
Corrija
Existe desde os primeiros compiladores FORTRAN dos anos 1950.
Agile apenas expandiu essa filosofia para toda a organização.
Curiosidade
O maior Sprint do mundo provavelmente acontece diariamente.
Milhões de transações bancárias.
Bilhões de SQLs.
Milhares de Jobs.
Tudo funcionando continuamente.
O cliente nem percebe.
Dicas do Mestre Bellacosa
Nunca comece programando.
Leia a User Story.
Entenda o problema.
Converse com o usuário.
Cinco minutos de conversa economizam cinco dias de retrabalho.
Faça pequenas alterações.
Grandes mudanças geram grandes ABENDs.
Compile frequentemente.
Esperar três dias para compilar é receita para desastre.
Automatize tudo.
Quanto menos trabalho manual...
Menos erro humano.
Faça Code Review.
Quatro olhos encontram erros que dois ignoram.
Conheça o fluxo inteiro.
Não seja apenas "o programador COBOL".
Entenda:
JCL.
Db2.
MQ.
CICS.
IMS.
RACF.
SMF.
JES2.
Quanto maior sua visão...
Maior seu valor.
Perigos do Agile
Daily infinita
Se durar uma hora...
Não é Daily.
Sprint sem objetivo
"Vamos fazer algumas tarefas."
Isso não é Sprint.
Product Owner ausente
Sem prioridades...
Tudo vira prioridade.
Backlog gigante
Cinco mil histórias.
Ninguém consegue administrar isso.
Dívida técnica
"Depois corrigimos."
Depois nunca chega.
Falta de testes
Agile sem testes automatizados vira loteria.
Deploy manual
Copiar Load Module na mão em pleno século XXI aumenta o risco operacional.
Mudanças durante o Sprint
Se tudo muda todos os dias...
Nada termina.
Vantagens
✔ Feedback constante.
✔ Menor risco.
✔ Cliente participa.
✔ Correções rápidas.
✔ Maior qualidade.
✔ Melhor previsibilidade.
✔ Integração entre equipes.
✔ Evolução contínua.
✔ Entregas frequentes.
✔ Melhor moral da equipe.
Desvantagens
Também existem.
Nem tudo são flores.
Agile pode sofrer quando:
a organização não dá autonomia ao time;
o Product Owner não consegue priorizar;
a equipe é constantemente interrompida por demandas urgentes;
a documentação é negligenciada em nome da velocidade;
há dependências fortes de sistemas legados sem planejamento adequado.
Além disso, ambientes regulados — comuns no setor financeiro — exigem controles formais de auditoria, segregação de funções e aprovação de mudanças. O desafio não é abandonar essas práticas, mas integrá-las ao fluxo ágil com automação, pipelines e governança.
O Caminho do Programador COBOL Padawan
No universo Bellacosa Mainframe, Agile não é um modismo nem uma desculpa para fazer reuniões. É uma maneira de reduzir riscos, aprender continuamente e entregar valor sem comprometer a estabilidade do IBM Z.
O Padawan que domina apenas COBOL escreve bons programas. O que compreende Agile, DevOps, testes automatizados, observabilidade, integração contínua, arquitetura e o ciclo de vida completo do software torna-se um profissional capaz de dialogar com desenvolvedores distribuídos, arquitetos, analistas de negócio, DBAs, administradores CICS e equipes de operações.
No fim da jornada, a maior lição é simples: o verdadeiro poder do Agile não está nos Sprints, nas Dailies ou nos quadros Kanban. Está na capacidade de transformar conhecimento em melhoria contínua. É exatamente isso que mantém o IBM Z relevante há mais de seis décadas: evoluir constantemente sem abrir mão da confiabilidade.
Como diria um velho Mestre Jedi do datacenter:
"O código pode ser legado. A forma de pensar nunca deve ser."
Sem comentários:
Enviar um comentário