Translate

Mostrar mensagens com a etiqueta Metodologias Ágeis. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Metodologias Ágeis. Mostrar todas as mensagens

sábado, 7 de maio de 2022

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como a Computação Evoluiu da Década de 1950 à Era dos Agentes de Inteligência Artificial

 

Bellacosa Mainframe e as ondas da informatica

☕ Um Café no Bellacosa Mainframe

As Grandes Ondas da Inovação

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como a Computação Evoluiu da Década de 1950 à Era dos Agentes de Inteligência Artificial

"Você não está apenas aprendendo COBOL. Está estudando uma profissão que sobreviveu a todas as revoluções da computação e continua sendo um dos pilares da transformação digital mundial."


Existe uma crença muito comum entre quem está começando na área de tecnologia.

A ideia de que a informática evolui substituindo tudo o que veio antes.

Mas basta entrar em um grande banco, uma companhia aérea, uma seguradora, uma bolsa de valores ou um órgão do governo para perceber que isso simplesmente não é verdade.

Na prática, a computação funciona como uma grande cidade.

Casas antigas continuam existindo ao lado de arranha-céus.

Ferrovias continuam transportando milhões de pessoas mesmo depois da invenção dos aviões.

Da mesma forma, um programa COBOL escrito há quarenta anos pode estar sendo acessado neste exato momento por um aplicativo de celular desenvolvido na semana passada.

Essa é uma das maiores lições que um Programador COBOL Padawan precisa aprender.

A história da informática não é uma sucessão de substituições.

É uma sequência de camadas de inovação.

Vamos fazer uma viagem década por década para entender como chegamos até a Inteligência Artificial Generativa.

Pegue seu café.

Nossa máquina do tempo está pronta.


Década de 1950

O nascimento da computação comercial

Depois da Segunda Guerra Mundial, computadores deixaram de ser apenas equipamentos militares e começaram a entrar nas empresas.

Eram gigantescos.

Salas inteiras.

Milhares de válvulas.

Consumo absurdo de energia.

Pouquíssima memória.

Programar significava literalmente controlar o hardware.

Não existiam sistemas operacionais modernos.

Muito menos interfaces gráficas.

Cada instrução era preciosa.

Os profissionais dessa época eram mais próximos de engenheiros eletrônicos do que dos desenvolvedores que conhecemos hoje.

A grande inovação

Pela primeira vez, máquinas começaram a executar processos administrativos.

Folha de pagamento.

Contabilidade.

Estoque.

Cálculos científicos.

Era o início da automação empresarial.


Década de 1960

A Era do COBOL e dos Sistemas Corporativos

Em 1959 nasce uma linguagem que mudaria para sempre a história da informática.

COBOL.

Seu objetivo era simples.

Permitir que computadores falassem a linguagem dos negócios.

Enquanto outras linguagens eram voltadas para matemática, COBOL foi criado para representar empresas.

Clientes.

Contas.

Salários.

Pagamentos.

Impostos.

Contratos.

Essa visão revolucionária fez surgir os primeiros sistemas corporativos de larga escala.

Foi nessa época que bancos começaram a informatizar contas correntes.

Companhias aéreas iniciaram sistemas de reservas.

Governos passaram a processar milhões de registros automaticamente.

O paradigma dominante

Programação Procedural.

O computador seguia uma sequência de instruções.

LER

VALIDAR

CALCULAR

GRAVAR

IMPRIMIR

Simples.

Determinístico.

Confiável.

Até hoje bilhões de transações seguem exatamente esse modelo.


Década de 1970

O nascimento dos Bancos de Dados

Os computadores já executavam programas.

Mas surgiu um novo problema.

Como armazenar milhões de informações?

Foi então que nasceram grandes tecnologias como:

  • IMS

  • VSAM

  • IDMS

  • primeiros bancos relacionais

O conceito de dado passou a ser tão importante quanto o programa.

Agora existiam profissionais especializados em modelagem.

Modelagem de dados tornou-se uma ciência.

Também nasceram

CICS

Monitores transacionais

Processamento online

Terminais espalhados pelo país inteiro

Imagine um caixa eletrônico.

Quando você consulta saldo hoje, está usando conceitos arquiteturais desenvolvidos nessa década.


Década de 1980

A Revolução do Computador Pessoal

Enquanto os mainframes cresciam nos Data Centers, outro fenômeno acontecia.

Os computadores chegaram às mesas das pessoas.

IBM PC.

Apple.

MS-DOS.

Windows.

Planilhas eletrônicas.

Editor de textos.

O computador deixou de ser exclusivo das grandes empresas.

