Bellacosa Mainframe apresenta o scrum e o waterfall

☕ Um Café no Bellacosa Mainframe

Phileas Fogg Entra no CPD — A Volta ao Mundo em 80 Sprints e o Dia em que Descobriu que Scrum e Waterfall Podiam Viajar no Mesmo Trem

Ou: como Waterfall, Scrum, modelos híbridos, Stage Gates, DevOps, automação, governança, feedback, riscos e um pouco de COBOL podem atravessar o mesmo projeto — e por que Passepartout descobriu que o maior atraso nunca estava no trem, mas no handoff esperando aprovação

---

Prólogo — Uma aposta no Reform Club e um projeto com data de produção

Londres, 1872.

Phileas Fogg entra no Reform Club, consulta o relógio e afirma com a serenidade de quem nunca recebeu um S0C7 às 16h58 de sexta-feira:

— É perfeitamente possível dar a volta ao mundo em oitenta dias.

Se Júlio Verne tivesse trabalhado algumas décadas em Tecnologia da Informação, provavelmente alguém responderia:

— Depende. O Architecture Board já aprovou?

Passepartout consultaria o Jira.

— Monsieur Fogg, a Índia está BLOCKED. O túnel ferroviário não ficou pronto.

Fogg não se abalaria:

— Então mudaremos o plano.

— Mas isso não estava no escopo!

— Passepartout, nosso objetivo é chegar a Londres. Não cumprir o PowerPoint.

E talvez tenhamos acabado de explicar boa parte da diferença entre seguir um plano e administrar um projeto.

Nossa viagem de hoje começa com uma pergunta aparentemente simples:

Scrum e Waterfall podem trabalhar juntos?

Podem.

Aliás, em grandes organizações, frequentemente já trabalham.

A questão mais interessante é outra:

Eles trabalham juntos porque alguém projetou conscientemente essa combinação ou porque cada departamento resolveu trabalhar de um jeito diferente?

Essa diferença separa um modelo híbrido intencional de um Frankenstein metodológico capaz de possuir todos os documentos do Waterfall, todas as reuniões do Scrum e nenhuma das vantagens dos dois.

Pegue seu café.

O trem parte exatamente às 20h45.

Fogg não tolera atrasos.

---

1. Primeira parada: afinal, o que é Waterfall?

Antes de transformar Waterfall no vilão da história, precisamos entendê-lo.

O modelo tradicional imagina o projeto aproximadamente assim:

REQUISITOS
    ↓
ANÁLISE
    ↓
DESIGN
    ↓
DESENVOLVIMENTO
    ↓
TESTES
    ↓
IMPLANTAÇÃO
    ↓
MANUTENÇÃO

Existe uma forte preocupação em compreender e planejar o trabalho antecipadamente.

Para nosso iniciante COBOL, imagine que o banco peça:

Criar um sistema de cálculo de juros para determinado produto financeiro.

Num processo bastante tradicional, poderíamos primeiro documentar as regras, depois projetar arquivos e tabelas, escrever programas COBOL, testar, homologar e finalmente implantar.

Waterfall possui vantagens quando o problema é relativamente conhecido e quando alterações tardias custam caro.

E isso não acontece apenas em software.

Imagine Phileas Fogg chegando ao porto e dizendo:

— Vamos alterar o casco do navio durante a travessia.

O capitão provavelmente sugeriria que ele bebesse menos conhaque no Reform Club.

Algumas decisões precisam realmente acontecer antecipadamente.

Infraestrutura física, hardware, contratos, regulamentações, certificações e determinadas arquiteturas possuem essa característica.

Portanto:

Waterfall ≠ burrice
Waterfall ≠ tecnologia antiga
Waterfall ≠ automaticamente ruim

Ele é simplesmente uma maneira de administrar trabalho que favorece planejamento, sequência e previsibilidade.

O problema surge quando fingimos conhecer antecipadamente aquilo que ainda não conhecemos.

