segunda-feira, 6 de abril de 2009

💾 Capítulo 3 — Boot inicial: o mundo além da escola

 

📚 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 3 — Boot inicial: o mundo além da escola

O fim do colegial chegou rápido — como o ponto final de um livro que a gente queria que tivesse mais capítulos.
Mas o próximo volume já estava sendo escrito: o mundo do trabalho.

Com o diploma técnico em mãos e a curiosidade de quem sempre foi estrangeiro de si mesmo, entrei no universo do Processamento de Dados — ainda não se falava em “TI”.
Era um tempo em que o computador ocupava salas inteiras, e a palavra “mainframe” soava como magia industrial.
Aquele mundo lógico e silencioso me acolheu como nenhum outro.
Ali, finalmente, eu não era o aluno novo — eu era o programador que aprendia a dialogar com máquinas, e cada compile successful era uma nova forma de pertencer.

Percebi que, afinal, viver em trânsito não era desvantagem — era um sistema operacional de alma.
Ser o “novo” sempre me ensinou a observar, adaptar e reconstruir — exatamente o que um bom analista faz.
Minha vida inteira foi um boot contínuo: cada cidade, uma reinicialização; cada escola, uma nova rotina; cada linha de código, uma lembrança em hexadecimal.

Trabalhando como office-boy foi conquistando meu espaço, crescendo, fiz a faculdade, pós-graduação e mestrado, cresci academicamente, mas não abandonei os meus, protegi o quanto pode e ajudei a todos a trilharem o bom caminho. Não imagina que seria apenas o começo e que este isekai iria ainda mais longe, desta vez atravessando o oceano, mas isso já é outra história.

E talvez seja isso o que nos torna humanos no mundo das máquinas: a capacidade de recomeçar sem perder a memória.


☕ Epílogo — O Isekai Real

No fim das contas, percebo que nunca precisei ser transplantado para outro mundo.
Meu isekai sempre foi aqui mesmo — entre escolas, cidades e sistemas que me forjaram.
E, como todo bom personagem de jornada, aprendi que mudar é só outra forma de continuar.


Série “Sempre um Isekai”
Um relato sobre educação, adaptação e vocação — onde cada reboot é também um renascimento.
Assinado: Bellacosa Mainframe


quarta-feira, 18 de março de 2009

🌿 SHISO VERMELHO – A ERVA JAPONESA QUE PINTA A MEMÓRIA

 

Bellacosa Mainframe apresenta shiso vermelho

🌿 SHISO VERMELHO – A ERVA JAPONESA QUE PINTA A MEMÓRIA

 

Se você já assistiu anime, leu mangá ou se aventurou numa receita japonesa mais raiz, uma hora esbarrou nele: shiso vermelho. Às vezes discreto, às vezes protagonista, mas sempre ali, rodando em background como um daemon cultural do Japão.

Hoje vou te contar a história dessa erva que parece simples, mas carrega cor, aroma, superstição, medicina, comida e memória.


shiso

🌱 O QUE É SHISO?

Shiso (紫蘇) é uma erva da família da hortelã.
Existem dois tipos principais:

  • 🟢 Shiso verde (aojiso) – fresco, herbal, muito usado como folha

  • 🔴 Shiso vermelho (akajiso) – mais intenso, levemente amargo, usado para cor, conserva e fermentação

O shiso vermelho é o sysprog da cozinha japonesa: não aparece sempre, mas quando entra… muda tudo.


🏯 ORIGEM & HISTÓRIA

O shiso veio da China há mais de 2.000 anos, mas foi no Japão que ele ganhou identidade própria.

Originalmente usado como:

  • Planta medicinal

  • Conservante natural

  • Antídoto contra intoxicações alimentares

📜 Textos antigos diziam que shiso “acalma o espírito e limpa o sangue”.
Ou seja: debug emocional e físico.


🍙 USO CLÁSSICO NA CULINÁRIA

O shiso vermelho aparece em:

  • Umeboshi (ameixa japonesa)

  • Umezu (líquido da conserva)

  • Furikake

  • Conservas de legumes

  • Bebidas fermentadas

  • Doces tradicionais

👉 Ele é responsável pela cor vermelha icônica da umeboshi.
Sem shiso, a ameixa fica bege, triste, sem alma.
É tipo CICS sem terminal: funciona, mas não encanta.


