| Bellacosa Mainframe e o backlog mainframe |
☕📋💣 BACKLOG: O ARQUIVO SECRETO QUE SEPARA UM PROGRAMADOR COBOL COMUM DE UM VERDADEIRO ARQUITETO DE SISTEMAS
"O sistema não está parado. Ele apenas está esperando na fila."
Existe uma cena que se repete diariamente em praticamente todas as empresas que possuem Mainframe.
O telefone toca.
Um gerente aparece.
Um usuário reclama.
Um diretor pede urgência.
Uma área regulatória exige mudanças.
O banco central publica uma nova norma.
O auditor encontra uma inconsistência.
O operador identifica um erro.
E de repente surgem vinte novas tarefas.
A pergunta é:
quem decide o que será feito primeiro?
É exatamente nesse momento que nasce um dos conceitos mais importantes da engenharia de software moderna:
o Backlog.
Se você é um programador COBOL Mainframe iniciante, entender backlog pode acelerar sua carreira mais do que aprender cinquenta comandos novos de JCL.
Porque programar é importante.
Mas entender como o trabalho é organizado é o que diferencia um executor de um profissional estratégico.
Pegue seu café.
Vamos abrir esse dataset.
O QUE É BACKLOG?
A definição mais simples possível:
Backlog é uma lista organizada de tudo aquilo que precisa ser feito.
Simples assim.
Pode conter:
novas funcionalidades;
correções de bugs;
melhorias;
ajustes regulatórios;
documentação;
refatoração;
automação;
modernização.
Tudo entra no backlog.
Pense nele como uma fila de JOBs esperando para executar.
O BACKLOG EXPLICADO COMO UM JOB SCHEDULER
Imagine um ambiente de produção.
Você possui:
JOB001 - Fechamento diário
JOB002 - Atualização de clientes
JOB003 - Relatório gerencial
JOB004 - Backup
JOB005 - Auditoria
Todos precisam executar.
Mas existe uma ordem.
Backlog é exatamente isso.
Uma fila organizada de atividades aguardando execução.
A diferença é que em vez de JOBs estamos falando de trabalho humano.
O MAIOR MITO SOBRE BACKLOG
Muitos iniciantes acreditam:
"Backlog é uma lista de novas funcionalidades."
Errado.
Backlog é muito maior que isso.
Um backlog saudável contém:
inovação;
manutenção;
correções;
melhorias;
dívida técnica.
Quando só existem novas funcionalidades no backlog, algo está errado.
Muito errado.
UM EXEMPLO REAL DE MAINFRAME
Imagine um sistema bancário.
O backlog pode conter:
Criar PIX Internacional
Corrigir cálculo de juros
Atualizar layout FEBRABAN
Refatorar COBCLI01
Documentar JOB FAT0001
Criar testes para módulo de cobrança
Observe.
Nem tudo é desenvolvimento novo.
Parte do trabalho é manutenção.
Parte é prevenção.
Parte é sobrevivência.
ONDE ENTRA A DÍVIDA TÉCNICA?
Agora chegamos ao ponto interessante.
A dívida técnica normalmente vive dentro do backlog.
Por exemplo:
BACKLOG
Criar API de consulta
Novo relatório fiscal
Refatorar COBPAG01
Eliminar COPYBOOK duplicado
Automatizar testes
Os três últimos itens são pagamentos de dívida técnica.
Ou seja:
Todo pagamento de dívida técnica vira backlog.
Mas nem todo backlog é dívida técnica.
COMO A DÍVIDA TÉCNICA APARECE
Imagine que você recebeu uma demanda urgente.
O gerente diz:
"Precisamos colocar isso em produção amanhã."
Você cria uma solução rápida.
Funciona.
Entrega realizada.
Todo mundo feliz.
Meses depois:
ninguém entende o código;
faltam comentários;
surgem bugs;
novas alterações ficam lentas.
Pronto.
A dívida nasceu.
O EFEITO BOLA DE NEVE
O primeiro remendo parece inocente.
Depois vem outro.
E mais outro.
Então surge um IF dentro de outro IF.
Depois outro.
Quando você percebe:
IF A
IF B
IF C
IF D
IF E
O programa ainda funciona.
Mas ninguém mais entende.
Isso é o juros da dívida técnica.
O DIA EM QUE O BACKLOG VIROU UM CEMITÉRIO
Existe uma curiosidade interessante.
Algumas empresas possuem backlog com milhares de itens.
Mas ninguém sabe:
quem criou;
por que criou;
se ainda faz sentido.
Isso não é backlog.
É arqueologia corporativa.
COMO UM JÚNIOR DEVE ENXERGAR O BACKLOG
Não veja o backlog como uma lista de tarefas.
Veja como um mapa.
Ele mostra:
para onde o sistema está indo;
quais problemas existem;
quais riscos precisam ser tratados.
Os melhores analistas costumam estudar o backlog inteiro.
Não apenas sua tarefa.
COMO IDENTIFICAR DÍVIDA TÉCNICA
Existem sinais clássicos.
Programas gigantes
Mais de 10.000 linhas.
COPYBOOKs duplicados
Mesma estrutura espalhada.
JCLs clonados
Copiar e colar virou arquitetura.
Falta de documentação
Conhecimento armazenado apenas na cabeça de alguém.
Dependência de especialistas
Quando você ouve:
"Somente o Carlos entende isso."
A dívida já existe.
COMO MAPEAR DÍVIDA TÉCNICA
Crie uma planilha simples.
Campos:
Sistema
Programa
Problema
Risco
Complexidade
Prioridade
Exemplo:
| Programa | Problema |
|---|---|
| COBCLI01 | Sem documentação |
| COBPAG02 | 15.000 linhas |
| COBFAT03 | Sem testes |
Agora a dívida ficou visível.
E aquilo que é visível pode ser gerenciado.
MÉTRICAS IMPORTANTES
Os melhores profissionais medem.
Sempre.
Algumas métricas úteis:
Número de ABENDs
Quanto mais ABENDs.
Maior a chance de problemas estruturais.
Tempo médio de correção
Quanto demora para corrigir um incidente?
Quantidade de bugs
Excelente indicador.
Número de programas sem documentação
Métrica simples.
Mas extremamente poderosa.
FERRAMENTAS QUE AJUDAM
Muitos acreditam que Mainframe não possui ferramentas modernas.
Grande erro.
IBM ADDI
Mapeia dependências.
Mostra relações entre:
COBOL;
JCL;
DB2;
CICS.
IBM Application Discovery
Excelente para sistemas legados.
IBM Fault Analyzer
Investiga ABENDs.
IBM Debug Tool
Ajuda a entender programas complexos.
SonarQube
Em ambientes integrados.
Ajuda na análise de qualidade.
Git
Sim.
Mainframe moderno usa Git.
E muito.
COMO CONTROLAR O BACKLOG
Regra simples.
Prioridade.
Nem tudo tem o mesmo peso.
Uma técnica muito usada:
Alta prioridade
Produção parada.
Média prioridade
Risco futuro.
Baixa prioridade
Melhorias desejáveis.
O SEGREDO DOS TIMES MADUROS
Times iniciantes fazem:
100% Funcionalidades
Times maduros fazem:
70% Funcionalidades
20% Correções
10% Dívida Técnica
Alguns chegam a reservar uma sprint inteira para limpeza.
E os resultados aparecem rapidamente.
EASTER EGG MAINFRAME
Se você encontrar comentários como:
* NÃO ALTERAR
* FUNCIONA DESDE 1998
Você encontrou um fóssil corporativo.
Parabéns.
Agora investigue antes de tocar.
Porque muitas vezes esse comentário está escondendo uma dívida técnica de milhões de dólares.
A REGRA DOS 15 MINUTOS
Uma dica que poucos ensinam.
Se você gastou mais de 15 minutos para entender um trecho de código:
documente.
Seu "eu do futuro" agradecerá.
COMO EVOLUIR MAIS RÁPIDO NA CARREIRA
O júnior normalmente aprende:
COBOL;
JCL;
DB2;
CICS.
Mas os profissionais mais valorizados aprendem também:
gestão de backlog;
análise de impacto;
controle de dívida técnica;
arquitetura;
observabilidade.
É isso que os transforma em analistas seniores.
O QUE NINGUÉM CONTA SOBRE BACKLOG
O backlog é uma fotografia do estado de saúde do sistema.
Se ele possui:
centenas de bugs;
dezenas de refatorações pendentes;
documentação atrasada;
o sistema está acumulando dívida.
O backlog está contando uma história.
Aprenda a lê-la.
CONCLUSÃO
Backlog não é apenas uma lista de tarefas.
É o painel de controle do futuro do sistema.
E a dívida técnica é uma das passageiras mais perigosas dessa viagem.
Um programador COBOL Mainframe que aprende a:
identificar problemas;
registrar atividades;
priorizar demandas;
controlar dívida técnica;
documentar descobertas;
deixa de ser apenas alguém que escreve código.
Passa a ser alguém capaz de manter sistemas vivos por décadas.
E no mundo Mainframe, onde muitos programas são mais antigos que seus desenvolvedores, essa habilidade vale ouro.
Porque no final das contas, o verdadeiro segredo não é escrever um programa novo.
É conseguir entender por que aquele programa de 1989 ainda está funcionando perfeitamente em produção.
E sobreviver ao chamado das 03:17 da manhã quando alguém decidir alterá-lo.