Agora qualquer escritório podia automatizar tarefas.

Ao mesmo tempo surgiram redes locais.

As empresas começaram a conectar computadores.

A informática deixava de ser centralizada.


Década de 1990

A Revolução da Orientação a Objetos

Os sistemas estavam gigantescos.

Milhões de linhas de código.

Projetos difíceis de manter.

Foi então que surgiu uma nova maneira de pensar.

Em vez de funções...

Objetos.

Classes.

Herança.

Polimorfismo.

Encapsulamento.

Linguagens como Java, C++ e Delphi popularizaram essa filosofia.

Agora não programávamos apenas processos.

Modelávamos o mundo.

Cliente.

Pedido.

Conta.

Produto.

Tudo virou objeto.

A reutilização tornou-se uma prioridade.


Outra revolução ocorreu silenciosamente

Internet.

World Wide Web.

HTTP.

HTML.

Navegadores.

O software deixou de morar apenas dentro das empresas.

Agora podia atender o planeta inteiro.


Década de 2000

A Era da Web

Empresas descobriram que poderiam vender pela Internet.

Nasceram:

Amazon

Google

Wikipedia

Facebook

YouTube

Milhões de aplicações web.

Ao mesmo tempo surgiu outra preocupação.

Projetos estavam demorando anos.

Clientes mudavam de ideia durante o desenvolvimento.

Foi então que nasceu o Manifesto Ágil.


Agile

A mudança foi cultural.

Antes

Planejar tudo.

Depois desenvolver.

Agora

Planejar.

Construir.

Entregar.

Aprender.

Repetir.

Scrum.

Kanban.

XP.

Lean.

A velocidade tornou-se vantagem competitiva.


Década de 2010

Cloud Computing

Outra mudança gigantesca.

Antes.

Comprar servidores.

Instalar servidores.

Configurar servidores.

Agora.

Criar servidores em minutos.

AWS.

Azure.

Google Cloud.

IBM Cloud.

Virtualização tornou-se padrão.

Containers apareceram.

Docker.

Kubernetes.

OpenShift.

Tudo ficou automatizado.


DevOps

Desenvolvimento e Operação deixaram de ser departamentos separados.

Surgiram

CI

CD

Git

GitHub

Jenkins

Terraform

Ansible

Infrastructure as Code.

Agora o próprio código construía infraestrutura.


O Mainframe também mudou

Muita gente acredita que Mainframe ficou parado.

Na verdade aconteceu exatamente o contrário.

Surgiram

Zowe

z/OS Connect

APIs REST

JSON

Git para COBOL

VS Code

Ansible for IBM Z

OpenShift

COBOL passou a conversar naturalmente com aplicações modernas.


Década de 2020

Inteligência Artificial Generativa

Essa talvez seja a maior ruptura desde a criação da Internet.

Os computadores deixaram de apenas executar comandos.

Agora interpretam linguagem humana.

Escrevem código.

Geram documentos.

Resumem textos.

Produzem imagens.

Explicam conceitos.

Modelos gigantes como os LLMs passaram a compreender contexto.

Não apenas palavras.


RAG

Logo surgiu um problema.

Os modelos não conheciam os documentos internos das empresas.

Então nasceu o Retrieval Augmented Generation.

O modelo continua inteligente.

Mas consulta documentos corporativos antes de responder.

É exatamente como um funcionário experiente consultando manuais antes de tomar uma decisão.


MCP

Depois surgiu outra evolução.

Model Context Protocol.

Os modelos passaram a acessar ferramentas externas.

Bancos.

APIs.

ERP.

Mainframe.

Agora eles não apenas respondem.

Executam tarefas.


A Nova Era

Sistemas Multi-Agentes

Estamos entrando em uma nova arquitetura.

Em vez de um único modelo fazendo tudo.

Diversos agentes especializados colaboram.

Imagine uma empresa.

Existe:

Gerente Financeiro.

Advogado.

Auditor.

Analista.

Contador.

Todos especialistas.

Os sistemas modernos seguem exatamente essa lógica.

Um agente planeja.

Outro pesquisa.

Outro programa.

Outro testa.

Outro documenta.

Outro monitora.

É uma empresa digital trabalhando vinte e quatro horas por dia.


O padrão escondido

Existe algo extremamente interessante observando toda essa evolução.

Cada década aumenta o nível de abstração.

DécadaPensamento dominante
1950Hardware
1960Procedimentos
1970Dados
1980Computadores Pessoais
1990Objetos
2000Processos e Internet
2010Plataformas e DevOps
2020Conhecimento e IA

Perceba.

Não é apenas evolução tecnológica.

