✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
quarta-feira, 21 de fevereiro de 2024
Metodologia Waterfall, o que é, para que serve, virtudes e defeitos
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.
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 ☕💾