🧪 CURIOSIDADE TÉCNICA (EASTER EGG BOTÂNICO)

A cor vermelha do shiso vem da antocianina, que:

  • Muda de cor conforme o pH

  • Fica vermelho intenso em meio ácido

  • Era usada como indicador natural antes da química moderna

📌 Sim, o shiso era um pH meter ancestral.


🥋 SHISO EM ANIMES & CULTURA POP

Você já viu shiso em:

  • 🍙 Animes slice of life – preparo de onigiri e umeboshi

  • 🏯 Animes históricos – conservas caseiras

  • 👘 Cenários rurais – quintais e hortas tradicionais

  • 🧘 Obras contemplativas – símbolo de cuidado e tempo

Ele quase nunca é explicado.
Porque no Japão, todo mundo sabe o que é shiso.


🧠 DICAS DE VETERANO

✔ Não confundir com manjericão
✔ Shiso vermelho é mais forte que o verde
✔ Seco dura meses
✔ Fresco estraga rápido (volatile dataset)
✔ Aroma lembra hortelã + canela + terra molhada


👀 FOFOQUICES DE COZINHA

🍃 Criança japonesa que ajuda a fazer umeboshi fica com as mãos roxas
🍃 Casas antigas tinham shiso no quintal como “erva de proteção”
🍃 Era usado para “neutralizar” peixe suspeito antes da refrigeração


🧠 FILOSOFIA ESCONDIDA

Shiso vermelho ensina:

  • Mottainai – nada se desperdiça

  • Tempo – não se apressa fermentação

  • Wabi-sabi – beleza na imperfeição da cor

  • Memória – sabor que atravessa gerações


🏁 CONCLUSÃO BELLACOSA

O shiso vermelho não grita.
Não aparece em propaganda.
Não pede holofote.

Mas sem ele, a cozinha japonesa perde alma, cor e história.

É a erva que roda silenciosa no background…
igual mainframe.

🌿Aqui, até a erva tem memória.

terça-feira, 17 de março de 2009

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

 

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.

terça-feira, 3 de março de 2009

SMP/E : SYSMOD sem mistério = Parte 2

 

Bellacosa Mainframe apresenta IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 2 – SYSMOD sem mistério  

“No SMP/E, tudo gira em torno do SYSMOD.
Entendeu o SYSMOD, entendeu metade do sistema.”


🧠 O que é SYSMOD (de verdade)

SYSMOD (System Modification) é a unidade básica de mudança controlada pelo SMP/E.

👉 Em português Bellacosa:

SYSMOD é o envelope lacrado que traz código, regras e avisos.

Dentro dele vêm:

  • Código novo ou corrigido

  • Instruções (MCS)

  • Dependências

  • Restrições

  • Alertas (HOLD, ERROR)


🧩 Tipos de SYSMOD (decore isso)

🔹 1. FUNCTION

É a base de tudo.

  • Instala um produto ou grande componente

  • Cria o “chão” para os outros SYSMODs

  • Exemplo: instalação inicial do JES2, CICS, DB2

📌 Sem FUNCTION, nada existe.


🔹 2. PTF (Program Temporary Fix)

É a correção prática do dia a dia.

  • Corrige defeitos

  • Resolve APARs

  • É o SYSMOD mais comum

📌 PTF não é opcional. Segurança agradece.


🔹 3. APAR (Authorized Program Analysis Report)

Não é exatamente uma correção.

  • É o registro do problema

  • Documento técnico da IBM

  • Normalmente leva a um PTF

👉 APAR explica, PTF corrige.


🔹 4. USERMOD

É a customização do cliente.

  • Criado pelo próprio site

  • Não vem da IBM

  • Usado para ajustes locais

📌 USERMOD é poder — e risco.


🧬 SYSMOD não vem sozinho

Um SYSMOD pode ter:

  • Pré-requisitos

  • Co-requisitos

  • Dependentes

  • Exclusões

Tudo isso é descrito nas MCS.

👉 SMP/E não aceita “jeitinho”.


🔁 SYSMOD e o fluxo SMP/E

Todo SYSMOD passa por:

1️⃣ RECEIVE
👉 Entra no controle do SMP/E

2️⃣ APPLY
👉 Vai para TARGET (executável)

3️⃣ ACCEPT
👉 Atualiza o DLIB (baseline)

📌 Pular etapa é pedir problema.


🚨 HOLD e ERROR: os avisos do SYSMOD

