🍑 COMO PRODUZIR UMEBOSHI EM CASA

Bellacosa Mainframe na seca da ume para produzir umeboshi

🍑 COMO PRODUZIR UMEBOSHI EM CASA

Receita raiz ao estilo Bellacosa Mainframe
(quando você vira operador, storage, JES2 e backup da tradição japonesa)

Vou te dizer logo de cara: fazer umeboshi em casa não é receita, é processo batch.
Não tem atalho, não tem CTRL+C / CTRL+V, não tem pressa.
É job longo, roda por meses, mas quando termina… entrega resiliência em forma de comida.

---

🏯 PRIMEIRO: O QUE É UME?

A ume é uma ameixa japonesa (na real, um híbrido entre damasco e ameixa).
Sozinha ela é azeda, dura e ingrata.
Mas depois do processamento correto… vira umeboshi, um dos alimentos mais antigos, funcionais e simbólicos do Japão.

👉 Conserva
👉 Probiótico natural
👉 Antibiótico ancestral
👉 Backup alimentar de guerra

---

📦 PRÉ-REQUISITOS (DATASETS OBRIGATÓRIOS)

Antes de submeter o job:

• 1 kg de ume verde (não madura, firme)

• 150 a 200 g de sal grosso marinho (15–20%)

• Shiso vermelho seco (opcional, mas clássico)

• Pote de vidro ou cerâmica esterilizado

• Peso (prato + algo pesado)

• Sol, paciência e silêncio

⚠️ Erro comum de iniciante: usar ameixa comum.
Não é a mesma coisa. Job abenda.

---

🧼 STEP 1 — LIMPEZA (ALLOCATE & SORT)

1. Lave as ume com cuidado.

2. Retire os cabinhos.

3. Seque uma a uma.

Aqui é igual preparar dataset crítico:
qualquer sujeira vira corrupção futura.

---

🧂 STEP 2 — SALGA (EXEC PGM=UMEBOSHI)

1. Faça camadas no pote:

   • ume

   • sal

   • ume

   • sal

2. Termine com sal por cima.

3. Cubra com prato e coloque peso.

📌 Após 2–3 dias, vai surgir líquido: umezu.
Isso é sinal de job rodando com sucesso.

---

🌿 STEP 3 — SHISO (OPCIONAL, MAS TRADICIONAL)

Se usar shiso vermelho:

1. Amasse com sal até soltar líquido escuro.

2. Descarte o líquido.

3. Coloque o shiso junto das ume no pote.

Resultado:
🔴 cor
🌸 aroma
🧠 memória cultural

---

☀️ STEP 4 — SECAGEM AO SOL (LONG RUNNING JOB)

Depois de 1 mês em salmoura:

1. Retire as ume.

2. Seque ao sol por 3 dias, virando de tempos em tempos.

3. À noite, recolha (orvalho é corrupção de dados).

Isso é batch noturno + diurno, estilo raiz.

---

🗄️ STEP 5 — ARMAZENAMENTO (BACKUP OFFSITE)

• Volte as ume para o pote

• Cubra com umezu

• Armazene em local fresco

⏳ Tempo de maturação:

• Mínimo: 6 meses

• Ideal: 1 a 3 anos

• Mestres: 10+ anos

Sim, umeboshi envelhece melhor que vinho.

---

🧠 DICAS DE OPERADOR VETERANO

✔ Quanto mais sal, mais durável
✔ Menos sal = mais cuidado
✔ Mofo branco pode ser removido
✔ Mofo preto = ABEND S0C7 (descarta tudo)

---

🥢 COMO USAR (APLICAÇÕES)

• Com arroz branco

• Dentro do onigiri

• Em chá quente (remédio)

• Em molhos

• Para “acordar o sistema” depois de exageros

---

🥋 FILOSOFIA EMBUTIDA

Fazer umeboshi ensina:

• Mottainai – nada se desperdiça

• Wabi-sabi – o valor do imperfeito

• Shikata ga nai – o tempo manda

• Resiliência – algo ácido vira força

---

🧠 CONCLUSÃO BELLACOSA

Produzir umeboshi em casa é como trabalhar com mainframe:

• Antigo

