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 📚

 

Bellacosa Mainframe apresenta product vision com elevator pitch

🧠☕ Product Vision no Estilo Bellacosa Mainframe

Ou: por que até produto moderno precisa de disciplina de mainframe

---

🧭 Pergunta raiz (a.k.a. “JOB card do Produto”)

The most effective Product Vision format uses what methodology?
Resposta curta, direta e sem IF ELSE desnecessário:

👉 Elevator Speech (ou Elevator Pitch)

Agora segura esse commit, porque vamos explicar como um conceito de produto moderno conversa diretamente com a mentalidade do mainframe — com história, fofoca, easter eggs e aquele tempero “El Jefe” ☕💼.

---

🏛️ Origem & História (ou: nada nasce em microserviços)

🎤 Elevator Speech

O Elevator Speech nasce no mundo corporativo americano, décadas atrás, com uma premissa simples:

“Se você tivesse apenas o tempo de um elevador para convencer alguém importante, o que você diria?”

📦 Normalmente: 30 a 60 segundos
📌 Público: executivo, investidor, sponsor, board
🎯 Objetivo: clareza absoluta + impacto imediato

👉 No mundo de Product Vision, ele virou padrão porque:

• Força foco

• Elimina ruído

• Obriga o time a saber o que NÃO é o produto

📢 Mainframe feelings:
É o mesmo princípio de explicar um sistema core bancário em 3 frases antes da diretoria mandar “vamos para o próximo assunto”.

---

🧪 Comparando os formatos (como um bom JCL COMMENT)

❌ Laconic Speech

• Curto demais

• Soa vago

• Parece RACF mal documentado
  📉 “Não dá contexto, só slogan”

❌ Crisp Presentation

• Bom para slides

• Ruim para alinhar visão estratégica

• Vira PowerPoint bonito sem alma
  📉 “Muito SHOW, pouco JOB”

❌ Brief Report

• Denso

• Técnico

• Mata a inspiração
  📉 “É o SMF record do produto”

✅ Elevator Speech (O CAMPEÃO)

• Simples

• Direto

• Memorável

• Replicável pelo time inteiro
  📈 “Todo mundo consegue repetir no café”

---

🧩 Estrutura clássica do Elevator Speech (a “COPYBOOK” da Product Vision)

Modelo mais famoso (Geoffrey Moore):

For (target customer)
Who (statement of the need)
The (product name)
Is a (product category)
That (key benefit)
Unlike (primary competitor)
Our product (key differentiator)

📌 Isso é Product Vision executável, não poesia.

---

🧠 Exemplo prático (com cheiro de datacenter)

For grandes bancos brasileiros
Who precisam processar milhões de transações críticas por segundo
The CorePay Z
Is a plataforma de processamento financeiro
That garante alta disponibilidade, segurança e integridade dos dados
Unlike soluções distribuídas instáveis
Our product roda em IBM Z com confiabilidade de décadas

💥 Se o diretor entendeu isso, o produto vive.

---

🧨 Fofoca corporativa (porque Bellacosa conta bastidor)

👀 Muitas empresas:

• Dizem que têm Product Vision

• Mas na prática só têm roadmap de features

💣 Resultado?

• Produto sem identidade

• Squad puxando para lados diferentes

• “Retrabalho” (o famoso RESTART STEP=) eterno

📌 Times maduros sempre começam com Elevator Speech antes do Jira.

---

🥚 Easter Eggs (para os atentos)

• Elevator Speech ≈ Mensagem inicial de um dump

• Se não explica em 1 minuto, nem o operador vai entender

• Jeff Bezos proibiu PowerPoint → preferia narrativas curtas e claras

• Mainframe já fazia isso nos anos 70:

  “Este sistema liquida operações bancárias nacionais com consistência e disponibilidade 24x7”

👑 Isso é Product Vision raiz.

---

🧠 Comentário “El Jefe”

❝ Se você não consegue explicar seu produto em um elevador,
você não tem um produto — só um monte de código rodando. ❞

---

🧷 Dicas práticas (para aplicar amanhã)

✔️ Crie o Elevator Speech antes do backlog
✔️ Todo dev deveria saber recitar a visão
✔️ Se cada pessoa descreve diferente → ABEND de visão
✔️ Revise a Product Vision a cada grande mudança estratégica

---

🏁 Conclusão (RETURN CODE 0)

📌 A metodologia mais efetiva para Product Vision é o Elevator Speech, porque:

• Cria alinhamento

• Força clareza

• Evita desperdício

• Funciona do board ao data center

☕ E como diria o Bellacosa Mainframe:

Produto bom é aquele que até o mainframe entenderia.

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