Mostrar mensagens com a etiqueta estudo. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta estudo. Mostrar todas as mensagens

segunda-feira, 15 de abril de 2019

💾 Capítulo 3 — Entre o 3270 e o XT: o despertar do programador

 


💾 Capítulo 3 — Entre o 3270 e o XT: o despertar do programador

Série: Crônicas de um Office-Boy Mainframe

Entre uma ida ao banco e outra, eu já não era mais o mesmo.
O garoto que carregava pastas começou a carregar também uma curiosidade sem fim.
Naquela época, os computadores ainda tinham cheiro de tinta, poeira e novidade.
E bastava um terminal 3270 piscando na tela para que o coração batesse diferente.

O 3270 era o portal para o sistema central — o grande cérebro da empresa.
Eu via os analistas digitando comandos enigmáticos, telinhas cheias de números, mensagens que pareciam falar com outro mundo.
E pensava comigo:

“Como será que eles fazem isso acontecer?”


 

Foi então que o XT entrou de vez na minha história.
Aquele micro que chegou em uma caixa, e que ninguém sabia montar, agora estava em pleno funcionamento.
E o office-boy curioso virou seu “operador não-oficial”.

💡 Eu aprendia no instinto — sem curso, sem internet, sem manual.
Descobria as funções por tentativa e erro.
Comandos do MS-DOS, teclas de função, diretórios…
Era o nascimento do meu alfabeto digital.

Comecei a anotar tudo em um caderninho surrado:
DIR, COPY, DEL, FORMAT, CLS — cada comando era um pequeno feitiço.
O XT virou minha escola silenciosa.

Durante os intervalos, eu ficava observando o comportamento do sistema.
Quando dava erro, tentava entender o porquê.
Sem perceber, estava pensando como programador — ainda que o cargo dissesse “office-boy”.

Alguns colegas achavam estranho aquele garoto preferir o teclado à conversa.
Outros riam, dizendo que “computador era coisa de engenheiro”.
Mas algo dentro de mim dizia que aquele era o meu caminho.



⚙️ Foi ali, entre o 3270 e o XT, que despertei.
Descobri que máquinas podiam obedecer ideias, que lógica podia virar ação.
E que, no fundo, programar era uma forma de conversar com o invisível —
de transformar curiosidade em código, e código em futuro.



Anos depois, quando entrei no mundo do mainframe, percebi que tudo começou ali:
Naquele micro empoeirado da Avenida Paulista,
com um garoto da Zona Leste digitando seus primeiros comandos
sem saber que estava escrevendo, linha por linha, o roteiro da própria vida.



terça-feira, 3 de julho de 2012

📘 Mega City – Case Study Review (Completo)

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árioAbordagem Correta
Alta concordância + baixa complexidadeWaterfall
Baixa concordância + alta complexidadeAgile / Scrum
Trabalho contínuoKanban

📌 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 📚