Bellacosa Mainframe e o planning em agile

☕ Um Café no Bellacosa Mainframe

Micky Rosa Entra na Sala de Planning — O Dia em que o Time COBOL Descobriu que Estimar Não É Apostar no Prazo

Ou: por que uma carta “8” não significa oito horas, como uma alteração de três linhas pode esconder um S0C7 internacional e por que o verdadeiro blefe da TI é prometer data antes de entender o programa

Há dois tipos de reuniões que fazem um programador COBOL iniciante olhar para a tela verde e pensar: “eu devia ter aberto uma padaria”.

A primeira é a reunião em que alguém diz:

“É só acrescentar um campo.”

A segunda é a reunião em que alguém responde:

“Quanto tempo leva?”

As duas frases podem parecer inocentes. As duas podem também acordar um monstro adormecido entre uma copybook de 1998, uma tabela Db2 com quarenta colunas, um job noturno que ninguém documentou e um arquivo enviado a uma empresa parceira que só descobre a mudança quando o lote volta com RC=12.

É aqui que entra Agile Estimation: estimativa ágil. Não como ritual para encher um mural de post-its ou como uma competição de quem escolhe o número mais baixo. Estimativa é uma ferramenta para tornar o trabalho visível antes de ele virar incidente.

E, para conduzir esta mesa, chamamos Micky Rosa, o professor de pôquer de Quebrando a Banca.

Micky não entra no CPD usando gravata de gerente e apresentando um cronograma colorido de PowerPoint. Ele olha para o backlog, vê uma história escrita como “adequar sistema à nova regra”, pede um café, olha para o time e pergunta:

“Vocês estão lendo as cartas ou só torcendo para que a próxima seja boa?”

No Agile, estimar é ler as cartas que já estão sobre a mesa: tamanho, incerteza, dependências, risco técnico, conhecimento do time e valor de negócio. Não é prever o futuro com precisão de vidente. É diminuir a chance de entrar em produção sem saber onde fica a saída de emergência.

Prólogo — “Só uma pequena alteração”, disse alguém que nunca abriu uma copybook

Imagine a solicitação:

“Incluir o campo PERCENTUAL-DESCONTO no cadastro de clientes.”

Para uma pessoa que está começando em COBOL, parece uma mudança modesta:

01  WS-PERCENTUAL-DESCONTO      PIC 9(3)V99.

Pronto. Uma linha nova. Talvez duas, se houver edição. Cinco minutos, certo?

Micky Rosa baixa as cartas. O analista experiente abre o ISPF. A história começa a revelar suas cartas escondidas.

O campo precisa:

aparecer na tela CICS;
receber validação;
ser gravado na tabela Db2;
entrar no SELECT, no INSERT e no UPDATE;
talvez exigir alteração de DCLGEN;
aparecer em relatórios;
ser enviado para um arquivo de integração;
ser lido pelo batch noturno;
afetar cálculo de faturamento;
ser registrado para auditoria;
passar por teste integrado;
ser promovido por uma cadeia de homologação;
ter plano de retorno caso a mudança cause erro.

Aquela “linha nova” deixou de ser uma linha. Ela agora é uma alteração transversal.

No universo mainframe, o programa COBOL raramente vive sozinho. Ele mora num condomínio antigo, muito eficiente, com regras, vizinhos e portaria.

Usuário
  ↓
Tela CICS
  ↓
Programa COBOL
  ↓
Copybook / validações
  ↓
Db2 ou VSAM
  ↓
JCL batch / arquivos / MQ / sistemas parceiros
  ↓
Auditoria, operação e reconciliação

A estimativa boa não pergunta apenas “quanto código será escrito?”. Ela pergunta:

“Quais sistemas, regras, dados, pessoas e riscos acordam quando mexemos nesta parte?”

1. Estimativa não é prazo, não é promessa e não é produtividade individual

Essa é a primeira regra que Micky escreveria na parede da sala de planning.

Uma estimativa é uma avaliação de tamanho ou esforço provável. Um prazo é uma data no calendário. Um compromisso é uma decisão explícita de entrega. Produtividade é outra conversa ainda.

