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.

 

📉 Por que o MS Project caiu em desuso nas equipes modernas?

Bellacosa Mainframe apresenta o fim do Ms Project

Ao estilo Bellacosa Mainframe — direto, pragmático e sem romantizar ferramenta legada:

---

📉 Por que o MS Project caiu em desuso nas equipes modernas?

O MS Project nasceu em um mundo onde planejar era mais importante do que aprender.
Projetos eram previsíveis, lineares e comandados por um Project Manager centralizador.
Esse mundo acabou.

Hoje, projetos mudam toda semana.
E o MS Project não lida bem com mudança constante.

---

⚙️ O que mudou no jogo

1️⃣ Do Plano Fixo para o Fluxo Contínuo

• MS Project → cronograma fechado, dependências rígidas

• Mundo atual → backlog vivo, prioridades dinâmicas

Atualizar um Gantt a cada mudança:

• consome tempo

• não gera valor

• cria falsa sensação de controle

---

2️⃣ Do Comando e Controle para Times Autônomos

• MS Project pressupõe:

  • um dono do plano

  • tarefas atribuídas de cima para baixo

• Agile / DevOps exigem:

  • auto-organização

  • visibilidade compartilhada

  • decisão no nível do time

O MS Project não conversa com times auto-geridos.

---

3️⃣ Planejamento por Datas vs Planejamento por Valor

• MS Project pergunta: “quando termina?”

• Agile pergunta: “qual valor entregamos agora?”

Hoje, valor entregue > cronograma perfeito.

---

🔁 Quem ocupou o lugar do MS Project?

O MS Project não teve um substituto direto.
Ele foi desmontado em partes.

🔹 Planejamento e Backlog

• Jira

• Azure DevOps

• Rally

👉 substituíram o planejamento detalhado por backlog priorizado

---

🔹 Fluxo de Trabalho

• Kanban Boards

• Trello

• Jira Boards

👉 substituíram o Gantt por fluxo visual em tempo real

---

🔹 Roadmap e Visão

• Product Roadmap

• Product Vision

• OKRs

👉 substituíram o cronograma mestre por direção estratégica flexível

---

🔹 Execução e Métricas

• Velocity

• Lead Time

• Cycle Time

• Burnup / Burndown

👉 substituíram o % completo do MS Project, que nunca refletiu a realidade

---

🧠 O verdadeiro motivo do desuso

O MS Project não é ruim.
Ele só resolve um problema que quase não existe mais.

Projetos previsíveis, estáveis, com escopo fechado.

Hoje temos:

• produto em evolução

• requisitos emergentes

• integração contínua

• entrega contínua

MS Project não acompanha ritmo de pipeline.

---

🧾 Onde o MS Project ainda sobrevive

Ele não morreu.
Virou ferramenta de exceção:

• Engenharia pesada

• Construção civil

• Infraestrutura tradicional

• Projetos regulatórios com escopo fechado

👉 Onde mudança é inimiga, não aliada.

---

🔚 Conclusão Bellacosa

MS Project planeja projetos.
Agile gerencia incerteza.

Quando a incerteza virou regra,
o MS Project virou peça de museu corporativo.

👉 Resumo para ir mais longe

Durante muitos anos, o Microsoft Project (MS Project) foi uma das principais ferramentas de gerenciamento de projetos do mercado. Seu foco em cronogramas detalhados, dependências complexas, diagramas de Gantt e planejamento de longo prazo refletia a realidade de projetos conduzidos por metodologias tradicionais, especialmente o modelo cascata (waterfall).

Com o crescimento das metodologias ágeis, muitas empresas passaram a enxergar limitações nesse modelo. Em ambientes onde requisitos mudam constantemente, criar planejamentos extremamente detalhados para meses ou anos à frente tornou-se cada vez mais difícil. O problema não era necessariamente a ferramenta, mas a mudança na forma como os projetos passaram a ser conduzidos.

Frameworks como Scrum, Kanban e práticas de Agile priorizam adaptação contínua, entregas frequentes e revisão constante das prioridades. Nesse contexto, ferramentas mais leves e colaborativas, como Jira, Trello, Azure DevOps e outras plataformas digitais, ganharam espaço por facilitarem o gerenciamento dinâmico de backlogs, sprints e fluxos de trabalho.