---

2. Passepartout conhece Scrum

Durante a viagem, Fogg possui um plano.

Mas o mundo não leu o plano.

Trem atrasou?

Adapte.

Navio não está disponível?

Procure outro.

A ferrovia não foi concluída?

Encontre outra solução.

O objetivo permanece.

A execução muda.

Existe aí uma analogia maravilhosa com Agile.

Scrum trabalha em ciclos curtos:

PRODUCT BACKLOG
      ↓
SPRINT PLANNING
      ↓
SPRINT
      ↓
INCREMENTO
      ↓
SPRINT REVIEW
      ↓
FEEDBACK
      ↓
RETROSPECTIVE
      ↓
PRÓXIMO SPRINT

A ideia não é simplesmente:

“Vamos programar mais rápido.”

Esse é um erro comum.

A grande vantagem é:

vamos diminuir o tempo entre fazer alguma coisa e descobrir se aquilo fazia sentido.

Isso é completamente diferente.

---

3. O usuário frequentemente não sabe exatamente o que quer

Esse é um segredo que todo programador descobre cedo ou tarde.

O usuário pede:

— Quero uma consulta de clientes.

Você cria:

       ACCEPT WS-COD-CLIENTE.

       EXEC SQL
          SELECT NOME
            INTO :WS-NOME
            FROM CLIENTE
           WHERE COD_CLIENTE = :WS-COD-CLIENTE
       END-EXEC.

Você demonstra.

Ele responde:

— Excelente! Mas precisamos pesquisar pelo CPF também.

Você implementa.

Nova demonstração.

— Ah... seria maravilhoso mostrar os contratos.

Depois aparece Jurídico:

— Esse campo não pode ser exibido.

Depois Segurança:

— Precisamos mascarar aquele dado.

Depois Produção:

— Essa consulta está fazendo table scan.

😂

O requisito não necessariamente estava “errado”.

O conhecimento sobre o problema evoluiu.

Scrum tenta transformar descoberta em parte natural do desenvolvimento.

---

4. Fogg descobre o Hybrid

Agora imagine algo interessante.

Phileas Fogg possui uma restrição absolutamente rígida:

80 DIAS

Mas sua execução precisa ser extremamente adaptável.

É quase nossa metáfora perfeita.

No projeto corporativo podemos ter:

DATA REGULATÓRIA
ORÇAMENTO
CONTRATO
ARQUITETURA CORPORATIVA
POLÍTICAS DE SEGURANÇA
AUDITORIA
JANELA DE PRODUÇÃO

Esses elementos podem exigir planejamento.

Enquanto desenvolvimento possui:

BACKLOG
SPRINTS
PROTÓTIPOS
FEEDBACK
PRIORIZAÇÃO
EXPERIMENTAÇÃO

Nasce o modelo híbrido:

              PROJETO
                 │
       ┌─────────┴─────────┐
       │                   │
   WATERFALL             SCRUM
       │                   │
   estrutura             adaptação
   orçamento             backlog
   milestones            sprint
   contratos             review
   gates                 feedback
       │                   │
       └────── HYBRID ─────┘

Não estamos necessariamente escolhendo um vencedor.

Estamos perguntando:

Qual problema cada abordagem precisa resolver?

---

5. Water-Scrum-Fall — Londres, Índia e Londres novamente

Uma combinação bastante conhecida pode ser representada assim:

WATERFALL
    ↓
Planejamento
Budget
Arquitetura
Contratos
    ↓
┌─────────────────┐
│      SCRUM      │
│ Sprint 1        │
│ Sprint 2        │
│ Sprint 3        │
│ Sprint 4        │
└─────────────────┘
    ↓
WATERFALL
    ↓
Homologação
Change
Aprovações
Deployment

Ou seja:

Water → Scrum → Fall.

O projeto começa bastante estruturado, desenvolve iterativamente e termina novamente em processos controlados.

