Translate

Mostrar mensagens com a etiqueta qualidade de software. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta qualidade de software. Mostrar todas as mensagens

quarta-feira, 15 de janeiro de 2025

☕📋💣 BACKLOG: O ARQUIVO SECRETO QUE SEPARA UM PROGRAMADOR COBOL COMUM DE UM VERDADEIRO ARQUITETO DE SISTEMAS

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:

ProgramaProblema
COBCLI01Sem documentação
COBPAG0215.000 linhas
COBFAT03Sem 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.