Mesmo assim, o MS Project não desapareceu. Ele continua sendo amplamente utilizado em áreas como engenharia, construção civil, infraestrutura, projetos governamentais e iniciativas que exigem forte controle de cronograma e recursos.

A grande transformação ocorreu na cultura de gestão. O foco deixou de ser apenas prever todo o futuro do projeto e passou a incluir adaptação rápida, colaboração entre equipes e resposta eficiente às mudanças constantes do mercado.

 

Bellacosa Mainframe agile kanbam estouro de prazo

🧠 Agile de Verdade: Por que Planejar Tudo no Início Falha (e o que Fazer em Vez Disso)

Por El Jefe — Estilo Bellacosa Mainframe

---

Introdução: o som dos prazos passando voando

Douglas Adams resumiu melhor do que qualquer framework:

“Eu amo prazos. Adoro o som que eles fazem quando passam voando. Whoosh!”

Se você trabalha com projetos — especialmente em TI, mainframe, DevOps ou software corporativo — já ouviu esse som.
Planejamos tudo no início, cravamos uma data… e erramos.

A pergunta não é se isso vai acontecer.
A pergunta é: por que insistimos em fazer isso?

---

O erro clássico: decidir tudo quando você sabe o mínimo

No início de um projeto, sabemos quase nada:

• Requisitos ainda são hipóteses

• Sistemas dependentes mudam

• Patches surgem

• Prioridades do negócio se ajustam

Mesmo assim, é exatamente nesse momento que:

• Criamos cronogramas longos

• Estimamos prazos fixos

• Prometemos entregas distantes

📌 Bellacosa rule #1

Não decida tudo no ponto em que você sabe menos sobre o problema.

---

A analogia dos pinguins (e por que ela funciona)

Imagine atravessar um campo cheio de pinguins em movimento.

• No início, você escolhe os primeiros passos

• No meio do caminho, o cenário já mudou

• Quanto mais avança, melhor é sua visão

Agora troque:

• Pinguins por dependências

• Campo por projeto

• Movimento por mudança constante

Isso é desenvolvimento de software.
Isso é modernização de sistemas.
Isso é Agile.

---

Planejamento iterativo: navegar, não adivinhar

Agile não elimina planejamento.
Ele elimina planejamento ilusório.

A ideia é simples:

• Planeje o que você conhece agora

• Avance um pouco

• Aprenda

• Ajuste

• Repita

🎯 Precisão real:

• Planejar 3 meses à frente → ~50% de acurácia

• Planejar 2 semanas → quase 100%

📌 Bellacosa rule #2

Agile não tenta ser onisciente. Agile aprende rápido.

---

O segundo grande erro: trocar cargos sem mudar mentalidade

Quando empresas “viram Agile”, algo perigoso costuma acontecer:

• Product Manager vira Product Owner

• Project Manager vira Scrum Master

• Time de desenvolvimento vira “Scrum Team”

Tudo isso sem treinamento.

Resultado? Fracasso previsível.

---

Product Manager ≠ Product Owner

• Product Manager

  • Cargo

  • Foco em orçamento e operação

• Product Owner

  • Papel do Scrum

  • Visionário

  • Conecta negócio e tecnologia

  • Define valor e experimentos

📌 Podem ser a mesma pessoa? Sim.
📌 Devem ser automaticamente? Não.

---

Project Manager ≠ Scrum Master

Aqui mora o choque cultural.

Project Manager

• Controla tarefas

• Cobra plano

• Documenta riscos

Scrum Master

• Atua como coach

• Remove impedimentos

• Protege o time

• Incentiva auto-organização

📌 Diferença brutal
O Project Manager pergunta:

“Como você vai se destravar?”

O Scrum Master diz:

“Deixa comigo. Vai produzir.”

---

Development Team ≠ Scrum Team

• Development Team: só desenvolvedores

• Scrum Team: time cross-functional

Inclui:

• Dev

• Teste

• Ops

• Segurança

• Negócio

📌 Agile sem time multidisciplinar é teatro corporativo.

---

Sem apoio da gestão, Agile não escala

Essa é a verdade que dói.

Gestão tradicional pergunta:

• “O que você entrega até o fim do ano?”

Gestão ágil pergunta:

• “O que você entrega nas próximas duas semanas?”