Quem trabalha em grandes empresas provavelmente já encontrou algo semelhante mesmo sem usar esse nome.

O time passa semanas falando:

Sprint! Backlog! Story! Velocity!

Até chegar o momento da implantação.

Surge então um personagem misterioso usando sobretudo e carregando uma prancheta:

— Número da Change?

Silêncio.

— Aprovação de Segurança?

Silêncio.

— Plano de rollback?

Mais silêncio.

O Agile acabou de encontrar o fiscal Fix.

---

6. Easter egg mainframe nº 1 — produção possui RACF

Nosso programador COBOL iniciante precisa aprender cedo:

Agilidade não significa fazer qualquer coisa em produção.

Você pode desenvolver iterativamente.

Pode automatizar testes.

Pode entregar várias vezes por dia em determinados ambientes.

Mas sistemas críticos possuem controles por uma razão.

No z/OS, podemos encontrar mecanismos envolvendo segurança, auditoria, separação de funções e processos de mudança.

Portanto a questão madura não é:

“Como remover todos os controles?”

É:

“Como manter os controles necessários eliminando o desperdício desnecessário?”

Essa distinção é enorme.

---

7. Scrum dentro de Waterfall

Outra parada da nossa viagem.

Imagine um grande programa de modernização:

MODERNIZAÇÃO DO SISTEMA
│
├── Arquitetura ........ tradicional
├── Infraestrutura ..... tradicional
├── Compliance ......... gates
│
├── COBOL Team ......... Scrum
├── API Team ........... Scrum
├── Front-end Team ..... Scrum
│
└── Produção ........... processo controlado

Não existe lei universal dizendo que todos precisam trabalhar exatamente da mesma maneira.

Um departamento responsável por adquirir hardware pode ter horizontes e dependências completamente diferentes do time construindo uma interface.

O erro é exigir uniformidade metodológica simplesmente porque ela fica bonita na apresentação executiva.

---

8. Stage Gates — os postos de fronteira da viagem

Phileas Fogg atravessa fronteiras.

Nos projetos corporativos também existem fronteiras.

Chamamos algumas delas de gates.

Por exemplo:

GATE 0
Business Case
    ↓
GATE 1
Architecture Approval
    ↓
SPRINTS
    ↓
GATE 2
Security Review
    ↓
SPRINTS
    ↓
GATE 3
UAT
    ↓
GATE 4
Production

O gate pergunta:

“Estamos autorizados a continuar?”

Scrum pergunta:

“Qual é a coisa mais importante que devemos construir agora?”

São perguntas diferentes.

E justamente por isso podem coexistir.

---

9. Times paralelos — cada um usando um transporte

Na viagem de Fogg não existe um único meio de transporte.

Há trem, navio e outras soluções muito mais... criativas.

Num grande projeto acontece algo semelhante:

COBOL/CICS TEAM
      ↓
    Scrum

API TEAM
      ↓
    Scrum

INFRASTRUCTURE
      ↓
 planejamento

SECURITY
      ↓
 gates

FORNECEDOR
      ↓
 milestones

OPERATIONS
      ↓
 processos operacionais

Isso parece ótimo até descobrirmos um problema.

Dependências.

O time COBOL termina sua funcionalidade.

Mas precisa de infraestrutura.

Infraestrutura aguarda Network.

Network aguarda Security.

Security aguarda documentação.

Documentação aguarda Architecture.

E Architecture está esperando uma reunião na próxima terça-feira.

Resultado:

STATUS: BLOCKED

O código demorou dois dias.

A entrega levou três semanas.

---

10. Easter egg nº 2 — JES2 já conhecia filas

Quem trabalha com mainframe olha para isso e pensa:

— Já vi esse filme.

JOB
 ↓
QUEUE
 ↓
EXECUTION
 ↓
OUTPUT

Filas importam.

E projetos também possuem filas invisíveis.

Existe o tempo de trabalho e existe o tempo de espera.