🔴 ++HOLD

Indica:

  • Conflitos conhecidos

  • Ações manuais necessárias

  • Restrições de ambiente

📌 Sempre leia o texto do HOLD.


🔥 ++ERROR

Indica:

  • Defeito conhecido no PTF

  • Correção parcial ou problemática

👉 Aplique só se souber o que está fazendo.


🧪 Exemplo prático de SYSMOD

++PTF(UJ12345). ++VER(Z038) FMID(HJES770). ++HOLD(SYSTEM) REASON(REQUIRES IPL).

📌 Tradução Bellacosa:

  • É um PTF

  • Serve para JES2

  • Exige IPL


📦 SYSMOD x FMID (confusão comum)

  • FMID → identifica o produto (ex: HJES770)

  • SYSMOD → mudança aplicada ao produto

👉 SYSMOD sempre aponta para um FMID.


🎓 Como aprender SYSMOD na prática

🧪 Laboratório essencial

  • SMP/E for z/OS Workshop

  • APPLY CHECK

  • Leitura de HOLDS

  • Análise de ERROR

📘 Leitura obrigatória

  • APARs

  • PTF cover letters

  • ++HOLD text

💡 Dica Bellacosa:

“Quem não lê o texto do PTF não sabe o que está instalando.”


🧠 Curiosidades Bellacosa

  • Um único SYSMOD pode alterar centenas de módulos

  • Um ++HOLD ignorado pode gerar outage

  • USERMOD mal feito é pesadelo em migração


🧾 Comentário final – Parte 2

SYSMOD não é só correção.
SYSMOD é contrato.
Quebrou o contrato, o SMP/E cobra.


📌 Próxima Parte da Série

👉 Parte 3 – MCS na prática: ++VER, ++HOLD, ++ERROR sem medo

segunda-feira, 2 de março de 2009

✏️ Capítulo 2 — Giz, Mimiógrafo e Destinos Impressos

 


📚 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 2 — Giz, Mimiógrafo e Destinos Impressos

Vim de um tempo em que mal aluno com fraco desempenho era reprovado mesmo — sem dó, piedade e sem discurso motivacional.

Mas eu era bom aluno, sempre me destaquei em todas as matérias, ops, quase todas, era abaixo da média em Educação Física, odiava os exercícios, ter que jogar bola, realmente era algo que não me dava prazer. O curioso é que fora a escola jogava vôlei e futebol normal, andava quilômetros em bicicleta, capinava quintais para ganhar uns trocos. O problema era a questão da aula mesmo... quero dizer não era preguiçoso, só não gostava mesmo, era um nerd, que vivia na biblioteca municipal fazendo pesquisas, numa era sem IA e Google para recuperar pontos em EF.

Passei pelos quatro anos do primário com sucesso, mantive boas notas no ginásio e alcancei a glória sendo um aluno brilhante e invejado e vi o colegial passar num piscar de olhos, nesta época já trabalhava então não foi o melhor alunos, mas estive no Top.

Foi ali que me formei técnico em Processamento de Dados, colegial-tecnico onde aprendiamos o suficiente para prestar o Vestibular, mas garantia uma profissão com melhor remuneração, que abriria as portas do mundo empresarial e me levaria, anos depois, aos corredores sagrados do mainframe.


Naquele tempo, informática ainda tinha cheiro de papel perfurado e fita magnética.
Falar em computador era falar em futuro — e eu queria estar lá, digitando linhas de destino no teclado verde-fósforo, não era um IBM Mainframe, mas sim um microcomputador de 8 bits da marca CP 500.

Participei do centro acadêmico no ginásio e no colegial — outros nomes, mesma essência: alunos que acreditavam poder melhorar o mundo começando pela escola.




Produzíamos jornalzinhos em mimiógrafo, ajudávamos em festas e eventos, organizávamos campeonatos e saraus.





Eram tempos simples, mas cheios de propósito e camaradagem.


Foram anos gratificantes, cheios de aventura, cheiro de álcool e papel úmido, onde cada professor era um farol e cada colega, um companheiro de travessia.


sexta-feira, 13 de fevereiro de 2009

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

quinta-feira, 12 de fevereiro de 2009

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

 

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 ManagerScrum Master
Gerencia tarefasAtua como coach
Controla planoProtege o time
Documenta riscosRemove impedimentos
Cobra prazosFomenta 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.