Misturar tudo cria a clássica tragédia corporativa:

o time dá uma estimativa;
alguém transforma a estimativa em data;
alguém transforma a data em promessa;
alguém transforma a promessa em cobrança;
o time aprende a inflar números para sobreviver;
a empresa conclui que “Agile não funciona”.

Não foi o Agile que falhou. Foi o uso da estimativa como arma contratual.

Pontos não são horas

Muitas equipes usam Story Points, pontos de história. Eles representam tamanho relativo, não tempo exato.

Se uma pequena correção conhecida vale 1 ponto e uma mudança com impacto em COBOL, Db2 e batch parece cinco vezes mais complexa, ela pode receber 5 pontos.

Isso não significa:

5 pontos = 5 horas

Nem:

8 pontos = 8 dias

Pontos são como fichas de pôquer: seu valor é compreendido pela mesa, não por quem chega de fora querendo converter tudo para reais.

Uma equipe pode concluir, após algumas sprints, que normalmente entrega cerca de 20 a 25 pontos por sprint. Isso é sua velocidade histórica. Ajuda a fazer previsões coletivas.

Mas cuidado: velocidade não é placar individual.

Comparar desenvolvedores por pontos é como avaliar um cirurgião pela quantidade de pontos que ele deu no paciente. A métrica pode até crescer; o resultado que importa pode piorar muito.

2. O que o time realmente estima?

Uma boa estimativa mistura pelo menos quatro cartas.

Esforço

Quanto trabalho será necessário: análise, código, testes, documentação, implementação, acompanhamento.

Complexidade

Quantas partes interagem? Há regras de cálculo? Há várias tabelas? Existem caminhos alternativos? O fluxo CICS chama outros módulos?

Risco

O que pode falhar? Há mudança em tabela crítica? Existe janela batch apertada? A alteração afeta folha, crédito, PIX, cobrança ou relatório regulatório?

Incerteza

O que ainda não sabemos? Há documentação? O dono de negócio confirmou a regra? O fornecedor respondeu? Alguém sabe quem consome aquele arquivo?

Uma história com pouco código pode ser grande porque tem alto risco ou alta incerteza. É por isso que a estimativa feita apenas olhando o número de linhas COBOL costuma ser uma armadilha.

Um MOVE pode ser simples. Um MOVE dentro de um programa que alimenta liquidação financeira às 2h da manhã talvez seja um convite para conhecer a equipe de operação antes do café.

3. Antes de estimar: refinamento, o detector de blefe

Em Quebrando a Banca, ninguém deveria entrar numa mesa sem observar o jogo. Em Agile, ninguém deveria estimar uma história que ainda é uma névoa poética.

Veja este item:

“Modernizar o sistema de cadastro.”

Isso não é uma história pronta. É uma declaração de intenções, talvez um pedido de socorro, talvez o começo de uma tese de doutorado.

Compare com:

“Como analista de atendimento, quero visualizar o percentual de desconto aprovado no cadastro CICS para conferir a regra aplicada antes de confirmar a operação.”

Agora já existe usuário, necessidade e contexto. Ainda faltam detalhes, mas existe algo conversável.

Antes da estimativa, faça perguntas simples e devastadoras.

Qual problema de negócio será resolvido?
Quem usa a função?
Qual é o critério de aceite?
Onde o dado nasce?
Onde ele é validado?
Onde ele é persistido?
Que programas o leem?
Há impacto em Db2, VSAM, CICS, IMS, MQ ou arquivos?
Há batch noturno?
Existe integração externa?
Quem testa?
Como a alteração será desfeita se algo der errado?
Há requisito de auditoria, segurança ou LGPD?
Qual é a dependência mais perigosa?

Se ninguém sabe responder, não chute um número. Crie uma spike.

Spike: a investigação com crachá e prazo

Uma spike é uma tarefa curta de descoberta. Ela não entrega a funcionalidade final; ela reduz incerteza.

Exemplo:

“Em até dois dias, mapear programas COBOL, tabelas Db2, layouts de arquivo e jobs afetados pelo novo percentual de desconto.”

No fim da spike, a equipe deve produzir algo útil:

lista de componentes impactados;
riscos encontrados;
opções técnicas;
protótipo;
decisão de arquitetura;
nova história mais clara e estimável.

A spike é o momento em que o time deixa de perguntar “quanto custa?” e passa a perguntar “o que estamos comprando?”.

4. As oito técnicas de estimativa — e o que elas fazem de verdade

A imagem original apresenta oito técnicas úteis. Algumas são excelentes para estimar; outras funcionam melhor para organizar ou priorizar. A diferença importa.

Vamos percorrê-las como se Micky Rosa estivesse ensinando uma equipe COBOL a perceber que não existe “uma técnica mágica”, apenas ferramentas adequadas para cada mesa.

4.1 Affinity Mapping — agrupar antes de numerar

No Affinity Mapping, o time coloca várias histórias lado a lado e agrupa itens que parecem ter tamanho parecido.

Você pode começar com colunas como:

Muito pequeno | Pequeno | Médio | Grande | Muito grande | Incerto

Depois, caso necessário, converte para Story Points:

1 | 2 | 3 | 5 | 8 | 13

Imagine estas solicitações:

corrigir texto de mensagem CICS;
ajustar máscara de data;
incluir validação de CPF;
acrescentar campo em tabela Db2;
criar novo extrato batch;
alterar cálculo de juros e reprocessar histórico.

Mesmo antes de discutir números, o grupo enxerga que as duas primeiras são pequenas, a alteração Db2 é média ou grande, e o reprocessamento histórico pode ser uma criatura de 13 pontos ou maior.

Quando usar

Use Affinity Mapping quando houver muitas histórias e pouco tempo. É excelente para organizar backlog antes de um planejamento de release.

Cuidado mainframe

Não agrupe apenas pelo “tipo de tecnologia”. Duas histórias que mexem em Db2 podem ter tamanhos totalmente diferentes:

adicionar um índice pode ser previsível;
mudar uma chave de negócio pode afetar integridade, performance, batch, replicação e reconciliação.

O nome da tecnologia não informa o risco sozinho.

4.2 Big, Small, Unclear — a triagem que salva a sprint

Esta técnica é quase um raio-X do backlog. Em vez de fingir precisão, o time separa itens em três grupos:

Big: grande demais, provavelmente precisa ser quebrado;
Small: entendido e manejável;
Unclear: ainda não sabemos o suficiente.

É simples e poderoso porque normaliza uma frase que deveria ser mais comum em TI:

“Ainda não sabemos.”

Isso não é incompetência. É honestidade operacional.

Exemplo:

Solicitação	Classificação	Por quê?
Corrigir título de tela CICS	Small	Escopo local e claro
Implantar nova tabela de tarifas	Big	Regras, dados, telas, batch e integração
Adequar à norma regulatória	Unclear	Norma, escopo e impactos precisam ser entendidos

O erro mais comum é tratar “Unclear” como “8 pontos”. Não. “Unclear” pode virar 2, 13 ou uma iniciativa inteira. Primeiro investigue.

4.3 Ordering Protocol — colocando as cartas em ordem

No Ordering Protocol, o grupo ordena itens do menor para o maior. Não começa discutindo se algo é 3 ou 5. Começa perguntando:

“Esta história é maior ou menor que aquela?”

A equipe move os cartões até formar uma sequência coerente.

Exemplo:

Ajustar texto
↓
Validar data
↓
Incluir campo em tela e COBOL
↓
Alterar tabela Db2 e batch
↓
Reprocessar histórico financeiro

Por que funciona?

Porque seres humanos costumam comparar melhor do que medir em absoluto. É mais fácil dizer que um cachorro é maior que um gato do que definir precisamente seu “índice universal de cachorridade”.

No desenvolvimento, comparar reduz discussões artificiais. Se todos concordam que uma história é maior que outra, a escala final fica mais natural.