Imagine:

Análise ................ 4 horas
Espera aprovação ....... 4 dias
Desenvolvimento ........ 2 dias
Espera ambiente ........ 6 dias
Teste .................. 1 dia
Espera Change .......... 5 dias

Se você otimizar o desenvolvimento em 30%, talvez quase nada aconteça no lead time total.

A grande descoberta é:

muitos projetos não são lentos porque programadores programam lentamente; são lentos porque trabalho pronto passa tempo demais esperando.

---

11. Predictability — cuidado com o mapa

Fogg possui horários de trens e navios.

Mas horário não é realidade.

O mesmo vale para nosso glorioso Gantt Chart.

Uma organização pode mostrar:

Projeto: 24 meses
Milestones: 137
Tasks: 4.281

Isso parece extremamente preciso.

Não significa necessariamente que seja previsível.

Existe uma diferença fundamental:

PRECISÃO ≠ EXATIDÃO

Dizer:

“Terminaremos em 17 de março às 14h35.”

é muito preciso.

Pode continuar completamente errado.

Uma abordagem mais madura reconhece horizontes diferentes de certeza:

12 meses → direção estratégica
 6 meses → grandes entregas
 3 meses → planejamento mais concreto
 1 mês   → maior detalhamento
 2 semanas → execução detalhada

Quanto mais distante o futuro, maior a incerteza.

O mapa deve admitir isso.

---

12. Flexibilidade — trocar o trem sem trocar o destino

Aqui está uma bela lição de A Volta ao Mundo em 80 Dias.

O objetivo não é usar determinado trem.

O objetivo é completar a viagem.

Da mesma maneira, o objetivo do projeto não deveria ser:

“executar perfeitamente o plano elaborado nove meses atrás.”

Deveria ser:

produzir o resultado necessário dentro das restrições relevantes.

Se aprendemos alguma coisa nova, o backlog pode mudar.

DESCOBERTA
    ↓
BACKLOG
    ↓
PRIORIZAÇÃO
    ↓
SPRINT
    ↓
REVIEW

Isso é adaptação controlada.

Não caos.

---

13. Risk Management — envie Passepartout primeiro

Existe uma ideia particularmente poderosa em desenvolvimento iterativo:

testar cedo as hipóteses perigosas.

Imagine uma modernização:

COBOL
  ↓
CICS
  ↓
z/OS Connect
  ↓
REST
  ↓
Cloud

No PowerPoint tudo funciona.

É impressionante como arquiteturas funcionam maravilhosamente dentro do PowerPoint.

Então construímos.

Aparecem:

LATÊNCIA
TIMEOUT
CERTIFICADOS
AUTENTICAÇÃO
FIREWALL
VOLUME
SERIALIZAÇÃO
RATE LIMIT
PERFORMANCE

Em vez de descobrir tudo isso no final, construa cedo uma pequena fatia vertical:

Programa COBOL
      ↓
CICS
      ↓
API
      ↓
Consumidor

Talvez processe somente uma operação.

Mas terá respondido perguntas arquiteturais valiosas.

Um pequeno experimento pode eliminar um grande risco.

---

14. Stakeholders — não desapareça por 18 meses

Uma das caricaturas mais perigosas do desenvolvimento tradicional é:

Usuário
  ↓
Requisitos
  ↓
18 meses de silêncio
  ↓
Sistema
  ↓
Usuário:
"Mas eu não pedi isso!"

Scrum reduz essa distância:

SPRINT
 ↓
DEMO
 ↓
FEEDBACK
 ↓
AJUSTE
 ↓
SPRINT

O verdadeiro benefício não é fazer mais reuniões.

É reduzir o tempo entre erro e descoberta do erro.

Quanto antes descobrimos uma premissa incorreta, menor tende a ser a quantidade de software construída sobre ela.

---

15. Culture Clash — Fogg encontra duas tribos

Aqui mora um dos maiores perigos do Hybrid.

