 |
| 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ÇÃOExiste 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 ruimEle é 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 SPRINTA 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 DIASMas 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ÇÃOEsses elementos podem exigir planejamento.
Enquanto desenvolvimento possui:
BACKLOG
SPRINTS
PROTÓTIPOS
FEEDBACK
PRIORIZAÇÃO
EXPERIMENTAÇÃONasce 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
DeploymentOu 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 controladoNã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
ProductionO 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 operacionaisIsso 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: BLOCKEDO 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
↓
OUTPUTFilas 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 diasSe 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.281Isso parece extremamente preciso.
Não significa necessariamente que seja previsível.
Existe uma diferença fundamental:
PRECISÃO ≠ EXATIDÃODizer:
“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 detalhadaQuanto 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
↓
REVIEWIsso é 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
↓
CloudNo 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
PERFORMANCEEm vez de descobrir tudo isso no final, construa cedo uma pequena fatia vertical:
Programa COBOL
↓
CICS
↓
API
↓
ConsumidorTalvez 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
↓
SPRINTO 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 centralizadasParabé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
↓
OPERATIONSCada seta pode representar:
fila
espera
reunião
ticket
aprovação
retrabalhoPortanto, 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 BDefina:
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
↓
OBSERVEO 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
↓
EvidenceE 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 arquivaAgora imagine pipeline produzindo automaticamente:
BUILD ID
COMMIT
TEST RESULT
TIMESTAMP
APPROVAL
ARTIFACT VERSION
DEPLOYMENT RESULTA 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 .......... milestonesNingué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 AnalystPergunta 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 indecisaNenhum 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
complianceAqui planejamento tradicional pode fazer sentido.
Etapa 2 — arquitetura
Consumer
↓
REST API
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2Etapa 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 — observabilidadeEtapa 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
disponibilidadePerceba:
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ÇÃODepois coloque o tempo em cada etapa.
Talvez você descubra:
TRABALHO REAL = 8 dias
ESPERA = 42 diasNesse 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 MatrixSã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: COMPLETEDO 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.