Dica Bellacosa

Mantenha algumas histórias de referência, conhecidas e já entregues:

“Alteração simples em CICS” = 2 pontos;
“Novo campo Db2 com batch” = 5 pontos;
“Nova regra financeira com integração” = 8 pontos.

Elas funcionam como marcos de quilometragem para a equipe.

4.4 Bucket System — o facilitador organiza, o time decide

O Bucket System acelera a estimativa de uma grande lista de itens. Colocam-se “baldes” de tamanho:

0 | 1 | 2 | 3 | 5 | 8 | 13 | 21 | ?

O facilitador organiza a dinâmica, mas não deveria sair distribuindo pontos sozinho como professor corrigindo prova. A equipe posiciona as histórias, depois revisa os casos controversos.

É ótimo para uma sessão de planejamento trimestral, quando há dezenas de demandas.

Regra de sobrevivência

Quando uma história cai em 21, XL ou “maior que isto”, ela está mandando um recado:

“Quebre-me antes que eu quebre a sprint.”

Uma história grande deve ser fatiada por valor e por fluxo de negócio, não simplesmente por camada técnica.

Ruim:

criar tabela;
criar programa;
criar tela.

Melhor:

permitir registrar desconto manual até determinado limite;
permitir consultar desconto aplicado;
gerar desconto aprovado no arquivo de faturamento.

O segundo corte produz partes testáveis e úteis. O primeiro cria uma sequência técnica que só entrega valor no final.

4.5 Planning Poker — a técnica em que a divergência é ouro

Planning Poker é o clássico. Cada pessoa escolhe sua carta em silêncio, todos revelam ao mesmo tempo e as diferenças são discutidas.

Uma escala comum é Fibonacci:

0, 1, 2, 3, 5, 8, 13, 21, ?

Por que Fibonacci? Porque a incerteza cresce junto com o tamanho. A diferença entre 1 e 2 é pequena; entre 13 e 14 quase ninguém conseguiria justificar com seriedade.

Imagine a história:

“Adicionar desconto especial ao cadastro e usar o valor no faturamento.”

O desenvolvedor A escolhe 3. O desenvolvedor B escolhe 13.

Antes de escolher “8, para fazer média”, Micky Rosa interrompe:

“Por que 3? Por que 13?”

Talvez o A tenha pensado apenas na tela e no programa online. B talvez saiba que o faturamento é batch, que existe reprocessamento, que o arquivo vai para uma parceira externa e que a alteração exige homologação regulatória.

A divergência revelou conhecimento que não estava no ticket.

Essa é a verdadeira função do Planning Poker: transformar conhecimento individual em consciência coletiva.

Como conduzir bem

Leia a história e os critérios de aceite.
Tire dúvidas essenciais.
Cada pessoa escolhe uma carta sem mostrar.
Todos revelam ao mesmo tempo.
Quem escolheu o menor e o maior número explica o raciocínio.
Discuta impactos, riscos e suposições.
Vote novamente.
Registre decisões e pendências.

Não é necessário unanimidade religiosa. É necessário entendimento suficiente para trabalhar com responsabilidade.

4.6 Three-Point Estimation — otimismo, realidade e o fantasma do pior caso

A estimativa de três pontos é útil quando risco e prazo precisam ser discutidos de forma mais explícita.

Você calcula três cenários:

Otimista (O): tudo ocorre bem;
Mais provável (M): cenário normal;
Pessimista (P): problemas realistas acontecem.

Uma fórmula PERT bastante usada é:

E = \frac{O + 4M + P}{6}

Exemplo: descobrir impacto de uma mudança em arquivo bancário.

O = 2 dias, se houver documentação e nenhum consumidor oculto;
M = 5 dias, se for necessário validar programas e testes;
P = 12 dias, se houver fornecedor, layout antigo e reconciliação histórica.

E = \frac{2 + 4(5) + 12}{6} = \frac{34}{6} \approx 5{,}7

A conclusão não é “prometa 5,7 dias”. A conclusão é:

“A previsão central é próxima de seis dias, mas existe risco considerável. Precisamos tratar as causas que levam ao cenário de doze.”

Talvez a ação correta seja envolver o fornecedor cedo, recuperar layout oficial do arquivo ou fazer uma spike.

Curiosidade

A técnica vem de ideias usadas em PERT, método criado para lidar com projetos complexos e incertos. Ela continua relevante porque reconhece algo que alguns cronogramas tentam esconder: o futuro não vem em linha reta.

4.7 Dot Voting — escolha o que vem antes, não o que “dá mais trabalho”

Dot Voting é uma ótima técnica, mas é frequentemente colocada no lugar errado.

Ela é mais útil para priorização do que para estimativa.

Cada pessoa recebe, por exemplo, três pontos adesivos e vota nas iniciativas que acredita terem maior valor, urgência ou redução de risco.

Você pode perguntar:

qual item reduz maior risco operacional?
qual atende obrigação legal?
qual elimina maior volume de trabalho manual?
qual beneficia mais usuários?
qual precisa ser descoberto primeiro?

Considere este backlog:

Item	Valor	Esforço
Corrigir falha RACF	Alto	Médio
Modernizar cores de tela	Baixo	Pequeno
Adequar obrigação legal	Muito alto	Grande
Automatizar conciliação manual	Alto	Médio

Os votos ajudam a escolher o que vem primeiro. A estimativa ajuda a entender quanto custa. As duas coisas não são iguais.

O item mais urgente pode ser o maior. O item mais fácil pode ter valor mínimo. Confundir prioridade com tamanho é como escolher uma rota de avião apenas pela distância, ignorando tempestade, combustível e aeroporto de destino.

4.8 T-shirt Sizing — o roadmap de camiseta

T-shirt Sizing usa tamanhos:

XS | S | M | L | XL

É uma maneira rápida de discutir tamanho em níveis altos, antes de existir detalhe suficiente para Planning Poker.

Tamanho	Interpretação prática
XS	mudança local, muito conhecida
S	alteração pequena e previsível
M	vários pontos de impacto, caminho claro
L	regra complexa ou integração relevante
XL	grande demais; dividir ou investigar

É especialmente bom em conversas de roadmap com negócio e gestão. Ninguém precisa fingir que já sabe o número de horas de uma iniciativa que será feita daqui a seis meses.

Micky Rosa diria:

“Você não precisa saber a carta exata antes de ela ser virada. Mas precisa saber se está apostando uma ficha ou a mesa inteira.”

5. Como estimar uma história COBOL: passo a passo

Vamos usar uma história completa:

“Como analista de crédito, quero aplicar percentual de desconto autorizado ao cálculo da parcela, para que clientes elegíveis recebam a condição comercial aprovada.”

Passo 1 — Entenda o fluxo de negócio

Antes de abrir o código, descubra:

quem autoriza o desconto;
qual limite é permitido;
o desconto vale para todas as parcelas?
existe validade?
há necessidade de trilha de auditoria?
é permitido alterar desconto depois de faturado?

Passo 2 — Mapeie os componentes técnicos

Procure:

programa COBOL online;
BMS map e tela CICS;
copybooks;
tabelas Db2;
SQL embutido;
DCLGEN;
jobs JCL;
arquivos de interface;
programas batch;
relatórios;
rotinas de auditoria;
testes existentes.

A ferramenta pode mudar — ISPF, IDz, VS Code com extensões, busca em repositório —, mas a pergunta é a mesma: “onde esse dado vive e para onde ele viaja?”

Passo 3 — Liste riscos e dependências

Por exemplo:

alteração de tabela exige DBA;
mudança no arquivo exige acordo com parceiro;
o batch tem janela curta;
não existe ambiente de teste representativo;
o cálculo é usado por vários produtos;
há massa histórica que precisa ser preservada.

Passo 4 — Quebre a história, se necessário

Talvez ela seja grande demais. Você pode separar:

cadastrar e consultar o desconto;
validar limites e registrar auditoria;
usar desconto em novo faturamento;
avaliar necessidade de reprocessamento histórico.