A cultura Waterfall tende a perguntar:

Estamos seguindo o plano?

A cultura Agile tende a perguntar:

Ainda estamos construindo a coisa certa?

As duas perguntas são importantes.

Mas imagine uma empresa anunciando:

AGORA SOMOS AGILE!

Ela instala Jira.

Cria Scrum Masters.

Faz Daily.

Usa Story Points.

Mas mantém:

Escopo fixo
Prazo fixo
Budget fixo
Arquitetura fixa
Prioridades fixas
Aprovações centralizadas

Parabéns.

Você pode ter inventado:

Waterfall usando camiseta de Scrum.

---

16. O pior híbrido possível

Existe uma maneira especialmente cruel de implementar Hybrid:

pegar todos os controles do Waterfall e adicionar todas as cerimônias do Scrum.

Agora o desenvolvedor precisa:

• atualizar o Gantt;

• atualizar Jira;

• participar da Daily;

• preencher status semanal;

• participar da Planning;

• preencher documentação;

• fazer Review;

• atualizar planilha do PMO;

• fazer Retrospective;

• preparar slides executivos.

Em algum momento ele pergunta:

— Quando programamos?

Esse é o chamado imposto metodológico.

Todo processo possui custo.

A pergunta é se esse custo produz valor.

---

17. Handoffs — o verdadeiro Inspetor Fix

Em Júlio Verne, o Inspetor Fix persegue Fogg pelo mundo.

No projeto corporativo, nosso Fix pode ser o handoff.

BUSINESS
   ↓
ANALYSIS
   ↓
ARCHITECTURE
   ↓
DEVELOPMENT
   ↓
TEST
   ↓
SECURITY
   ↓
OPERATIONS

Cada seta pode representar:

fila
espera
reunião
ticket
aprovação
retrabalho

Portanto, quando alguém disser:

“Precisamos aumentar a produtividade dos desenvolvedores.”

pergunte primeiro:

“Quanto tempo o trabalho passa parado entre departamentos?”

Essa pergunta pode ser muito mais valiosa.

---

18. Defina contratos entre equipes

Uma excelente prática para modelos híbridos é transformar dependências vagas em interfaces claras.

Não escreva apenas:

Team A → Team B

Defina:

O QUE será entregue?
QUEM entrega?
QUEM recebe?
QUANDO?
EM QUAL FORMATO?
QUAL O CRITÉRIO DE ACEITE?
QUAL O SLA?
QUAIS AS DEPENDÊNCIAS?

É quase uma API organizacional.

Se APIs precisam de contratos, equipes também se beneficiam deles.

---

19. DevOps embarca no navio

Aqui nossa história ganha outro personagem.

Porque discutir somente Scrum versus Waterfall é insuficiente.

Scrum ajuda muito no ciclo de desenvolvimento e aprendizado.

DevOps olha para outro problema:

CODE
 ↓
BUILD
 ↓
TEST
 ↓
PACKAGE
 ↓
DEPLOY
 ↓
OPERATE
 ↓
OBSERVE

O objetivo é melhorar o fluxo entre desenvolvimento e operação.

Num ambiente moderno, inclusive mainframe, podemos automatizar boa parte disso.

Developer
   ↓
Git
   ↓
Build
   ↓
Unit Test
   ↓
Static Analysis
   ↓
Security Checks
   ↓
Package
   ↓
Deploy
   ↓
Integration Test
   ↓
Evidence

E chegamos a uma conclusão extremamente importante:

controle e velocidade não são necessariamente inimigos.

---

20. Compliance como código

Imagine que auditoria exija evidências de testes.

Modelo manual:

executa teste
 ↓
captura evidência
 ↓
preenche documento
 ↓
envia e-mail
 ↓
alguém arquiva

Agora imagine pipeline produzindo automaticamente:

BUILD ID
COMMIT
TEST RESULT
TIMESTAMP
APPROVAL
ARTIFACT VERSION
DEPLOYMENT RESULT