• “Qual valor chega ao cliente neste sprint?”

📌 Bellacosa rule #3

Agile só funciona quando a liderança muda as perguntas.

---

Ferramentas não tornam ninguém ágil

Kanban, Jira, ZenHub, GitHub…
Ferramentas não criam mindset.

Elas apenas:

• Dão visibilidade

• Sustentam o processo

• Reduzem ruído

Se o processo é Waterfall, o Kanban vira um Gantt disfarçado.

---

Kanban sem frescura: simples, visual e honesto

Kanban é só isso:

• O que preciso fazer

• O que estou fazendo

• O que já fiz

Trabalho flui da esquerda para a direita.
Sem mágica. Sem burocracia.

---

Pipelines: uma visão clara do fluxo

Um Kanban típico tem:

• New Issues – entrada

• Icebox – longo prazo

• Product Backlog – tudo que queremos

• Sprint Backlog – próximas duas semanas

• In Progress – trabalho ativo

• Review / QA – validação

• Done – concluído

📌 Uma única fonte da verdade.
📌 Atualizada automaticamente onde o dev já trabalha.

---

Conclusão: Agile não é moda, é sobrevivência

Agile não é sobre:

• Framework

• Cerimônia

• Ferramenta

Agile é sobre:

• Aprender rápido

• Planejar melhor

• Entregar valor continuamente

• Aceitar que o desconhecido faz parte do jogo

📌 Bellacosa final rule

Quem tenta controlar o futuro perde o presente.
Quem aprende continuamente constrói o futuro.

📌 Resumo para ir mais longe

 Um dos princípios mais importantes do movimento Agile é reconhecer uma realidade que muitos projetos tentam ignorar: é impossível planejar tudo com precisão absoluta. Mercados mudam, clientes alteram prioridades, tecnologias evoluem e novos desafios surgem constantemente. Por isso, metodologias ágeis não eliminam o planejamento; elas transformam o planejamento em um processo contínuo.

Durante décadas, muitas organizações acreditaram que documentos extensos e cronogramas detalhados seriam suficientes para prever todo o futuro de um projeto. Na prática, porém, quanto maior o prazo, maior a probabilidade de mudanças. O Agile surgiu justamente para lidar com essa incerteza de forma estruturada.

Em vez de definir todos os detalhes antecipadamente, equipes ágeis trabalham com objetivos claros e ciclos curtos de entrega. A cada sprint, novas informações são analisadas, permitindo ajustes rápidos e redução de riscos. O aprendizado contínuo passa a ser parte integrante do processo.

Outro conceito fundamental é o feedback constante. Clientes, usuários e equipes colaboram para identificar melhorias antes que pequenos problemas se transformem em grandes falhas. Essa abordagem aumenta a capacidade de adaptação e melhora a qualidade das entregas.

O verdadeiro Agile não promete prever o futuro. Ele oferece mecanismos para responder às mudanças de maneira eficiente, permitindo que pessoas, equipes e organizações evoluam continuamente em um ambiente cada vez mais dinâmico e imprevisível.

 

Bellacosa Mainframe apresenta Agile Kanban

🧭 Agile na Prática: Planejamento, Pessoas e Kanban

(Guia Navegável – Estilo Bellacosa Mainframe)

---

1️⃣ Por que o planejamento inicial leva à perda de prazos

“Não decida tudo quando você sabe o mínimo.”

Planejar tudo no início de um projeto quase sempre leva a prazos estourados porque:

• No começo do projeto, sabemos muito pouco

• Requisitos mudam

• Tecnologias são atualizadas

• Dependências externas se movem

📌 Analogia dos pinguins
Planejar um projeto é como atravessar um campo cheio de pinguins em movimento:

• No início, você enxerga pouco

• No meio, sua visão muda

• Conforme avança, você aprende e ajusta o caminho

👉 Moral da história:
Planejar tudo no começo é decidir no pior momento possível.

---

2️⃣ Planejamento iterativo: navegar pelo desconhecido

O Agile propõe planejar conforme o conhecimento aumenta.

• Planeje apenas o que você conhece agora

• Avance um pouco

• Aprenda

• Ajuste o plano

• Repita 🔁

🎯 Precisão realista

• Planejamento de 3 meses → ~50% de precisão