• Lento

• Preciso

• Pouco entendido

• Mas absolutamente confiável

É comida que aguenta crises, guerras, apagões…
e ainda melhora com o tempo.

Se quiser, no próximo post eu te ensino:
👉 Umeboshi low-salt (cloud-native)
👉 Umeboshi com mel (versão ocidental)
👉 Falhas comuns e ABENDs do processo

☕🍑
Aqui a tradição roda em batch…
e não falha.

 

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.

SMP/E: Entendendo o guardião do z/OS - Parte 1

 

Bellacosa Mainframe apresenta o IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 1 – Entendendo o guardião do z/OS 

“No mainframe, nada entra em produção sem passar pelo crivo do SMP/E.”

---

🧠 O que é SMP/E (sem enrolação)

SMP/E (System Modification Program / Extended) é o gerenciador oficial de mudanças do z/OS.

Ele garante que:

• Correções sejam aplicadas na ordem certa

• Dependências sejam respeitadas

• Nada seja sobrescrito por acidente

• O histórico do sistema seja preservado

👉 Em resumo Bellacosa:

SMP/E é o síndico do prédio chamado z/OS.

---

🕰️ Um pouco de história (porque mainframe tem memória)

Antes do SMP/E:

• Correções eram copiadas “na mão”

• Não havia controle de versão

• Produção quebrava sem explicação

A IBM então criou o SMP, que evoluiu para o SMP/E, acompanhando:

• OS/360

• MVS

• OS/390

• z/OS

📆 Presente em TODOS os releases modernos do z/OS.

---

🧩 Conceitos básicos que você precisa gravar

🔹 SYSMOD

É o pacote de mudança que o SMP/E gerencia.

Tipos mais comuns:

• PTF – correção de defeito

• APAR – problema reportado

• USERMOD – modificação do cliente

• FUNCTION – novo produto ou função

📌 Sem SYSMOD, o SMP/E não trabalha.

---

🔹 CSI – Consolidated Software Inventory

O CSI é o cérebro do SMP/E.

Ele guarda:

• O que está instalado

• O que depende de quê

• O que foi aplicado

• O que foi aceito

👉 Quebrou o CSI? Parou o mundo.

---

🔁 O fluxo básico do SMP/E (decore isso)

1️⃣ RECEIVE

Recebe o SYSMOD e registra no CSI.

“Agora o SMP/E sabe que isso existe.”

---

2️⃣ APPLY

Aplica o SYSMOD no Target Libraries.

“Agora o sistema pode usar.”

---

3️⃣ ACCEPT

Atualiza o DLIB (baseline oficial).

“Agora isso virou padrão.”

---

📌 Regra Bellacosa:

Nunca ACCEPT sem antes validar o APPLY.

---

📦 Target x DLIB (confusão clássica)

Biblioteca	Função
TARGET	Executável
DLIB	Referência / fonte

❌ Erro comum de iniciante:

“Achei que DLIB era produção.”

---

🚨 O que são MCS?

MCS (Modification Control Statements) são as instruções que acompanham o SYSMOD.

Todas começam com:

++

Exemplos famosos:

• ++VER

• ++MOD

• ++HOLD

• ++ERROR

👉 MCS dizem ao SMP/E como tratar o código.

---

🧪 Exemplo simples de MCS

++PTF(UJ12345).
++VER(Z038) FMID(HJES770).

📌 Isso diz:

• É um PTF

• Serve para o FMID HJES770

• Compatível com versão Z038

---

🎓 Como estudar SMP/E (do jeito certo)

📘 Teoria

• IBM Docs

• Redbooks

• APARs reais

🧪 Prática

• SMP/E for z/OS Workshop

• APPLY CHECK

• Ambientes de teste

💡 Dica Bellacosa:

“SMP/E só entra na cabeça quando você vê um APPLY falhar.”

---

🧠 Curiosidade Bellacosa

• SMP/E já resolvia dependência antes do DevOps

• Já fazia auditoria antes do compliance virar moda

• Não tem interface bonita, mas nunca falha

---

🧾 Encerramento – Parte 1

Quem aprende SMP/E não briga com produção.
Quem ignora SMP/E vira refém de outage.