A automação pode aumentar simultaneamente:

velocidade + rastreabilidade + repetibilidade + controle.

Isso é extremamente importante em ambientes regulados.

O objetivo não precisa ser remover o gate.

Pode ser automatizar tudo aquilo que existe antes do gate.

---

21. Hybrid intencional versus Hybrid acidental

Essa distinção merece ficar pendurada na parede do CPD.

Hybrid intencional

A organização conclui:

Budget precisa de planejamento.
Compliance precisa de gates.
Desenvolvimento precisa de iteração.
Produção precisa de controle.
Feedback precisa ser rápido.

Então desenha conscientemente o sistema.

Excelente.

Hybrid acidental

A empresa cresceu durante décadas:

PMO ............. Waterfall
Development ..... Scrum
Operations ...... ITIL
Security ........ Gates
Finance ......... orçamento anual
Vendor .......... milestones

Ninguém projetou o fluxo completo.

Cada pedaço funciona isoladamente.

O conjunto parece a bagagem de Passepartout depois de atravessar três continentes.

Isso também é Hybrid.

Só que por acidente.

---

22. Easter egg nº 3 — o PERFORM RESPONSABILIDADE

Outro problema aparece quando misturamos estruturas.

Agora temos:

Project Manager
Product Owner
Scrum Master
Delivery Manager
Program Manager
Architect
Tech Lead
Business Analyst

Pergunta simples:

— Quem decide?

Silêncio.

Podemos representar em COBOL:

       PERFORM RESPONSABILIDADE
          THRU ALGUEM-DEVE-SABER.

😂

Definir papéis é absolutamente essencial.

Quem prioriza?

Quem controla orçamento?

Quem aceita?

Quem aprova arquitetura?

Quem responde pelo prazo?

Quem remove impedimentos?

Se duas pessoas acham que possuem a mesma autoridade, teremos conflito.

Se nenhuma acha que possui, teremos paralisia.

---

23. O segredo que nenhum framework gosta de admitir

Agora chegamos à grande pergunta que iniciou nossa conversa:

E se a “melhor metodologia” estiver escondendo o maior defeito do projeto?

Projeto atrasou.

— Vamos adotar Scrum!

Continua atrasado.

— Precisamos de mais governança!

Continua.

— Vamos fazer Hybrid!

Continua.

Talvez o problema seja:

arquitetura ruim
dívida técnica
ambientes instáveis
dependências excessivas
fornecedor atrasado
decisões lentas
requisitos contraditórios
testes manuais
falta de pessoas
governança inútil
liderança indecisa

Nenhum framework transforma magicamente problemas estruturais em produtividade.

Você pode reorganizar as cadeiras do navio.

O motor continuará quebrado.

---

24. Exemplo completo — a volta ao mundo de um programa COBOL

Vamos acompanhar uma funcionalidade.

O banco precisa disponibilizar uma operação COBOL/CICS através de API.

Etapa 1 — objetivo macro

Definimos:

prazo
budget
segurança
arquitetura
compliance

Aqui planejamento tradicional pode fazer sentido.

Etapa 2 — arquitetura

Consumer
   ↓
REST API
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Etapa 3 — backlog

Transformamos a implementação em itens menores.

Story 1 — consultar cliente
Story 2 — autenticação
Story 3 — consultar contratos
Story 4 — tratamento de erros
Story 5 — observabilidade

Etapa 4 — Sprints

Implementamos e demonstramos progressivamente.

Etapa 5 — integração contínua

Cada alteração dispara processos automatizados.

Etapa 6 — gates

Segurança e compliance verificam requisitos necessários.

Etapa 7 — homologação

Usuários validam comportamento.

Etapa 8 — implantação

Change aprovada, artefato identificado, rollback preparado.

Etapa 9 — observabilidade

Depois de produção medimos:

latência
throughput
erros
CPU
consumo
timeouts
disponibilidade