• Planejamento de 2 semanas → ~100% de precisão

📌 Frase Bellacosa-style

Agile não tenta ser onisciente. Agile aceita que aprender faz parte do plano.

---

3️⃣ Por que trocar cargos sem treinamento leva ao fracasso

❌ Erro comum nas organizações

“Vamos virar Agile, mas sem mudar as pessoas nem o mindset.”

Isso gera falhas graves.

---

4️⃣ Product Manager ≠ Product Owner

• Product Manager

  • Cargo

  • Foco em orçamento e operação

• Product Owner

  • Papel do Scrum

  • Visionário

  • Conecta stakeholders ao time

  • Define experimentos e objetivos do sprint

📌 Nem todo Product Manager é um bom Product Owner.
E está tudo bem — desde que isso seja reconhecido.

---

5️⃣ Project Manager ≠ Scrum Master

Diferenças fundamentais:

Project Manager	Scrum Master
Gerencia tarefas	Atua como coach
Controla plano	Protege o time
Documenta riscos	Remove impedimentos
Cobra prazos	Fomenta autonomia

📌 Choque cultural clássico
O Project Manager pergunta:

“Como você vai se desbloquear?”

O Scrum Master responde:

“Deixa comigo. Vai trabalhar em algo produtivo.”

---

6️⃣ Development Team ≠ Scrum Team

• Development Team

  • Apenas desenvolvedores

• Scrum Team

  • Desenvolvedores

  • Testers

  • Ops

  • Segurança

  • Analistas de negócio

📌 Scrum Team é cross-functional
Tudo o que é necessário para gerar um incremento de valor.

---

7️⃣ O papel crítico da gestão no Agile

“Sem apoio da liderança, Agile vira teatro.”

Gestão tradicional pergunta:

• “O que você vai entregar até o fim do ano?”

Gestão ágil pergunta:

• “O que você vai entregar nas próximas duas semanas?”

• “Como vamos encantar o cliente no próximo sprint?”

📌 Citação-chave

Enquanto líderes insistirem em prazo, escopo e custo fixos, Agile não funciona como foi projetado.

---

8️⃣ Ferramentas não tornam ninguém ágil

• Kanban

• ZenHub

• Jira

• GitHub

👉 Nenhuma ferramenta cria mindset ágil sozinha

📌 Primeiro vem o processo
📌 Depois vem a ferramenta

---

9️⃣ O que é um Kanban Board (sem complicar)

Kanban é apenas:

• 📝 O que precisa ser feito

• ⚙️ O que está sendo feito

• ✅ O que já foi feito

Visual. Simples. Transparente.

---

🔟 Pipelines do Kanban (ZenHub como exemplo)

🔹 New Issues

• Caixa de entrada

• Tudo começa aqui

❄️ Icebox

• Armazenamento de longo prazo

• Ideias futuras

📦 Product Backlog

• Tudo o que queremos fazer algum dia

🏃 Sprint Backlog

• O que será feito nos próximos 14 dias

⚙️ In Progress

• Trabalho em execução

• Dono visível (avatar)

🔍 Review / QA

• Pull Requests

• Revisão de código

✅ Done

• Trabalho concluído pelo desenvolvedor

• Aceitação ocorre depois, no Sprint Review

---

🔄 Fluxo do trabalho no Kanban

➡️ Sempre da esquerda para a direita

• Entrada → Execução → Entrega

• Visual

• Atualizado

• Uma única fonte da verdade

📌 Desenvolvedor não atualiza vários sistemas
📌 Tudo acontece onde ele já trabalha: GitHub

---

🧠 Conclusão Bellacosa Mainframe

Agile não é sobre prever o futuro.
É sobre aprender mais rápido,
planejar melhor,
e entregar valor continuamente.

📦Resumo para ir mais longe

Implementar Agile na prática vai muito além de adotar cerimônias ou ferramentas. O verdadeiro diferencial das metodologias ágeis está na combinação equilibrada entre planejamento, pessoas e resultados. Embora o Agile valorize a adaptação às mudanças, isso não significa ausência de planejamento. Pelo contrário, o planejamento acontece de forma contínua, permitindo ajustes rápidos conforme surgem novas necessidades do negócio.