Na Parte 2, vamos falar de:

👉 SYSMOD, PTF, APAR e USERMOD na prática 

🏫 Capítulo 1 — O garoto das cidades trocadas

 

Bellacosa Mainframe e a infância isekai

📚 SÉRIE “Sempre um Isekai”

Por Bellacosa Mainframe
(Memórias de um garoto que aprendeu a trocar de mundo sem sair da sala de aula)

---

🏫 Capítulo 1 — O garoto das cidades trocadas

Foto escolar em 1981

As escolas que frequentei foram tantas que minha infância virou uma colcha de retalhos costurada à pressa.

Sempre fui mais tímido do que expansivo, mas a profissão do meu pai — fotógrafo — nos ensinou a viver em constante movimento.

Lembranças do prézinho no parque 3 marias

Cada mudança era uma nova lente, um novo enquadramento, uma turma inteira tentando entender quem era o aluno recém-chegado.

Memórias do primeiro ano, a professora Cecilia, brava e muito rígida para um pequeno garoto, que terminava muito rápido as lições, para poder desenhar mechs em antigos envelopes fotográficos. O unico amigo que me lembro de 1981, era um asiático chamado Fabio, cujo  o obâchan (

$おばあちゃん$

), era fotografo profissional e virou mentor do meu pai, evoluindo na amizade de ambos, que incluiu as respectivas familias, cimentando minha amizade com o Fábio, com isso ambos eramos fanáticos por mechs e robôs gigantes vindo da Terra do Sol nascente, 

Caderno de calagrafia

Inclusive um dia, ambos muito inspirados em desenhar Spectreman, fomos apanhados pela professora Cecilia, que apesar de termos terminados nossas atividades escolares, fomos duramente repreendidos e colocados de castigo, em pé atras da porta. Algo que marcou minha memória até os dias atuais... 

Cartilha Caminho Suave

Um ano bem traumático, tantas coisas ruim aconteceram em tão pouco tempo. No terceiro ano do primário, passei por três escolas diferentes em três municípios distintos.
Estudei em São Paulo, Pirassununga, Quiririm,

O terceiro ano começou bem, com muita expectativa com a professora Maria, mas a meio do ano uma catástrofe familiar, me derrubou. Nesse meio tempo retornamos a São Paulo em clima de tragédia. Despenquei nas aulas, notas sofríveis e quase reprovando o ano, porém com nova mudança ao Quiririm. Um recomeço com uma nova professora, Maria, recuperei de tal maneira, que a professora emocionada me presenteou com um troféu.

Professora Maria do 3ºano no Quiririm

Quarto ano, uma professora bem velhinha, que amava ensinar a mitica Ligia, uma senhora que educou gerações de pessoas no Quiririm, que tinha prazer imenso em ensinar, uma excelente professora, que serviu de ritual de passagem entre o primário e ginásio. Deixando grandes e boas lembranças da turma do Quarto Ano B da escola Deputado Cesar Costa.

Outros passos do quinto e sexto ano em Taubaté… e novamente São Paulo para concluir o setimo e oitavo ano, sempre correndo, sempre me adaptando. Criando um novo ser a cada escola nova, novas regras, novos professores e novos amigos.

No Ginásio foram dezenas de professores, a memória perdeu o nome da maioria, mas aqueles especiais ficaram Mirtes e Luis de Matemática, Dinah de história, Edvan de ciências, a doce Regina de Educação Moral e Cívica, Miguel de Inglês, conforme for lembrando atualizarei o poste.

Um reencontro com a melhor professora que tive no primario, a lendaria professora Maria

Na minha época escolar, a evolução era dividida em 3 etapas: primário primeiro ao quarto ano com educação básica, usando lápis e borracha, com caderno normal e no meu caso tarefas adicionais em caderno de caligrafia; ginásio do quinto ao oitavo ano com inúmeros professores, cada qual com sua disciplina usando caderno do ginásio e uso de canetas. Para finalmente o Colegial com a possibilidade de ir pelo científico vocacionado a Vestibulares de elite e o Técnico com profissão, mas acesso a faculdades de segunda linha.

Relembrando do caminho seguido desde a pré-historia