É evolução intelectual.


O que provavelmente veremos na década de 2030

Se observarmos o padrão histórico, uma hipótese plausível é que a próxima onda será a Orquestração Cognitiva. Em vez de programadores descrevendo passo a passo o comportamento de um sistema, equipes irão definir objetivos, restrições e políticas, enquanto ecossistemas de agentes coordenarão pessoas, aplicações legadas, serviços em nuvem e robôs de software.

Podemos esperar:

  • Agentes especializados cooperando em larga escala.

  • Sistemas capazes de negociar recursos entre si.

  • Interfaces conversacionais substituindo parte das telas tradicionais.

  • Engenharia de software cada vez mais orientada por intenção e governança.

  • Maior foco em segurança, explicabilidade e auditoria das decisões tomadas por IA.

Assim como COBOL não desapareceu com a chegada da Orientação a Objetos, é improvável que a IA substitua todas as tecnologias anteriores. Ela será mais uma camada sobre uma base construída ao longo de décadas.


A grande lição para um Programador COBOL Padawan

Muitos iniciantes perguntam:

"Vale a pena aprender COBOL em plena era da Inteligência Artificial?"

A pergunta correta é outra.

"Quem melhor para integrar Inteligência Artificial aos sistemas que movimentam bancos, seguradoras, bolsas de valores, companhias aéreas e governos?"

A resposta é clara.

Quem conhece esses sistemas.

Quem entende regras de negócio.

Quem domina arquitetura corporativa.

Quem sabe como funciona uma transação CICS.

Quem compreende DB2.

Quem conhece JCL.

Quem entende segurança.

Quem conhece processamento batch.

Quem domina integração.

Esse profissional é justamente o Programador Mainframe.


O Café termina...

Se olharmos para trás, veremos válvulas, cartões perfurados, COBOL, bancos de dados, PCs, Internet, orientação a objetos, computação em nuvem, DevOps e Inteligência Artificial.

Cada geração acreditou estar vivendo a maior revolução da história.

E, de certa forma, estava.

Mas existe uma verdade que atravessa todas essas décadas:

A tecnologia muda. Os princípios permanecem.

Organizar informações.

Automatizar processos.

Resolver problemas.

Gerar valor para pessoas e organizações.

É exatamente isso que um programa COBOL faz desde 1959.

É exatamente isso que um sistema de IA faz hoje.

A diferença está nas ferramentas.

A missão continua a mesma.

E talvez essa seja a maior lição desta viagem pela história da computação: quem compreende os fundamentos não fica preso ao passado; torna-se capaz de construir o futuro. Afinal, as grandes ondas de inovação não apagam as anteriores — elas se apoiam nelas. É por isso que, em pleno século XXI, o COBOL continua processando bilhões de transações diariamente enquanto conversa com APIs, microsserviços e agentes de Inteligência Artificial. A próxima revolução já começou, e os Programadores COBOL Padawans têm um lugar privilegiado para participar dela.


sábado, 5 de setembro de 2009

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


👉 Resumo para ir mais longe

Durante muitos anos, o Microsoft Project (MS Project) foi uma das principais ferramentas de gerenciamento de projetos do mercado. Seu foco em cronogramas detalhados, dependências complexas, diagramas de Gantt e planejamento de longo prazo refletia a realidade de projetos conduzidos por metodologias tradicionais, especialmente o modelo cascata (waterfall).

Com o crescimento das metodologias ágeis, muitas empresas passaram a enxergar limitações nesse modelo. Em ambientes onde requisitos mudam constantemente, criar planejamentos extremamente detalhados para meses ou anos à frente tornou-se cada vez mais difícil. O problema não era necessariamente a ferramenta, mas a mudança na forma como os projetos passaram a ser conduzidos.

Frameworks como Scrum, Kanban e práticas de Agile priorizam adaptação contínua, entregas frequentes e revisão constante das prioridades. Nesse contexto, ferramentas mais leves e colaborativas, como Jira, Trello, Azure DevOps e outras plataformas digitais, ganharam espaço por facilitarem o gerenciamento dinâmico de backlogs, sprints e fluxos de trabalho.

Mesmo assim, o MS Project não desapareceu. Ele continua sendo amplamente utilizado em áreas como engenharia, construção civil, infraestrutura, projetos governamentais e iniciativas que exigem forte controle de cronograma e recursos.

A grande transformação ocorreu na cultura de gestão. O foco deixou de ser apenas prever todo o futuro do projeto e passou a incluir adaptação rápida, colaboração entre equipes e resposta eficiente às mudanças constantes do mercado.


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.