Perceba:

não precisamos escolher entre controle e aprendizado.

Precisamos projetar ambos.

---

25. A matriz de Fogg para escolher uma abordagem

Antes de perguntar “Scrum ou Waterfall?”, faça cinco perguntas.

1. O que sabemos?

Quanto maior a certeza, mais planejamento detalhado pode fazer sentido.

2. O que ainda precisamos descobrir?

Quanto maior a incerteza, mais úteis são experimentação e ciclos curtos.

3. Quais decisões são caras de reverter?

Construir infraestrutura é diferente de alterar a cor de um botão.

4. Quais decisões são facilmente reversíveis?

Decisões reversíveis não precisam necessariamente de seis comitês.

5. Onde o trabalho espera?

Essa talvez seja a pergunta mais negligenciada.

Desenhe:

IDEIA
 ↓
ANÁLISE
 ↓
DESENVOLVIMENTO
 ↓
TESTE
 ↓
SEGURANÇA
 ↓
PRODUÇÃO

Depois coloque o tempo em cada etapa.

Talvez você descubra:

TRABALHO REAL = 8 dias
ESPERA        = 42 dias

Nesse caso, reduzir uma Sprint de duas semanas para uma semana talvez não resolva absolutamente nada.

---

26. Curiosidade — o mapa não é o território

Phileas Fogg podia consultar horários, mapas e rotas.

Mas continuava sujeito ao mundo real.

Gerenciamento de projetos sofre da mesma ilusão.

Temos:

Gantt
Roadmap
Backlog
Dashboard
Burndown
Velocity
Risk Matrix

São representações.

Não são o projeto.

Um dashboard verde não significa necessariamente que tudo está bem.

Story Points não significam valor.

Número de tarefas concluídas não significa resultado.

Percentual de conclusão pode ser particularmente enganoso.

Você pode estar 90% concluído durante seis meses.

Quem já viu projeto corporativo sabe exatamente do que estou falando.

---

27. A verdadeira definição de Hybrid

Depois de atravessarmos continentes metodológicos, podemos melhorar bastante aquela definição inicial.

Hybrid não deveria significar:

“Misture Scrum e Waterfall.”

Uma definição mais madura seria:

Use previsibilidade onde existe conhecimento suficiente para planejar e adaptação onde ainda existe incerteza a ser descoberta.

Essa frase muda tudo.

Porque desloca a discussão de:

QUAL FRAMEWORK?

para:

QUAL PROBLEMA?

E essa é uma evolução enorme.

---

28. A metodologia não deve virar religião

Talvez essa seja uma das maiores lições para quem está começando.

Não seja torcedor de metodologia.

Não existe:

SCRUM F.C.
       VS
WATERFALL UNITED

😂

Métodos são ferramentas.

COBOL também é ferramenta.

Db2 é ferramenta.

CICS é ferramenta.

Jira é ferramenta.

CI/CD é ferramenta.

A pergunta profissional é:

Que problema estou tentando resolver e por que esta ferramenta é adequada?

Quando a organização começa a defender o processo mesmo quando o processo prejudica o resultado, alguma coisa saiu dos trilhos.

Literalmente, no caso de Fogg.

---

29. A regra Bellacosa da Volta ao Mundo

Se nosso jovem programador COBOL lembrar apenas de uma coisa deste café, guarde isto:

WATERFALL
Planeje aquilo que você conhece.

SCRUM
Aprenda rapidamente sobre aquilo
que ainda não conhece.

HYBRID
Não trate todos os tipos de
incerteza da mesma maneira.

DEVOPS
Reduza a distância entre código
e produção.

AUTOMAÇÃO
Faça a máquina executar aquilo
que não precisa de criatividade humana.

GOVERNANÇA
Controle aquilo cujo erro realmente
possui consequências.

Esse conjunto é muito mais útil do que perguntar qual metodologia ganhou a guerra.

