Bellacosa Mainframe estuda o case Mega City

---

📘 Mega City – Case Study Review (Completo)

🎯 Visão Geral do Projeto

O projeto Mega City Commuter Application tem como objetivo desenvolver um aplicativo para apoiar os deslocamentos urbanos, integrando dados do Department of Transportation (DOT) para melhorar a experiência dos usuários.

🎯 Objetivo Principal do App

✅ Allow commuters to determine optimal routes

❌ Não é:

• Previsão do tempo

• Horários de voo

• Sistema ferroviário isolado

---

🧭 Principais Artefatos do Projeto

1️⃣ Agile Project Charter

Finalidade:

• Define objetivos

• Alinha negócio + tecnologia

• Explica o porquê do projeto

📌 Pergunta típica de prova:

“Which document ensures objectives are clear and aligns business and technical teams?”
✅ Agile Project Charter

---

2️⃣ Product Roadmap

Finalidade:

• Visão visual e de alto nível

• Organiza entregáveis por fases e meses

• Indica quando o produto será testado e lançado

📅 Data de lançamento do App (prova):
✅ October

📌 Responsável pela criação:
✅ Project Manager

---

3️⃣ Working Agreement

Finalidade:

• Define regras de convivência

• Cria transparência, expectativas e objetivos comuns

• Focado em como o time trabalha

👤 Quem lidera a criação:
✅ Scrum Master – Anant Kumar

📌 Nunca é imposto, sempre criado pelo time

---

4️⃣ Product Backlog

Finalidade:

• Repositório de todos os User Stories

• Base para planejamento de Sprints

👤 Responsável:
✅ Product Owner – Anant Kumar

📌 Dica de prova:

Quem gerencia e prioriza = Product Owner

---

👥 Papéis-Chave no Case Mega City

🔹 Product Owner

• Define o que será construído

• Gerencia o Product Backlog

✅ Anant Kumar

---

🔹 Scrum Master

• Facilita reuniões

• Remove impedimentos

• Garante adesão ao Scrum

• Lidera o Working Agreement

✅ Anant Kumar (em perguntas específicas do curso)

---

🔹 Subject Matter Expert (SME)

Responsável por garantir que requisitos técnicos e funcionais sejam atendidos.

📍 SME do DOT:
✅ Hiroshi Tanaka

📌 Sempre associado a:

• Dados do DOT

• Funcionalidade específica do domínio

---

📊 Stacey Matrix (Análise Crítica)

📌 Parâmetros Avaliados:

• Level of Agreement

• Technology Complexity

---

🧠 Interpretação para prova

Cenário	Abordagem Correta
Alta concordância + baixa complexidade	Waterfall
Baixa concordância + alta complexidade	✅ Agile / Scrum
Trabalho contínuo	Kanban

📌 No Mega City:

Low agreement + High complexity
✅ Agile / Scrum

---

🧩 Resumo Rápido (Cola de Prova 📝)

• Objetivo do App: Rotas ideais para commuters

• Roadmap: Visual + meses + lançamento em October

• Charter: Alinha negócio e tecnologia

• Working Agreement: Criado pelo time, liderado pelo Scrum Master

• Product Backlog: Responsabilidade do Product Owner

• SME DOT: Hiroshi Tanaka

• Stacey Analysis: Low agreement + High complexity → Agile/Scrum

---

Se quiser, no próximo passo posso:

• Criar um quadro comparativo (tabela) só com quem faz o quê

• Simular questões de prova estilo Coursera

• Ou montar um resumo em inglês, pronto para revisão final 📚

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

 

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.

 

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.

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