Esqueci de comentar que antes de entrar em tudo isso tinha a pré-escola, onde recebíamos os fundamentos de leitura e escrita, matemática e preparava o aluno a entrar em escola no primário.

Até terminar o ginásio, minha vida escolar parecia uma sessão de slides — clique, nova imagem, novo começo.

O colegial fiz em Ferraz de Vasconcelos, o que me obrigou a ser mais aberto, a sorrir primeiro e esperar a empatia depois.

Aprendi cedo que mudar exige não apenas coragem, mas também leveza.

Sempre senti falta de raízes — daqueles amigos que crescem juntos, colecionam histórias e ficam na mesma rua por anos.
Mas a vida me direcionou para outro roteiro.
Sem perceber, vivi meu próprio isekai: em cada escola, um novo universo, uma chance de provar que eu pertencia àquele mundo.

E assim fui acumulando colegas, experiências e memórias, como quem vive duas vidas — uma em cada recomeço.

Bellacosa Mainframe apresenta a mitica cerveja sapporo

🍺 SAPPORO – A CERVEJA MÍTICA DO JAPÃO (E UM MAINFRAME LÍQUIDO)

Se o Japão tivesse um logotipo gravado em aço, ele teria uma estrela vermelha de cinco pontas e o nome SAPPORO. Não é só cerveja. É legado, é uptime, é batch rodando há mais de um século sem falhar.

Hoje eu não vou falar só de bebida. Vou falar de história líquida, de cultura engarrafada e daquele primeiro gole que parece um IPL bem-sucedido.

---

⭐ ORIGEM – NASCE UM MAINFRAME EM HOKKAIDO

A Sapporo Beer nasce oficialmente em 1876, na cidade de Sapporo, ilha de Hokkaido.
O Japão estava se modernizando após a Restauração Meiji e decidiu aprender com os alemães a arte da cerveja.

👨‍🔬 Seibei Nakagawa, mestre-cervejeiro treinado na Alemanha, foi o arquiteto desse sistema.

Resultado?
Uma cerveja lager, limpa, estável, previsível (no melhor sentido), feita para rodar 24x7.

---

🍺 O SABOR – SEM BUG, SEM EXCESSO

Sapporo é:

• leve

• seca

• refrescante

• sem doçura exagerada

• sem amargor agressivo

💡 É cerveja OLTP, não é batch pesado.

Perfeita para:
✔ acompanhar comida
✔ beber mais de uma
✔ não cansar o paladar
✔ conversar por horas

---

cerveja sapporo

🏭 O QUE VER – SAPPORO BEER MUSEUM

Se estiver no Japão, pare tudo e vá ao Sapporo Beer Museum.

Você vai ver:
🍺 equipamentos antigos
📜 rótulos históricos
🧠 a evolução da marca
🏭 como se mantém consistência por 150 anos

👉 É tipo visitar um CPD histórico, mas com degustação no final.

---

🍖 O QUE COMER – PAREAMENTO PERFEITO

🍖 Jingisukan (cordeiro grelhado típico de Hokkaido)
🍜 Ramen de Sapporo (miso pesado)
🍤 Tempurá
🍣 Peixes gordos

Sapporo limpa o paladar como SORT com OUTREC bem escrito.

---

🧠 CURIOSIDADES & EASTER EGGS

⭐ A estrela vermelha vem do símbolo do governo de Hokkaido
⭐ Sapporo é uma das cervejas japonesas mais antigas ainda ativas
⭐ Produção fora do Japão segue padrão rigoroso
⭐ No Japão, beber Sapporo no inverno é comum (frio não é argumento)

🟡 Easter egg: no Japão, Sapporo é vista como cerveja de gente séria, não modinha.

---

🍺 SAPPORO NOS ANIMES & CULTURA POP

Aparece discretamente em:

• Izakayas de Shokugeki no Soma

• Mangás slice of life

• Dramas japoneses

• Animes adultos (onde ninguém bebe energético colorido)

Quando aparece, significa:
➡️ vida real
➡️ pausa merecida
➡️ maturidade

---

🧠 COMENTÁRIO BELLACOSA

Sapporo me lembra mainframe porque:

• não grita

• não pisca

• não tenta impressionar

• só funciona

Enquanto outras cervejas querem ser “craft”, “hiper lupuladas” ou “influencer friendly”, a Sapporo segue firme:

🍺 entregando consistência há quase 150 anos

---

🏁 CONCLUSÃO

Sapporo não é hype.
É infraestrutura.

É aquela cerveja que:
✔ acompanha conversa longa
✔ respeita o prato
✔ não briga com o paladar
✔ nunca sai de produção

Uma cerveja para quem entende que confiabilidade vence moda.

🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺 🍺

🧠 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 ☕💾

📘 Treinamento Completo de Auditoria z/OS

Bellacosa Mainframe treinamento em Auditoria em IBM Z/OS

📘 Treinamento Completo de Auditoria z/OS

Estilo Bellacosa Mainframe — do técnico ao auditável

"Auditoria em z/OS não é um evento. É um estado permanente de controle."

---

🎯 Objetivo do treinamento

Capacitar profissionais de mainframe a:

• Preparar ambientes z/OS para auditoria

• Responder auditores com evidência técnica

• Evitar não conformidades

• Implementar governança contínua

Público-alvo:

• System Programmers

• Analistas de Segurança

• Auditores técnicos

• Arquitetos mainframe

---

🧱 Estrutura do treinamento

🧩 Módulo 1 – Fundamentos de Auditoria em z/OS

• O que o auditor realmente procura

• Tipos de auditoria (interna, externa, regulatória)

• Conceitos: evidência, rastreabilidade, segregação

• Por que z/OS já nasce auditável

📌 Entregável: checklist conceitual

---

🔐 Módulo 2 – Controle de Acesso (RACF)

• IDs privilegiados (SPECIAL, OPERATIONS)

• UACC e perfis genéricos

• Logging e SMF

• Revisão periódica de acessos

📌 Laboratório:

• Identificar riscos reais em perfis RACF

---

📦 Módulo 3 – SMP/E como pilar de integridade

• CSI, DLIB e TARGET

• RECEIVE, APPLY, ACCEPT

• APPLY CHECK

• ++HOLD, ++ERROR, ++VER

📌 Laboratório:

• Análise de PTF com HOLD de segurança

---

🧩 Módulo 4 – USERMOD e risco operacional

• Quando USERMOD é aceitável

• Documentação obrigatória

• Riscos em auditoria

• Plano de remoção

📌 Estudo de caso real

---

🔁 Módulo 5 – Gestão de Mudanças

• Integração SMP/E + Change Management

• Evidências exigidas

• Falhas clássicas em auditoria

📌 Oficina:

• Montar dossiê de mudança

---

🧪 Módulo 6 – Evidência técnica e rastreabilidade

• Outputs SMP/E

• Logs RACF

• SMF como prova

• Versionamento de JCL

📌 Laboratório:

• Criar pacote de evidências

---

🛡️ Módulo 7 – Segurança e Compliance

• PTFs de segurança

• Backlog e risco

• Auditorias regulatórias (SOX, PCI, LGPD)

📌 Discussão guiada

---

🔄 Módulo 8 – Continuidade e Recuperação

• Backup do CSI

• RESTORE na prática

• Testes documentados

📌 Laboratório:

• Simulação de rollback

---

📋 Módulo 9 – Auditoria passo a passo

• Como o auditor conduz a sessão

• Como responder perguntas difíceis

• O que nunca dizer

📌 Simulação completa de auditoria

---

🧠 Estudos de Caso Bellacosa

• USERMOD esquecido

• CSI sem backup

• ALTER irrestrito

• PTF de segurança atrasado

---

📜 Avaliação e Certificação

• Checklist executável preenchido

• Estudo de caso resolvido

• Avaliação prática

🎓 Certificado: Auditoria Técnica z/OS – Nível Profissional

---

🧰 Material complementar

• Checklist executável

• Modelos de evidência

• JCLs de laboratório

• Guia rápido para auditores

---

🏁 Encerramento

"No mainframe, auditoria não é medo. É maturidade operacional."

📘💾🛡️

📘 Treinamento Completo De Auditoria Z/os