---

Epílogo — Fogg retorna ao Reform Club

Oitenta dias depois, as portas do Reform Club se abrem.

Phileas Fogg entra.

Passepartout vem atrás carregando um notebook corporativo, três dashboards, vinte Changes, quarenta e sete histórias concluídas e uma retrospectiva que ninguém teve tempo de fazer.

O presidente do clube pergunta:

— Monsieur Fogg, afinal, qual metodologia permitiu completar a viagem?

Fogg olha para o relógio.

Depois responde:

— Nenhuma.

Silêncio.

— Eu tinha um objetivo, restrições, riscos, recursos e informações incompletas. Planejei aquilo que podia prever e adaptei aquilo que não podia.

Passepartout abre o notebook:

PROJECT STATUS: COMPLETED

O Inspetor Fix aparece correndo.

— Espere! Falta minha aprovação!

Passepartout fecha a tampa.

— Está em produção, monsieur.

😂

E talvez Júlio Verne tenha escrito, sem saber, uma excelente metáfora para gerenciamento moderno de projetos.

Fogg tinha um prazo praticamente Waterfall:

oitenta dias.

Mas sua execução era profundamente adaptativa.

Quando uma rota falhava, ele não convocava uma reunião para explicar por que o plano original continuava correto.

Ele procurava outra rota.

Esse é justamente o ponto que tantas organizações esquecem.

Planejamento não existe para obrigar a realidade a obedecer ao plano. Planejamento existe para ajudar pessoas a navegar pela realidade.

Scrum não deve ser desculpa para ausência de planejamento.

Waterfall não deve ser desculpa para ignorar feedback.

Hybrid não deve ser desculpa para acumular burocracias.

DevOps não significa ausência de governança.

Automação não significa ausência de responsabilidade.

E Agile definitivamente não significa colocar Post-its numa parede e esperar que o projeto magicamente fique rápido.

No final, talvez o melhor modelo seja aquele que quase desaparece.

O desenvolvedor sabe o que precisa fazer.

O Product Owner consegue priorizar.

A arquitetura fornece limites compreensíveis.

Os testes encontram problemas cedo.

Security participa antes do último minuto.

Compliance recebe evidências confiáveis.

O pipeline elimina trabalho manual.

Produção recebe mudanças rastreáveis.

E o usuário vê valor continuamente.

Quando isso acontece, ninguém precisa passar metade do dia discutindo se aquilo é Scrum, Waterfall, Water-Scrum-Fall, Stage-Gate Agile ou Hybrid.

O trem simplesmente anda.

E para nós, habitantes do Bellacosa Mainframe, sobra a última lição.

No z/OS aprendemos há décadas que controle, filas, prioridades, segurança, automação e execução precisam coexistir. Um JOB não recebe acesso irrestrito ao sistema apenas porque precisa terminar rápido. Também não deveria ficar eternamente parado porque alguém decidiu que todo controle precisa ser manual.

Projetos modernos estão redescobrindo exatamente esse equilíbrio.

Talvez a volta ao mundo do desenvolvimento de software tenha levado décadas apenas para chegarmos novamente a uma velha conclusão do CPD:

velocidade sem controle produz acidentes; controle sem fluxo produz filas; e metodologia sem propósito produz reuniões.

Phileas Fogg consulta novamente o relógio.

Passepartout pergunta:

— Para onde vamos agora, monsieur?

Fogg observa um programador COBOL abrindo o Jira.

— Para produção.

— Scrum ou Waterfall?

Fogg pega o café.

— Primeiro descubra onde está o gargalo.

Fim do JOB.

IEF142I FOGG80D STEP01 - STEP WAS EXECUTED
IEF285I JOURNEY COMPLETED
IEF375I JOB/F0GG80D/ START
IEF376I JOB/F0GG80D/ STOP

RETURN CODE = 0000

☕ E o café, ao contrário do projeto, ainda estava dentro do prazo.