Nesse contexto, as pessoas ocupam papel central. Equipes multidisciplinares, comunicação transparente e colaboração constante tornam-se elementos fundamentais para o sucesso dos projetos. Frameworks como Scrum incentivam a participação ativa de todos os envolvidos, promovendo responsabilidade compartilhada e melhoria contínua.

Outro aspecto importante é o foco nos resultados. Em vez de medir sucesso apenas pelo cumprimento de cronogramas, o Agile busca entregar valor real ao cliente por meio de incrementos frequentes e funcionais. Cada sprint representa uma oportunidade de aprendizado, validação e refinamento das prioridades.

A prática ágil também estimula a identificação rápida de riscos, gargalos e oportunidades de melhoria. Reuniões como Daily Scrum, Sprint Review e Retrospective ajudam a manter alinhamento e transparência ao longo do projeto.

Quando bem aplicado, o Agile cria ambientes mais adaptáveis, produtivos e inovadores, permitindo que organizações respondam com maior velocidade às mudanças do mercado sem abrir mão da qualidade e da satisfação dos clientes.

 

🧠 Agile e Scrum : Do batch noturno ao sprint quinzenal

 

Bellacosa Mainframe em um projeto Agile Scrum 

🧠 Agile e Scrum

Do batch noturno ao sprint quinzenal — uma conversa franca de mainframeiro

“Agile não nasceu para matar o mainframe.
Nasceu para sobreviver ao mundo fora dele.”
— Bellacosa (provavelmente reclamando de um status meeting)

---

📜 Origem: quando o Waterfall começou a dar abend

Antes de Agile virar buzzword em slide corporativo, o mundo vivia sob o Waterfall:
analisa tudo → projeta tudo → codifica tudo → testa tudo → entrega tudo.

Funcionava…
👉 até o requisito mudar no meio do caminho.

No mainframe, isso era tolerável porque:

• sistemas eram estáveis

• mudanças eram raras

• o batch rodava à noite e ninguém mexia

Fora do CPD, o mundo começou a mudar rápido demais.

📅 2001 – O nascimento oficial do Agile

Em fevereiro de 2001, 17 desenvolvedores se reuniram em Utah (EUA) e escreveram o Manifesto Ágil.

📌 Easter egg histórico:
Nenhum deles falava em ferramenta, framework ou certificado.
Falavam de pessoas, colaboração e adaptação.

---

🔁 Scrum: o JES2 do Agile

Scrum não é metodologia.
Scrum é framework.

Assim como:

• JCL não é aplicação

• JES não é programa

• ISPF não escreve código

Scrum organiza o fluxo, mas não faz o trabalho por você.

📅 Scrum “oficial”

• Conceito inicial: 1986 (Takeuchi & Nonaka)

• Consolidação moderna: anos 1990

• Popularização absurda: 2010+ (quando começaram a estragar)

---

👥 Papéis do Scrum (tradução para mainframeiro)

• Product Owner
  👉 Dono do requisito, como o usuário que assina o change

• Scrum Master
  👉 Um misto de operador experiente + analista que tira impedimento do caminho

• Time
  👉 Quem realmente faz o sistema funcionar (igual sempre foi)

📌 Fofoquinha:
Em muitas empresas, o Scrum Master vira “chefe disfarçado”.
Isso quebra o Scrum mais rápido que DELETE sem backup.

---

🧩 User Story: o novo requisito funcional

User Story é simples:

Como <usuário>, quero <objetivo>, para <valor>.

Se você já escreveu:

• especificação funcional

• descrição de programa

• comentário de COBOL bem feito

👉 você já sabe escrever user story.

💡 Dica Bellacosa

User story grande demais é como JOB com 200 steps:
ninguém entende, ninguém testa, ninguém confia.

---

📊 Story Points: estimar sem mentir

Story Point não é hora, não é dia, não é prazo.

É:

• complexidade

• risco

• esforço relativo

📌 Easter egg Agile:
Times ruins transformam story point em hora escondida.
Times bons usam para prever, não para cobrar.

---

🗂️ Backlog e Kanban: o SDSF do projeto

O Product Backlog é a fila do sistema.
O Kanban Board é o painel:

• To Do

• In Progress

• Done

👉 Igual SDSF:

• você vê o que está rodando

• o que está esperando

• o que terminou

💡 Dica prática