📌 Resumo para ir mais longe

 Um dos princípios mais importantes do movimento Agile é reconhecer uma realidade que muitos projetos tentam ignorar: é impossível planejar tudo com precisão absoluta. Mercados mudam, clientes alteram prioridades, tecnologias evoluem e novos desafios surgem constantemente. Por isso, metodologias ágeis não eliminam o planejamento; elas transformam o planejamento em um processo contínuo.

Durante décadas, muitas organizações acreditaram que documentos extensos e cronogramas detalhados seriam suficientes para prever todo o futuro de um projeto. Na prática, porém, quanto maior o prazo, maior a probabilidade de mudanças. O Agile surgiu justamente para lidar com essa incerteza de forma estruturada.

Em vez de definir todos os detalhes antecipadamente, equipes ágeis trabalham com objetivos claros e ciclos curtos de entrega. A cada sprint, novas informações são analisadas, permitindo ajustes rápidos e redução de riscos. O aprendizado contínuo passa a ser parte integrante do processo.

Outro conceito fundamental é o feedback constante. Clientes, usuários e equipes colaboram para identificar melhorias antes que pequenos problemas se transformem em grandes falhas. Essa abordagem aumenta a capacidade de adaptação e melhora a qualidade das entregas.

O verdadeiro Agile não promete prever o futuro. Ele oferece mecanismos para responder às mudanças de maneira eficiente, permitindo que pessoas, equipes e organizações evoluam continuamente em um ambiente cada vez mais dinâmico e imprevisível.

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.

📦Resumo para ir mais longe

Implementar Agile na prática vai muito além de adotar cerimônias ou ferramentas. O verdadeiro diferencial das metodologias ágeis está na combinação equilibrada entre planejamento, pessoas e resultados. Embora o Agile valorize a adaptação às mudanças, isso não significa ausência de planejamento. Pelo contrário, o planejamento acontece de forma contínua, permitindo ajustes rápidos conforme surgem novas necessidades do negócio.

Nesse contexto, as pessoas ocupam papel central. Equipes multidisciplinares, comunicação transparente e colaboração constante tornam-se elementos fundamentais para o sucesso dos projetos. Frameworks como Scrum incentivam a participação ativa de todos os envolvidos, promovendo responsabilidade compartilhada e melhoria contínua.

Outro aspecto importante é o foco nos resultados. Em vez de medir sucesso apenas pelo cumprimento de cronogramas, o Agile busca entregar valor real ao cliente por meio de incrementos frequentes e funcionais. Cada sprint representa uma oportunidade de aprendizado, validação e refinamento das prioridades.

A prática ágil também estimula a identificação rápida de riscos, gargalos e oportunidades de melhoria. Reuniões como Daily Scrum, Sprint Review e Retrospective ajudam a manter alinhamento e transparência ao longo do projeto.

Quando bem aplicado, o Agile cria ambientes mais adaptáveis, produtivos e inovadores, permitindo que organizações respondam com maior velocidade às mudanças do mercado sem abrir mão da qualidade e da satisfação dos clientes.

 

quarta-feira, 7 de janeiro de 2009

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


💾 Resumo Para ir mais longe

A evolução do desenvolvimento de software pode ser comparada à transição do tradicional batch noturno dos mainframes para os modernos ambientes de entrega contínua. Durante décadas, projetos eram conduzidos por modelos rígidos, com longos ciclos de análise, desenvolvimento, testes e implantação. Embora eficientes para sua época, essas abordagens tinham dificuldades para lidar com mudanças frequentes de requisitos.

Foi nesse cenário que surgiram os conceitos de Agile e, posteriormente, o framework Scrum. Baseados no Manifesto Ágil de 2001, esses métodos priorizam colaboração, adaptação, entregas frequentes e foco no valor para o cliente. Em vez de esperar meses ou anos por uma versão completa, as equipes passam a trabalhar em ciclos curtos chamados sprints, entregando incrementos funcionais do produto regularmente.

O Scrum organiza o trabalho por meio de elementos como Product Backlog, Sprint Backlog, Daily Meeting, Sprint Review e Retrospective, promovendo transparência e melhoria contínua. Curiosamente, muitos profissionais de mainframe percebem que conceitos como planejamento rigoroso, controle de mudanças e confiabilidade operacional continuam relevantes mesmo no universo ágil.

Hoje, Agile e Scrum são amplamente utilizados em empresas de todos os portes, integrando-se a práticas como DevOps, automação e cloud computing. O objetivo permanece o mesmo: entregar software de qualidade com rapidez, eficiência e capacidade de adaptação às necessidades do negócio.