 |
| Bellacosa Mainframe e o conceito do backlog na stack mainframe |
☕ Um Café no Bellacosa Mainframe
Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe
"No mundo IBM Z, um programa COBOL raramente quebra por causa de uma linha de código. Quase sempre ele quebra porque existe um backlog que ninguém quis enxergar."
Existe uma palavra que todo profissional de TI escuta diariamente: Backlog.
Ela aparece em reuniões ágeis, em SCRUM, em Kanban, nos relatórios do gerente, nos dashboards do Jira e até em apresentações do CIO.
Mas curiosamente, poucos programadores COBOL entendem o verdadeiro significado do backlog.
Para um Padawan Mainframe, backlog costuma parecer apenas uma lista enorme de tarefas.
Na realidade, backlog é muito mais parecido com um dataset VSAM KSDS.
Ele armazena tudo que ainda precisa ser processado.
Se ele estiver organizado, o sistema flui.
Se estiver corrompido...
Você acabou de criar o próximo ABEND da equipe.
Imagine um Batch Noturno
Pense em um JOB executando durante a madrugada.
Ele possui:
milhares de registros
prioridades
dependências
checkpoints
reprocessamentos
Agora substitua os registros por atividades.
Pronto.
Você acabou de entender o backlog.
O backlog é simplesmente o conjunto de trabalho que ainda será executado.
Mas existe uma diferença enorme entre:
muito trabalho
e
backlog saudável.
O Backlog Não É o Problema
O backlog é inevitável.
Todo sistema vivo possui backlog.
Até o z/OS trabalha com filas.
JES2 possui filas.
CICS possui filas.
MQ possui filas.
IMS possui filas.
DB2 possui locks esperando.
Tudo funciona através de filas.
O problema nunca foi possuir backlog.
O problema é possuir um backlog que ninguém entende.
Como Nasce um Backlog
Imagine um sistema bancário.
Hoje o gerente pede:
Criar PIX.
Depois:
alterar TED.
Depois:
corrigir boleto.
Depois:
adequação ao Banco Central.
Depois:
LGPD.
Depois:
Open Finance.
Depois:
PIX Automático.
Depois:
IA.
Depois:
APIs REST.
Cada solicitação entra.
Nem todas saem.
O resultado?
Um backlog crescente.
O Backlog Invisível
O pior backlog é o invisível.
Ele mora em frases como:
"Depois a gente vê."
"Na próxima Sprint."
"Isso fica para outro momento."
"É uma melhoria."
"Não é urgente."
Meses depois...
Existem centenas delas.
Backlog Técnico
Nem todo backlog é funcional.
Existe também:
melhoria de performance
reorganização de programas
limpeza de código
documentação
atualização de COPYBOOKS
reorganização DB2
índices
compressão VSAM
testes
Tudo isso entra no backlog.
Como Identificar um Backlog Doente
Um backlog começa a adoecer quando aparecem sintomas.
Sintoma 1
Todo mundo pergunta:
"O que devemos fazer agora?"
Isso significa ausência de prioridade.
Sintoma 2
Existem tarefas de três anos atrás.
Se ninguém fez em três anos...
Talvez nunca devesse existir.
Sintoma 3
Existem tarefas duplicadas.
Muito comum.
Um analista abre:
"Corrigir cálculo."
Outro abre:
"Ajustar juros."
Outro:
"Problema financeiro."
São o mesmo erro.
Sintoma 4
Ninguém sabe explicar a tarefa.
Descrição:
"Verificar erro."
Qual erro?
Onde?
Quando?
Por quê?
Sintoma 5
Todo item é prioridade máxima.
Quando tudo é urgente...
Nada é urgente.
Como um Programador COBOL Deve Ler um Backlog
Nunca leia apenas o título.
Leia:
requisito
regra de negócio
programas envolvidos
COPYBOOKS
arquivos
tabelas DB2
transações CICS
JCL
impacto
A tarefa começa muito antes do código.
O Erro do Padawan
O Padawan pensa:
"Recebi uma tarefa."
O profissional experiente pensa:
"Recebi um problema de negócio."
Isso muda tudo.
Como Evoluir um Backlog
Existe uma prática chamada:
Backlog Refinement
Ou refinamento.
No Mainframe isso seria parecido com preparar um JOB antes da produção.
Você elimina ambiguidades.
Durante o refinamento fazemos perguntas.
O usuário realmente quer isso?
Existe impacto financeiro?
Existe impacto jurídico?
Existe cálculo?
Existe histórico?
Existe rollback?
Existe auditoria?
Existe logging?
Existe batch?
Existe online?
Existe integração?
Quanto mais perguntas...
Menor o risco.
Um Backlog Não Deve Crescer Para Sempre
Imagine um dataset.
Se ninguém fizer housekeeping...
Ele cresce.
Depois cresce.
Depois cresce.
Depois o volume explode.
Depois aparece:
SPACE ABEND
O backlog também.
Como Priorizar
Uma técnica simples.
Divida em quatro grupos.
Incêndio
Sistema parado.
Financeiro
Pode gerar prejuízo.
Cliente
Afeta usuários.
Melhoria
Pode esperar.
A maioria dos times mistura tudo.
Backlog e COBOL
Um programa COBOL raramente possui apenas uma alteração.
Quando você abre um fonte...
Encontra:
Alteração 2003
Alteração 2006
Alteração 2009
Alteração 2014
Alteração 2018
Alteração 2021
Alteração 2025
Cada comentário representa um backlog encerrado.
O código conta a história da empresa.
O Backlog Bom
Possui:
✔ descrição
✔ prioridade
✔ responsável
✔ impacto
✔ dependência
✔ prazo
✔ critério de aceite
✔ documentação
O Backlog Ruim
Descrição:
"Ajustar."
Boa sorte.
A Grande Diferença Entre Backlog e Dívida Técnica
Muita gente mistura.
Mas são conceitos completamente diferentes.
Backlog
É trabalho conhecido.
Sabemos que precisa ser feito.
Está registrado.
Está visível.
Pode ser priorizado.
Dívida Técnica
É trabalho escondido.
Você decidiu fazer algo mais rápido.
Agora pagará juros.
Imagine um empréstimo.
Você compra uma casa.
Ainda deve dinheiro.
A casa existe.
Mas existe dívida.
No software é igual.
Exemplo.
Você precisava entregar uma alteração.
O correto seria:
modularizar
criar testes
atualizar documentação
Mas o prazo era curto.
Você fez um IF gigantesco.
Funcionou.
Pronto.
Nasceu uma dívida técnica.
Backlog Pode Não Ser Dívida
Exemplo.
Nova funcionalidade PIX.
Ela nunca existiu.
Está no backlog.
Não existe dívida.
É apenas trabalho futuro.
Dívida Técnica Pode Não Estar no Backlog
Muito comum.
Todo mundo sabe que existe.
Ninguém registra.
Ninguém fala.
Até o dia em que explode.
Como Identificar Dívida Técnica
Pergunte:
"Se eu tivesse mais tempo...
faria diferente?"
Se a resposta for SIM...
Existe dívida técnica.
Os Juros da Dívida Técnica
Assim como um banco cobra juros...
O software também.
Cada alteração demora mais.
Cada teste demora mais.
Cada deploy gera medo.
Cada manutenção aumenta.
Dívida Técnica no Mainframe
Exemplos.
Programa COBOL com:
12000 linhas.
Sem PERFORM.
GO TO para todos os lados.
COPYBOOK repetido.
Campos duplicados.
Comentários de 1998.
Variáveis mortas.
Parágrafos nunca chamados.
SQL repetido.
MOVE desnecessário.
PERFORM THROUGH gigantesco.
Tudo isso gera dívida.
Como Corrigir
Nunca tente pagar toda a dívida de uma vez.
Faça igual um financiamento.
Pague parcelas.
Sempre que alterar um programa:
melhore um pouco.
Renomeie variáveis.
Remova código morto.
Atualize comentários.
Crie testes.
Melhore SQL.
Refatore pequenos blocos.
A Regra do Escoteiro
Robert C. Martin criou uma regra famosa.
Deixe o código melhor do que encontrou.
No Mainframe ela é perfeita.
Backlog Funcional
Pedido do negócio.
Backlog Técnico
Pedido da TI.
Backlog Arquitetural
Mudanças estruturais.
Exemplos.
Migrar VSAM.
Migrar CICS.
Atualizar COBOL.
Atualizar compilador.
Migrar DB2.
Atualizar RACF.
O Backlog Nunca Acaba
Isso assusta iniciantes.
Mas é normal.
Software vivo nunca termina.
Ele evolui.
Curiosidade Mainframe nº 1
Nos anos 70 ninguém dizia "Backlog".
Chamavam de:
Pending Requests
Programming Queue
Change Queue
Maintenance Queue
A palavra backlog ficou popular muito depois com métodos ágeis.
Curiosidade nº 2
Em muitos bancos brasileiros ainda existem planilhas Excel paralelas ao Jira.
Sim.
O backlog oficial nem sempre é o verdadeiro.
Curiosidade nº 3
Algumas empresas possuem backlog maior que o código.
Há milhares de demandas abertas.
Mas apenas algumas centenas realmente serão desenvolvidas.
Curiosidade nº 4
O maior inimigo do backlog não é a falta de programadores.
É a falta de decisão.
Curiosidade nº 5
Muitos ABENDs históricos aconteceram porque uma melhoria pequena ficou anos esquecida.
Quando finalmente foi feita...
Ninguém mais entendia o motivo original.
Easter Egg IBM Z
Você já percebeu?
O JES2 organiza trabalhos.
O MQ organiza mensagens.
O CICS organiza transações.
O DB2 organiza dados.
O RACF organiza permissões.
O backlog organiza pessoas.
No fundo...
Todo o ecossistema IBM Z é baseado em gerenciamento de filas.
Easter Egg COBOL
O comando:
NEXT SENTENCE
parece simples.
Mas ele simboliza exatamente muitos backlogs.
Você pula para frente sem realmente resolver o problema.
Funciona.
Até deixar de funcionar.
Easter Egg DB2
Um índice mal planejado gera consultas lentas.
Um backlog mal priorizado gera equipes lentas.
Os dois possuem exatamente o mesmo problema:
falta de organização.
Easter Egg CICS
Em CICS existe o conceito de resposta rápida.
O usuário não pode esperar.
No backlog também.
Quanto mais tempo uma tarefa fica parada...
Maior a chance de perder contexto.
Easter Egg JCL
Imagine um JOB.
STEP010
STEP020
STEP030
STEP040
Existe ordem.
Existe dependência.
Existe fluxo.
Um backlog deveria funcionar exatamente assim.
Easter Egg VSAM
Um KSDS desorganizado sofre mais splits.
Uma equipe desorganizada sofre mais interrupções.
Easter Egg RACF
No RACF, tudo segue o princípio do menor privilégio.
No backlog, vale um princípio parecido:
o menor item possível.
Histórias pequenas fluem melhor do que demandas gigantescas.
O Conselho Final para Todo Padawan COBOL
Quando você entrar em um projeto Mainframe, não olhe apenas para o código-fonte. Observe a saúde do backlog. Um programa de 30 anos pode ser surpreendentemente fácil de manter se houver um backlog bem organizado, prioridades claras e comunicação constante entre negócio e tecnologia. Por outro lado, um sistema moderno pode se tornar um pesadelo quando acumula tarefas mal descritas, prioridades conflitantes e dívida técnica ignorada.
Aprenda a fazer perguntas antes de programar. Entenda a regra de negócio antes de abrir o editor COBOL. Documente suas descobertas, refine as histórias, questione requisitos ambíguos e aproveite cada manutenção para deixar o código um pouco melhor do que estava. Essa disciplina, repetida diariamente, transforma um Padawan em um verdadeiro Mestre Mainframe.
No universo IBM Z, backlog é o mapa da jornada, enquanto a dívida técnica é o peso que você carrega na mochila. O mapa pode crescer à medida que novos caminhos surgem, mas o peso só aumenta quando atalhos mal planejados são tomados. Os melhores profissionais aprendem a equilibrar os dois: mantêm um backlog claro, vivo e priorizado, enquanto pagam pequenas parcelas da dívida técnica a cada entrega.
No fim das contas, a maior lição é simples: software não é apenas código; é uma fila contínua de decisões. Assim como o JES2 coordena jobs, o CICS gerencia transações e o DB2 organiza dados, um bom desenvolvedor organiza seu trabalho, seu conhecimento e sua evolução. É essa capacidade de transformar caos em ordem que diferencia um programador que apenas entrega tarefas de um engenheiro que constrói sistemas capazes de sobreviver por décadas — exatamente como os grandes ambientes IBM Z que continuam sustentando bancos, seguradoras, governos e empresas em todo o mundo.
Sem comentários:
Enviar um comentário