Bellacosa Mainframe em gestao de projetos no Mainfrmae

💣🔥 O JOB NÃO FALHA — QUEM FALHA É A GESTÃO

O Guia Bellacosa Mainframe para Sobreviver (e Dominar) Projetos em COBOL 🔥💣

Se você é programador COBOL júnior e acha que projeto mainframe é só codar PERFORM UNTIL EOF… sinto te informar: você está rodando em modo batch sem controle de job 😈

Mainframe não quebra. Ele cobra disciplina.
E gestão de projeto aqui não é burocracia… é o JCL invisível que faz tudo funcionar.

---

🧠 ANTES DE TUDO: O QUE É “GESTÃO” NO MAINFRAME?

Gestão de projetos no mundo z/OS é:

👉 Garantir que milhões de registros sejam processados sem erro
👉 Coordenar jobs, pessoas, prazos e dados
👉 Evitar o pior pesadelo:

S0C7 em produção às 02:13 da manhã

Se código é instrução…
👉 gestão é orquestração

---

🏛️ ORIGEM: POR QUE MAINFRAME VIROU OBCECADO POR PROCESSO?

Volta comigo:

• Anos 60–70: surgem sistemas críticos bancários
• Anos 80: batch vira padrão industrial
• Anos 90: explosão de sistemas COBOL corporativos

Resultado?

💡 Um erro simples = milhões de dólares perdidos

Então nasceram:

• ITIL
• PMBOK
• Governança rígida
• Change management

👉 No mainframe, processo não é opcional — é sobrevivência

---

⚙️ O CICLO DE VIDA DE UM PROJETO MAINFRAME (PASSO A PASSO)

🔹 1. Levantamento (O “INPUT DD *” do projeto)

Aqui você descobre:

• O que o sistema faz
• Quem usa
• Qual o impacto

📌 Exemplo:

“Precisamos incluir um novo campo no extrato bancário”

Tradução real:

mexer em COBOL + DB2 + JCL + arquivos VSAM + downstream systems 😅

---

🔹 2. Análise (O COPYBOOK DA VIDA REAL)

Você vai mapear:

• Programas impactados
• Arquivos
• JOBs
• Interfaces

Ferramentas comuns:

• ISPF 3.14 (Search)
• SYSVIEW / SDSF
• Ferramentas de impacto

💣 Easter egg:

Quem nunca abriu um programa COBOL com 20.000 linhas… não viveu.

---

🔹 3. Design (A ARQUITETURA INVISÍVEL)

Decisões críticas:

• Alterar ou criar novo programa?
• Batch ou online (CICS)?
• DB2 ou VSAM?

📌 Exemplo prático:

Antes:
EXTRATO-OLD

Depois:
EXTRATO-V2 + compatibilidade retroativa

👉 Aqui nasce a dívida técnica… ou você evita ela.

---

🔹 4. Desenvolvimento (A HORA DO COBOL RAIZ)

Agora sim, código:

IF SALDO < 0
   MOVE 'DEVEDOR' TO STATUS-CONTA
END-IF

Mas atenção:

👉 Código precisa seguir padrão da empresa
👉 Naming convention é religião
👉 COPYBOOK é contrato

---

🔹 5. Testes (O VERDADEIRO CAMPO DE BATALHA)

Tipos:

• Unitário
• Integrado
• Batch completo
• Teste de volume

Ferramentas:

• JCL de teste
• Dados simulados
• Comparadores de arquivos

💣 Curiosidade:

Muitos bugs só aparecem com milhões de registros.
Pequeno volume = falsa sensação de sucesso.

---

🔹 6. Implantação (O “SUBMIT” QUE DEFINE VIDAS)

Aqui entra:

• Change management
• Aprovação
• Janela de deploy

📌 Exemplo JCL simbólico:

//DEPLOY EXEC PGM=IEFBR14

😏 Sim… até o IEFBR14 participa da história.

---

🔹 7. Pós-Produção (O MONITORAMENTO SILENCIOSO)

Você vai:

• Acompanhar logs
• Ver RC (Return Code)
• Validar dados

👉 RC=0 = felicidade
👉 RC>0 = café + guerra

---

🧩 COMO USAR ISSO NA PRÁTICA (SENDO JÚNIOR)

Aqui é onde você vira profissional de verdade:

✔️ Regra 1: Nunca altere sem entender o fluxo completo

✔️ Regra 2: Sempre leia o JCL antes do COBOL

✔️ Regra 3: Pergunte sobre impacto (upstream/downstream)

✔️ Regra 4: Documente — mesmo que ninguém peça

---

🧠 MENTALIDADE MAINFRAME (O DIFERENCIAL)

Enquanto dev moderno pensa:

“funciona no meu ambiente”

Mainframe pensa:

“funciona para milhões de clientes em produção crítica”

---

💣 CURIOSIDADES QUE POUCOS CONTAM

• COBOL ainda processa trilhões de dólares diariamente
• Muitos sistemas têm código com +40 anos em produção
• Programas são alterados por dezenas de pessoas ao longo das décadas

👉 Você não escreve código…
👉 você entra em uma linha do tempo viva

---

🕵️ EASTER EGGS DO MUNDO MAINFRAME

• IEFBR14 = programa que “não faz nada”… mas faz tudo 😏
• S0C7 = erro clássico de conversão (e trauma coletivo)
• COND=(0,NE) = aquele IF misterioso do JCL
• Comentários de 1998 ainda salvando vidas hoje

---

📚 MATERIAL DE APOIO (OBRIGATÓRIO PRA EVOLUIR)

📘 Livros

• Enterprise COBOL Programming Guide
• IBM z/OS Basics

🌐 Conceitos importantes

• ITIL (gestão de serviços)
• PMBOK (gestão de projetos)
• DevOps adaptado ao mainframe

🛠️ Ferramentas

• ISPF
• SDSF
• Endevor / Changeman
• DB2 SPUFI

---

🚀 RESUMO FINAL (EM MODO JCL)

//GESTAO EXEC PGM=SUCESSO
//INPUT   DD *
DISCIPLINA, PROCESSO, CONTEXTO
/*
//OUTPUT  DD SYSOUT=*
RESULTADO: SISTEMA ESTAVEL

---

🔥 FECHAMENTO ESTILO BELLACOSA

Mainframe não é sobre tecnologia…
é sobre responsabilidade em escala absurda.

Você não é só um programador COBOL júnior.

👉 Você é operador de um sistema que nunca pode parar.

E agora você sabe:
o código é só metade do jogo — a gestão é o que mantém o sistema vivo. 💣🔥

📉 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.