Não esconda o reprocessamento dentro da história principal como se fosse uma nota de rodapé. Reprocessamento financeiro é quase sempre uma carta que merece ser vista.

Passo 5 — Escolha a técnica

poucas histórias importantes: Planning Poker;
muitas histórias parecidas: Affinity Mapping ou Buckets;
muita incerteza: Spike e Three-Point Estimation;
roadmap inicial: T-shirt Sizing.

Passo 6 — Registre suposições

Uma estimativa sem suposição documentada vira discussão de memória seletiva depois.

Exemplo:

Estimativa de 8 pontos, assumindo que não haverá alteração retroativa de parcelas já faturadas e que o layout externo não muda.

Se a regra mudar, a estimativa muda. Não é “o time errou”. O escopo foi alterado.

6. Os erros que fazem a estimativa virar cassino sem Micky Rosa

Estimar sem critério de aceite

“Criar relatório” pode significar qualquer coisa entre um DISPLAY em batch e um documento regulatório com reconciliação, assinatura, distribuição e retenção.

Usar estimativa para pressionar pessoas

Quando a estimativa vira cobrança individual, todos aprendem a se defender, não a colaborar.

Transformar pontos em horas

Pontos são comparativos. Horas são calendário e disponibilidade. Ambas podem coexistir, mas não são sinônimos.

Esquecer trabalho invisível

Análise, testes, revisão, documentação, deploy, acompanhamento pós-produção e correção de falhas fazem parte da entrega.

Se um time estima apenas “tempo de codar”, está tratando o desenvolvimento como se COBOL compilasse, sorrisse e se promovesse sozinho.

Aceitar histórias XL dentro da sprint

Uma história gigante diminui previsibilidade, dificulta teste e costuma terminar com a frase “está 90% pronto” durante três semanas.

Em sistemas críticos, 90% pronto pode significar 0% entregável.

Confundir estimativa com adivinhação

Uma estimativa muda quando aparece informação nova. Isso é esperado.

O erro não é atualizar a previsão; erro é fingir que a informação nova não existe para proteger uma data antiga.

7. O verdadeiro poder escondido da estimativa Agile

A maior entrega de uma boa sessão de estimativa não é o número 5, 8 ou 13.

É o time descobrir, antes da produção:

que há uma copybook compartilhada;
que o campo também precisa existir no arquivo;
que a tabela Db2 possui dependências;
que existe uma regra de auditoria;
que o batch usa uma lógica diferente da tela;
que outro sistema consome o dado;
que a regra de negócio ainda não foi decidida.

A estimativa cria conversa técnica. A conversa técnica cria entendimento. O entendimento diminui retrabalho, incidentes e aquela famosa reunião de crise em que todos dizem “ninguém avisou”.

No mundo COBOL, em que décadas de regra de negócio podem estar preservadas dentro de programas, JCL, CICS e Db2, isso vale ouro.

Epílogo — a lição de Micky Rosa para o programador iniciante

O programador iniciante muitas vezes acha que estimar é uma tarefa de gerente, Scrum Master ou analista. Não é. Sua visão técnica é parte essencial do processo.

Quando você pergunta:

“Esse campo também entra no arquivo de fechamento?”

ou:

“Há programas batch que leem esta tabela?”

ou ainda:

“Como vamos testar o retorno se a atualização Db2 falhar no meio?”

você não está “complicando”. Está evitando que a mesa inteira aposte sem ver as cartas.

Agile não pede que você prometa o impossível com um sorriso e um post-it. Ele pede que o time enxergue o trabalho com clareza suficiente para tomar decisões melhores.

Então, na próxima vez que alguém disser “é só uma alteração pequena”, faça como Micky Rosa: observe a mesa, confira o histórico, pergunte o que está escondido e só então coloque sua ficha.

Porque, no mainframe, a alteração pequena quase sempre começa pequena.

O restante da história costuma estar escondido em alguma copybook.

Translate

domingo, 7 de maio de 2023