Se tudo fica em “In Progress”, o problema não é Agile.
É falta de limite de WIP (Work in Progress).

---

📉 Burndown Chart: o SMF do Sprint

Burndown chart mostra:

• quanto trabalho falta

• se o sprint fecha

• se alguém mentiu na estimativa

📌 Curiosidade:
Scrum não manda “bater meta”.
Ele apenas mostra a realidade.
Quem não gosta do gráfico geralmente não gosta da verdade.

---

🧪 Execução diária: o batch agora é contínuo

Daily Stand-up

• Não é reunião de status

• Não é para gerente

• Não passa de 15 minutos

👉 É para sincronizar o time, como um checkpoint lógico.

Sprint Review

• Mostra o que foi entregue

• Não é teatro

Retrospective

• Onde o time melhora

• Onde a política costuma atrapalhar

---

🛠️ Ferramentas modernas (com cheiro de CPD)

• GitHub
  Versionamento, issues, colaboração
  👉 o novo Librarian/Endevor

• ZenHub
  Agile sobre o GitHub
  👉 backlog, sprint, burndown

• Boards nativos do GitHub
  Simples, mas funcionais

📌 Fofoquinha de bastidor:
Empresa que compra ferramenta antes de mudar cultura
só troca Waterfall por Agile fake.

---

🎓 Curso IBM – Quando a teoria encontra a prática

O curso Introduction to Agile Development and Scrum (IBM):

📅 Lançamento: década de 2020
🎯 Público: iniciantes
🧠 Abordagem: prática, direta, sem romantismo

Inclui:

• Agile

• Scrum

• Kanban

• GitHub

• ZenHub

• Projeto final completo

Faz parte do IBM DevOps and Software Engineering Professional Certificate.

---

🧠 Dicas Bellacosa (aprendidas na dor)

✔ Agile não acelera time ruim
✔ Scrum não salva projeto sem dono
✔ Ferramenta não substitui disciplina
✔ Daily não resolve problema estrutural
✔ Retrospective ignorada vira reunião inútil

---

🥚 Easter Eggs para quem veio do mainframe

• Agile é iterativo como release de sistema legado

• Sprint é mini-release controlado

• Burndown é SMF emocional do time

• Kanban é SDSF com post-it

• Waterfall é batch eterno sem restart

---

🎯 Conclusão: Agile não é moda, é sobrevivência

O mainframe sobreviveu porque:

• era estável

• era disciplinado

• evoluía sem quebrar

Agile sobrevive pelo mesmo motivo.

👉 Quem entende mainframe entende Agile mais rápido do que imagina.

No fim, muda a ferramenta.
Muda o ritmo.
Mas a verdade continua a mesma:

Sistema bom é aquele que entrega valor
sem acordar ninguém de madrugada.

— Bellacosa Mainframe ☕💾

💾 Resumo Para ir mais longe

A evolução do desenvolvimento de software pode ser comparada à transição do tradicional batch noturno dos mainframes para os modernos ambientes de entrega contínua. Durante décadas, projetos eram conduzidos por modelos rígidos, com longos ciclos de análise, desenvolvimento, testes e implantação. Embora eficientes para sua época, essas abordagens tinham dificuldades para lidar com mudanças frequentes de requisitos.

Foi nesse cenário que surgiram os conceitos de Agile e, posteriormente, o framework Scrum. Baseados no Manifesto Ágil de 2001, esses métodos priorizam colaboração, adaptação, entregas frequentes e foco no valor para o cliente. Em vez de esperar meses ou anos por uma versão completa, as equipes passam a trabalhar em ciclos curtos chamados sprints, entregando incrementos funcionais do produto regularmente.

O Scrum organiza o trabalho por meio de elementos como Product Backlog, Sprint Backlog, Daily Meeting, Sprint Review e Retrospective, promovendo transparência e melhoria contínua. Curiosamente, muitos profissionais de mainframe percebem que conceitos como planejamento rigoroso, controle de mudanças e confiabilidade operacional continuam relevantes mesmo no universo ágil.

Hoje, Agile e Scrum são amplamente utilizados em empresas de todos os portes, integrando-se a práticas como DevOps, automação e cloud computing. O objetivo permanece o mesmo: entregar software de qualidade com rapidez, eficiência e capacidade de adaptação às necessidades do negócio.