SP 065 Parada: Alagamento na Dom Pedro Km 122

Presos no engavetamento

Como um evento prejudica a vida de tanta gente, devido ao alagamento das pistas da Rodovia Dom Pedro em Campinas, houve um grande  congestionamento que começou no quilometro 116 e seguiu ate o 122.

A pista estava alagada e  a policia rodoviária manteve o local sobre vigilância, auxiliando os motoristas a passarem e verificando a integridade da pista.

Foram quase 2 horas presos sem nenhuma informação nas rádios e outros meios de comunicação, seria interessante que houvessem mais informação na Internet, em radio e outros meios.

Uma coisa que nos faz pensar, realmente apesar de todo progresso tecnológico somos reféns das condições climatéricas: um ribeirão que transborda e destruiu meia cidade, uma das principais artérias de São Paulo não ter uma sistema de contingência para transbordamento de rios, barrancos ruindo e enchendo as pistas de barro, Realmente deveríamos aprender com os erros e tentar remediar estas situações para que no futuro nao voltassem a ocorrer.

☕ Lei da Entropia — ou: se você não cuidar, vira bagunça (e rápido)

 

Bellacosa Mainframe e Lei da entropia

☕ Lei da Entropia — ou: se você não cuidar, vira bagunça (e rápido)

Vou começar do jeito mais honesto possível: a Lei da Entropia sempre esteve certa. O que muda é o tempo que ela leva pra provar isso. Em casa, no trabalho, nos relacionamentos, no código, no mainframe… se você parar de cuidar, o caos assume o controle.

📜 Origem da Lei da Entropia

A entropia nasce na física, lá no século XIX, com a termodinâmica. Em termos simples: todo sistema isolado tende ao aumento da desordem. Energia se dissipa, estruturas se degradam, organização custa esforço contínuo.

Traduzindo para a vida real:

manter ordem dá trabalho, deixar virar bagunça é grátis.

🧠 Entropia explicada no “modo Bellacosa”

Um data center não vira caos porque alguém quer. Ele vira caos porque ninguém documentou, ninguém limpou, ninguém revisou. O mesmo vale para:

• Um guarda-roupa

• Um casamento

• Um código COBOL sem comentários

• Um JCL “herdado” de 1989

• Uma amizade esquecida

A entropia não é vilã. Ela só faz o trabalho dela.

🖥️ Entropia no Mainframe (easter egg técnico)

Todo mainframeiro já viveu isso:

• Dataset temporário que virou permanente “sem querer”

• Job que ninguém sabe mais por que existe

• Parâmetro mágico comentado como: * NAO MEXER

• PROC copiada, colada e adaptada até ninguém entender a original

👉 Isso é entropia organizacional.

📺 Curiosidades & Easter Eggs

• O vilão Thanos, da Marvel, é praticamente um evangelizador maluco da entropia

• Em Neon Genesis Evangelion, a entropia psicológica dos personagens é maior que a física

• Em TI, quanto mais antigo o sistema, maior a entropia acumulada — e maior o respeito por quem mantém vivo

🗣️ Fofoquices filosóficas

O curioso é que o ser humano odeia entropia, mas vive alimentando ela:

• Compra coisa que não usa

• Guarda rancor

• Acumula arquivos inúteis

• Evita conversa difícil

• Procrastina manutenção

Depois reclama do caos.

🛠️ A prática da antientropia (sim, isso existe)

A única forma de lutar contra a entropia é energia consciente:

• Revisar

• Limpar

• Organizar

• Documentar

• Conversar

• Manter

No Japão isso vira filosofia. No mainframe, vira sobrevivência.

🧘 Como entender a Lei da Entropia sem sofrer

Aceite três verdades:

1. Nada fica organizado sozinho

2. Ordem é temporária

3. Manutenção é parte da vida, não castigo

Não é pessimismo. É realismo maduro.

🌏 Importância da Lei da Entropia

Ela nos ensina:

• Humildade (tudo se desgasta)

• Responsabilidade (manter dá trabalho)

• Valor do cuidado diário

• Respeito pelo tempo e pela história

No Japão, isso conversa com mottainai, wabi-sabi e mujo. No mainframe, conversa com disciplina operacional.

☕ Conclusão Bellacosa

A entropia não quer te derrotar.
Ela só quer ver se você está acordado.

Quem entende a Lei da Entropia:

• valoriza quem mantém sistemas antigos

• cuida melhor das relações

• respeita o passado

• entende que ordem é um ato de resistência

E no fim das contas…
manter é tão nobre quanto criar.

 

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.