STOP DOING SCRUM
ฝัง
- เผยแพร่เมื่อ 13 ก.ย. 2024
- Quantas vezes tu teve que calcular quantos dias equivalem a 3 Story Points?
The Agile Paradoxon
• The Agile Paradoxon
✅ Aulas Gratuitas ao Vivo de Desenvolvimento Android:
comercial16570...
Pensando em comprar o curso do @FilipeDeschamps ? Use o link abaixo pra apoiar o canal: go.hotmart.com...
✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟
▸ Odeio Desenvolvimento Web do Fundo da Minha Alma | React do TabNews
• Odeio Desenvolvimento ...
▸ Abrindo o que faço na Disney+ como Software Engineer
• Abrindo o que faço na ...
▸ 2023 Programadores
• 2023 Programadores
▸ VAMOS FALAR de R$ 40.000,00 como Software Engineer
• VAMOS FALAR de R$ 40.0...
▸ NÃO DIGA TEU SALÁRIO PROGRAMADOR
• QUAL TEU SALÁRIO ATUAL...
✅ Torne-se membro para obter conteúdo exclusivo:
/ @lucasmontano
✅ Livros, Cursos, Equipamentos, Discord, Aplicativo Memo ↴
lucasmontano.com
Eu devo compartilhar a tela ao fazer o React?
Com certeza sim!!
Acho que pode deixar dinâmico, acho interessante ter duas câmeras kkk, uma pra filmar você quando tiver falando com a gente, quando tiver algo na tela, compartilhar. Estilo jornal 😹😹, vira pra gente uma câmera, vai pro pc, outra câmera
Sim, acho melhor.
Sim!! Em termos de experiência do espectador é meio ruim ter que olhar a tela do notebook, sem falar que parece muito desconfortável pra vc ficar segurando o note na mão daquele jeito kkkkkk
não, qdo vc mostra algo para o conhecido, vc fala olha aqui e não compartilha a tela.
Vamos ser ágeis fazendo dezenas de reuniões que poderiam ser um email
No fim das contas a gente só mudou o jeito de fazer software saímos de um ambiente corporativo e burocrático para um ambiente hippie burocrático
Ri muito desse finalzinho. Realmente, não são poucos os relatos de brasileiros que recebem pedidos de gestores gringos para darem uma segurada na velocidade das entregas. Algo tipo: "O cliente paga em hora. Fizeram uma estimativa. Você, entregando tudo na metade do tempo, vai acabar derrubando o preço do projeto".
Já trabalhei em uma empresa em que ao invés de fazermos reuniões DSM (Daily Stand-up Meeting), enviávamos e-mails detalhados do que estávamos fazendo, do que iríamos fazer e caso tivéssemos impedimentos, além de reportar por e-mail enviar msg pra quem pudesse te destravar. Meu Deus, funcionou mil vezes melhor.
Normalmente essas coisas ficam mais complexas quando é um projeto de escopo aberto, quando é escopo fechado, facilita um pouco essa estimativa.
Enfim, não importa o framework, tudo vira go horse no final. Kkkkkkkk
Faz pouco tempo que saí de uma grande consultoria, era um inferno na terra kkkkkkk. Plannings, dailys, refines de negócio, refines técnicos, reviews com o cliente, retrospectivas, reuniões de priorização, reuniões da própria consultoria, reuniões com o cliente, reuniões de alinhamento com designers, etc. No final sobrava muito pouco tempo para "trabalhar de verdade".
Tudo isso com um time bem grande, onde cada um tinha uma opinião diferente e ficavam discutindo por horas, cada um puxando pro seu lado. Era comum reuniões de mais de 3 horas. Quem aguenta 3 horas pendurado numa reunião em home office???
Planning poker? foi a coisa mais ridícula que eu já vi kkkkk
Pelo amor de Deus
É porque não é tempo é complexidade, sobre complexidade o QA consegue falar qual é mais complexo que o outro. Mas concordo que, se apenas 1 ou outro no time vive o scrum há algo errado aí.
E sinto bastante falta de alguma doc pq depois de 3 horas numa call, ninguém lembra de mais nada a não ser o mais engajado do time. Aí ele vira o ponto focal do projeto.
eu trabalhava em 3 empresas entao ficava no mudo e tals, funcionou por um tempo ate que começaram a reclamar ,mas bixo é mt reuniao, mt chato.. tem 1 empresa q eu ainda trampo q tem feedback 360, daily, refinmaneto, restropectiva...
engraçado que o refinamento é feito pelos devs, deveria ser feito só pelo tech lead ,
E pq não medir tudo em campos de futebol ?
(Ironia)
Eu sou um cara simples, se tem EXTREME GO HORSE no video tem LIKE ❤
Melhor padrao de projeto que existe, torna o desenvolvedor a prova de balas, eles viram o neo da matrix
Go horse é arte, sofrer faz parte auhauhauha
Digamos que vc trabalha por exemplo no Bradesco no cardo chefe de tech. Como fazer para entregar rápido e com qualidade?
Considerando que são sei lá mais de 300 diferentes projetos simultãneos.
Você arruma um ninja pra cada projeto (se é que dá pra achar esses ninjas aí, já contratou alguém?) e cada projeto fica refem de um ninja e quando esse cara resolve pedir aumento vc depende úninca e exclusivamente dele.
Ok dada as condições quais seriam as melhores decisões estratégicas pra se organizar a empresa?
@ oxi, se vc tem um projeto q esta literalmente nas costas de um desses Dev ninja ele mais q merece um aumento!
E se a situação chega a esse ponto é pq a gestão o planejamento e a execução foram ruins Então desconta dos heads por terem aprovado um plano ruim (sem as devidas contingências) , dos gestores que deixaram a situação se enrolar ao ponto de depender de uma só pessoa sem conseguir catalogar as atividades e conhecimento necessário para execução
@ paga um adicional por produtividade para cada ninja, dessa forma ele se torna motivado a entregar o projeto no prazo por que a sua remuneracao adicional depende do desempenho do projeto.
se utilizar scrum até mesmo o ninja vai boicotar o projeto pq pra ele é indiferente o andamento do mesmo
Pra mim tudo se resume a comunicação.
O problema que a "agilidade" "cria" e "resolve" é todo em cima de comunicação.
Resolve isso e não precisa mais de 50 rituais e 100 pessoas pra saber o que fazer.
1h programando errado é muito mais caro do que 1h sem programar.
No melhor dos casos, 1h errada vai ser só desfeita e tem o peso de 1h ociosa.
Em qualquer outra situação, você vai introduzir bugs, technical debt, bagunçar o que tava certo e ainda corre o risco de quebrar o ambiente de produção.
Ou seja, 1h programando errado pode te perder inúmeras horas 😂
Concordo, mas podemos ver por esse lado... essa 1 hora perdida vai se transformar em uma hora de experiência, a qual poderá ajudar nas futuras tomadas de decisões. Entretanto, há possibilidades de realmente se tornar horas perdidas que não vão ajudar ou agregar em nada. Haverá casos em que implementar e testar é o caminho mais rápido do que passar dias se matando para saber qual seria a melhor solução para resolver um problema/bug.
Isso é "desevolução", você só sabe se algo está certo ou errado se conhece o que está sendo apresentado e para saber alguém precisa já ter sido feito, ou seja, fazer errado não é tempo ocioso é aprendizado para não repetir, agora se você sabe do erro e deixa passar, aí sim é um problema e se enquadra no que disse.
Preste atenção na história, quantos anos não temos uma invenção revolucionária, internet é dos anos 60, um computador tem 2 mil anos, um mais próximo dos de hoje é dos anos 40, o conceito de IA vem dos anos 50, avião e carro tem mais de 100 anos, carros, inclusive elétricos, também tem mais de 100 anos, remédios importantes está nessa faixa de idade também como a penicilina.
O que tem em comum? simplesmente as pessoas faziam e resolviam problemas reais, não pensavam no que pode dar errado e faziam milhares de planos para algo que pode nunca acontecer, se acontecesse, pensava em como resolver e não ficava imaginando um mundo perfeito. Se os responsáveis em inventar o avião ficasse pensando que poderia ser usado para guerra jamais inventaria, se quem inventou internet ficasse pensando nos ataques que existem tentando travar até hoje antes de lançar o produto, jamais existiria.
É difícil dosar, mas infelizmente alguém precisa provar do veneno para saber que é veneno, e caso não seja, foi criada uma nova revolução, hoje essa metodologia faz com que não exista mais isso, por isso nossa evolução está estagnada, temos apenas melhorias, nada novo entre 60~100 anos
Nada a ver. 1 hora fazendo reunião e 1 hora programando errado são 2 horas. 1 hora programando errado e 1 hora arrumando são 2 horas porém você vai ter arrumado o problema.
É equilíbrio é difícil. Não tem fórmula mágica pra resolver uma coisa que funciona em equipes. A ideia legal que eu pensei sobre o Scrum é o time ter autonomia pra ir melhorando sozinho. E não depender de líderes. Auto gestão o que for mais eficiente e der boa, segue ..senão muda o processo. Isso que entendi lendo o Livro...mas até hj não entenderam, direito talvez. Estas cerimonias todas nem precisa e estimativas. É mais a ideia de colaboração, definição do que cabe dentro de sprints, entregaveis incrementais com mais valor, times multidisciplinares e com autonomia e auto feedbacks pra ir sempre melhorando. Inclusive melhorar a comunicação. As pessoas vão complicando demais as ideias e parece telefone sem fio kkk era pra simplificar e ser mais inteligente e não complicar mais ainda.
Aqui usamos Scrum, entre outras coisas. Fomos adaptando e melhorou muito. Esse negócio de que Scrum não funciona ou funciona e tipo hate de nego que quer desculpa pra não interagir. Como na minha equipe trabalhamos com auto gestão, o Scrum se tornou uma ferramenta poderosíssima de interação e produção. Agora produzimos algo que entrega valor de verdade e gera menos débito técnico. Mas é isso, já ouvi de programador que DDD é perda de tempo kkkk, no fim acho que é desculpa pra nao estudar e se aprofundar em ferramentas que melhoraram a organização.
Scrum é igual a comunismo, ninguem fez do jeito certo kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Essa foi foda
Tem uma galera comunista que ta ofendida.😂😂😂
@@opedro.salvador Não tem pelo o que ficar ofendido, sou de esquerda e concordo com a fala dele, nunca existiu comunismo mesmo 🤷♂
@@JoaoVitor-jv6um veja bem João. Ninguém disse que comunismo não existe. O que foi dito é que não funciona.
É pq o comunismo é uma utopia, nunca ira existir um comunismo que deu certo.
@@JoaoVitor-jv6umkkkkkkkkkkk
O pior de tudo é trabalhar numa empresa que ainda tenta implantar scrum em 2023 como se fosse algo revolucionário. Mas é claro que essa mesma empresa faz uma “daily” de 1h pq a equipe tem 20 pessoas, nao tem documentação detalhada e tem 1 scrum master que na prática é um project manager fazendo microgerenciamento 😅
Story points é o maior bait de todos os tempos. Já perdi as contas de quantas vezes passei dias resolvendo um problema que deveria ser "fácil", o famoso 3 que vira um 8.
mas o problema nesse caso não é dos story points, e sim que foi feito a medição errada da história.
😂 o mais legal é o gerente de projeto sendo o scrum master “o certo é usar pontos, mas como estamos começando vamos usar horas” 😂😂😂 tinha um colega que resumia a estimativa assim “olha, o tempo é num range entre 2 e 45 horas 😂
@@karinebaltKKKKKKKKKKKKKKKKKKKKKK específico demais
react mais moderno que eu já vi, eu quase consegui enxergar a tela do note
"Ninguem fez certo, ainda..." ooh comparação acertada meus irmão e irmãs kkkkkkkkk
Camaradas.
Sou programador e jogo poker a 10 anos positivamente vi seu vídeo até o fim mas acredito que vc quando vc fala de fibonnaci é uma progressão de apostas normalmente usado em Blackjack no qual tem RTP é negativo para o jogador, Poker no entanto é um esporte da mente como o Xadrez. Ele se baseia em estatísticas no qual se vc tiver um ROI positivo com amostragem legal vc sempre vai sair ganhando no final.
Não sei vocês, nossa produtividade aumentou quando abandonamos story points. Tira agenda de planning e refina só quando precisa e sempre em vários mini entregáveis
Aumenta a quantia de PRs mas vão ser todos bem pequenos, fáceis de revisar, também fácil de testar a história e todo mundo fica feliz
Vocês abandonaram story points mas foram para o quê? Entendo que ainda assim vocês mantém as estimativas... certo?
@@paulorockz6899as entregas são pequenas justamente pra manter uma média (o que não é regra). Pode ser algo combinado diretamente com o pessoal se Produto (tipo uma conversa assíncrona mesmo ou via daily). Ja trabalhei sem scrum dessa forma ai, basicamente a gente se falava via chat o que era mais urgente e ia combinando assim, quando a coisa era muito complexa ai sim fazíamos reuniões com quem era necessário. Definíamos uma data posterior pra entrega e ja era. Funciona bem quando todos são autossuficientes e capazes, quando tem muito jr ou seniors incompententes já fica meio inviável
Aqui abandonamos story points e mantemos refinamentos semanais, com tasks menores possiveis(mini entregáveis). O board vai sendo populado conforme a vazao do time
Na empresa que eu trabalho nao existia scrum, e as coisas andavam muito mais rapido, eu entregava uma task em 1 dia, 2 dias, agora implementaram o story points ta osso, muita cobrança pressao, as coisas nao andam muito, é 3,4 dias pra entregar, osso
Absolutamente todo projeto que já foi pra produção teve aqueles últimos 10% (que equivalem aos outros 90% do projeto) feitos na base do XGH. Os gringos só não sabem que a gente já tem um termo cunhado para isso faz tempo.
O "ta quase pronto" que leva quase o mesmo tempo do resto do projeto.
@@waltwhite8126As vezes mais
Pior que é verdade, semanas na paz, e nos ultimos 4 dias antes da entrega, todo mundo suando sangue com o gerente de projetos no cangote pra garantir que vamos entregar.
O detalhe: os 4 dias são quinta, sexta, sabado e domingo 😂
Cara, tá uma loucura mesmo. Tenho sprint de 1 semana. Todo dia tenho Daily meeting, toda semana tenho 1 Weekly Kick-Off, toda semana tenho 1 Backlog Refinement (as vezes chamado de grooming), a cada 2 semanas tenho Retrospective, a cada 2 tenho Demo (pra mostrar, live, o trabalho que tá fazendo), a cada 2 tenho One-to-One meetings com meu manager, a cada 2 tenho mentorship meetings, a cada 2 tenho..... isso só com meu time, fora as reuniões inter-times que tenho, por ex Postmortem (quando há incidentes, tb semanalmente), Show & Tell (onde mostra o trabalho num nível maior que o time, geralmente Tribe ou Domain....
É tanta reunião que criaram o "Winning Wednesdays", onde não se pode marcar reuniões...
Desde que nasceu o SCRUM eu falava e brigava que era absurdo esse esquema de Story Points... agora já tá mais que óbvio....
O Fábio Akita fez um vídeo sobre esse assunto. Transformaram os princípios ágeis em uma verdadeira "bullshitagem".
Vou começar a falar difícil que nem vocês
Eu trabalho com: "Marked map" + "Go horse" + "DJTC"
- "Marked map" (define os requisitos a serem contemplados e um plano de execução)
- "Go horse" (go horse)
- "Don't jump on cliffs" (não é porque ta no plano que é o que deve ser feito quando chegar a hora, adaptemo-nos)
É muito frustrante trabalhar numa empresa de tecnologia que ta mais focada nessas metodologias, do que na entrega de fato, é a receita pro burnout pq ve cada vez mais demandas, mas nada anda e vc nao consegue entregar..
Eu não sou desse mundo dev, porém do mundo do Marketing. E já estive em agência onde tinha o scrum como framework de produtividade.
As dailys todos os dias para iniciar o nosso dia abençoado, reuniões de planejamento, reunião de kpi's da campanhas, reunião para fazer reunião, e reunião de sexsta para dizer como fomos em questao de produtividade....
Era reunião para todo o lado que a cobrança era cada vez maior, passava pouco tempo atendendo os clientes mesmo e os resultados dos clientes caindo aos poucos.
Tinha que fazer milagre para entregar tudo, apagar incêndio toda hora pois o time de CS vinha na cobrança e ainda tinha meus clientes por fora que dava um jeito para atender.
Sério fiquei maluco e sai de lá porque não tinha mais tempo para fazer minhas coisas, pois chegava a noite estava esgotado.
Hoje tocando meu negócio, atendendo menos clientes mas ganhando muito mais, tenho meu tempo para estudar, criar novas coisas e atender os clientes. Scrum realmente é um cancêr.
Sobre o scrum, a parte de estimativa fica boa demais quando dois sênior coloca que gasta 2h e o junior gasta 12h, no fim essa task vai pro junior com estimativa de 6h, é onde o dev acaba evoluindo na raça 🤣
Parece aquela funcionalidade da Udemy de "Programe um horário para o aprendizado" que você sempre descarta, mas eles ficam empurrando goela a baixo para você usar e toda hora reaparece.
Mano, quando eu vejo que o cara vai reagir o vídeo e eu tenho que ver no notebook do cara já desisto de ver
Compartilha a tela ae Lucão! Vlws!
esse foi o sentimento né mano, puts
vai ver o cara não tem tempo de fazer edição, não julgo
Neste exato momento estou implementando uma funcionalidade EM PRODUCAO que meus proprios clientes exigiram que ela fosse pra producao sem teste algum justamente pq eles precisam dela o mais rapido possivel por que eles ja estam necessitando desta funcionalidade para fecharem um contrato gigante com os clientes deles.. ou seja, mesmo funcionando de forma duvidosa eles se responsabilizaram por QUALQUER consequencia inesperada, então no fim de tudo, no mundo real é sempre MELHOR MAL FEITO DO QUE NÃO FEITO. X GO HORSE FTW
Aham, daqui a pouco eles vão começar a reclamar que não atende, ou vai começar a dar bug sem parar, e vai virar um remendo seu código. No final o cliente que parecia satisfeito, vai ficar insatisfeito, e você criou um monte de débito técnico que só uma reformulação, que investirá tempo pra cacete irá resolver, aí no fim das contas você gastou mais tempo do que deveria e perdeu o cliente mesmo assim. Essa é a famosa balela e desculpa que eu escuto a décadas que trabalho na área. Scrum funciona, mas isso não é regra, esse hate de quem não conhece ou teve uma experiência ruim e agora virou regra
@@dkeepsie eu não tiro sua razao, mas no meu caso tudo está descrito no contrato, até mesmo o produto entrando em producao em fase beta. Isso nunca havia ocorrido comigo em outros projetos, eu jamais aceitaria esse tipo de contrato com clientes, mas esse caso foi muito especifico e tem muito dinheiro envolvido, e quando o dinheiro jorra não tem muito o que vc fazer a não ser aceitar.. e mais uma vez o mundo será salvo pelo XGH ! 🤣
@@arthurmelo88 tô ligado como é kkk. Passo por isso também, mesmo sabendo que vamos sofrer no futuro kkk
Olá, Lucas. Polêmico o vídeo, hein. Muito legal, inclusive.
Olha, eu concordo 95% e queria explicar a diferença dos 5% de discordância, se me permite.
Acho que o mérito do Scrum está mais na tentativa de adaptar o Lean ou STP ao universo de TI.
Como software é intangível, a ideia de criar "unidade básica" para ter distribuição de frequência na esteira de produção tem suas virtudes, à medida em que faça sentido tanto para o negócio quanto para o time. Entretanto, não raro, o negócio deturpa qualquer modelo de gestão de inovação/tecnologia quando não pertence ao mesmo. Não só o Scrum, mas qualquer framework.
Acho que a cola que faz falta é o entendimento do que é um time scrum. Mas, sem advogar a favor de nenhuma metodologia, na boa. Acho que o Scrum é uma embalagem simplificada do Lean, na boa.
Parabéns pelo vídeo e pela provocação.
O inimigo da edição kakakaka
Axioma 7. XGH doesn’t have schedules. Schedules given to you by your clients are all but important. You will ALWAYS be able to implement EVERYTHING in time.
Um dos motivos pelo qual o XGH é a melhor opção, sempre se entrega tudo no prazo e ponto final. Quando tudo explodir, aí só ir pro Axioma 8, pular do barco ou culpar alguém kkk
Lucas, seu vídeo tem algumas coisas a serem observadas. O Scrum não é prescritivo, não define técnicas. Planning Poker, Standup meeting, Story points, etc, nada disso faz parte do Scrum. Muitos times Scrum falham por falta de experiência … scrum master não é posição para iniciante, assim como Project Manager tbm não.
Esse fechamento largando a real com o Go Horse valeu o like! Eu curti a dinâmica do react mostrando no notebook
Essa parada de story points não corresponder as horas trabalhadas é a maior idiotice (ao meu ver), por que complexididade não necessariamente indica a duração da história, até por que existem histórias que são fáceis, mas são grandes, e você pode ter uma que é muito pequena, mas é extretamente complexa.
Que vídeo maravilhoso! Eu realmente não entendo pq o Scrum ficou mais popular que o XP, que foi feito voltado pro desenvolvimento de software de fato. Talvez tenha sido por causa dessa visão dos gestores de que a produtividade é relacionada a esse controle de processos e não às práticas de desenvolvimento em si. O que vocês acham?
XP acho muito interessante, mas não sei como funcionaria em equipes grandes. O próprio criador do método comenta que XP é mais voltado pra equipes pequenas (3-10 desenvolvedores) e não é recomendado pra projetos que envolvam 100 desenvolvedores por exemplo, já que o método envolve muita sinergia e comunicação entre os desenvolvedores (pair programming, alta cobertura de testes, disposição específica do espaço, interação síncrona, etc.).
Não sei se surgiram adaptações do método que dão conta dessa situação.
Obrigado pelo video. Sou formado em gerenciamento de projetos e consegui reunir uma equipe pequena de programadores para iniciar um novo produto, geralmente nós (Project Manager ou Product Manager) aprendemos a fazer diversas reuniões para nos alinharmos com a equipe, então nem sempre é algo proposital, na maioria das vezes é apenas uma questão do gerente achar que é o melhor método ou que é o método correto. Nos comentários eu li uma sugestão muito interessante, referente a utilização de emails ao invés de reuniões diárias e passarei isso para minhas equipes a partir de hoje. Sinceramente nunca há muito oque ser dito em uma reunião diária e tudo que é dito pode tranquilamente ser passado por email.
Na minha empresa a gente fez uma metodologia que pegam coisas boas do Scrum e do Kanban e acabou que se solidificou tanto que não necessitou mais de scrum master
um time de dev só deve existir dev, nao precisa de PO enchendo o saco, nem scrum master, nem agile master
Mano, tu é foda demais. Como que faz pra ser teu amigo? Eu já te sigo no twitter KkkkK muito bom cara. Particularmente, implementamos algo parecido com Agile e Scrum na empresa (basicamente as sprints KkkkK), e tem funcionado até agora. As entregas estão bem eficientes e com um feedback bem legal. Analisando os processos da minha equipe, acredito que usar o framework à risca poderia engessar um monte de coisa. Acho que no final, a palavra que sempre tem que ser considerada é adaptabilidade. Tudo são contextos, e o que funciona pra um pode não funcionar pra outro. Tmj
Se tem algo que me da sono na faculdade é esse papo de metodologias, pq eu sempre sei q falando de ramo empresarial, vai ser algo que atrapalha mais que ajuda.
Essa nova perspectiva de react é a mais inovadora que já vi
Na empresa que trampo, umas das maiores aqui da Australia, eu sempre falo para PO, PM, Scrum Master, toda essa gente ai que tudo que fazem eh um circo e so. Por que quando a parada "funciona" todo time para de estimar T-shirt, fibonacci, e faz free style total e sempre melhora. So vejo sorrisos amarelos, e completo que se a empresa ta feliz com todo esse ritual eu tambem estou ja que mantem o trampo de todos!
Trabalhar com cascata presencial em cubiculos devia ser terrível.
Agora imagine hj com trabalho remoto… seria o sonho.
Programa entrega recebe e vai curtir a vida
tudo isso pq o cliente não sabe bem definir o que precisa mas quer tudo para ontem !
Video muito necessário! Inclusive, o final do vídeo pede por um outro video!!! Por favor, faça um vídeo falando sobre o extreme go horse e o pq da galera se apavorar quando vai pra gringa!!!
Ótimo vídeo!
"Cadê o espaço para criatividade", representa muito esses frameworks agile... não passa de uma ferramenta para controle mesmo
O ponto é que a galera sempre quer botar a culpa em alguma coisa. O SCRUM funciona sim caso você queira treinar programadores juniors que nunca trabalharam em equipe, que não sabem dialogar ainda, que tem medo de fazer estimativas e que tem medo de errar. Para treinamento de equipes ele é muito bom sim. Todo treinamento tem um tempo limite, depois deste tempo é obvio que se deve parar com as cerimonias e a equipe já deveria estar fluindo melhor. O próprio fato do time-box é para as pessoas aprenderem a parar de fazer as reuniões.
Polêmico, muito polêmico. O grande lance é que a maioria das críticas não São diretamente ligadas ao framework scrum, mas sim a práticas adotadas por muitas equipes que usam o scrum.
Eu particularmente prefiro no scrum, a daily, planning, retro e também as agendas de refinamento. Acho que independente se é scrum ou n, essas etapas acabam sendo bem importante para deixar o time alinhado, evitar que pessoas tomem decisoes erradas e forçar com que as pessoas sempre estejam ali trabalhando em alguma coisa. No fim, acho que o scrum traz uma porrada de coisa e historinhas, mas acho que cada time tem que entender o que faz sentido pra eles e se tem algo que n ta mudando nada, joga fora.
Nem tem história no método scrum. Vide o vídeo: scrum é só o frame da janela. Vc poderia chamar ítem de backlog e escrever esse ítem do jeito que quiser.
E se vc não entendeu essa parte do scrum: ''e porque vc ta fazendo errado" - contem ironia tá.
na firma a gente (3 staff) usava algo como uma mistura de kanban+scrum, que no fim era muito parecido com ShapeUP. tudo fluia e o produto lançado com sucesso e mais features por vir... diretoria nova quis meter scrum by the book, estimativas por horas, e toda papagaiada que sabemos.. resultado, o foco mudou do que antes era a entrega em si e foi pra estimativas que demonstrem "velocidade", fodase a entregar do jeito certo, tem que entregar como foi estimado por pessoas que ignoram parecer técnico, qualidade foi pro saco pois tem que se virar pra caber nas estimativas se não é punido, clima terrível na equipe, avg de 8hrs de meetings por semana, flow da equipe foi destruído... minha primeira exp com uma regressão tão grande
Eu sinto falta de documentação. Às vezes eu passo mais mais tempo tentando entender como o que eu faço se relaciona e não quebra outras coisas, do que de fato codando
CARA!!! vc me ganhou no EXTREME GO HORSE"!!!! KKKKKKKKKKKKKKKKKKKK
To chegando na área agora, aprendendo sobre o mundo de programação, obrigado pelo video...
Obrigado por mais um vídeo Lucas Montano do canal Lucas Montano
o cara colocam o problema como um charmander e na hora de programar é na verdade um mewtwo mt puto kkkkkkk
7:27 A vontade que eu tenho de dar um tapa no Scrummaster animadão do video não pode ser descrita em palavras...
A questão é que a agilidade têm varias coisas antes de um framework tipo scrum, kanban ou qualquer outro. Ai as empresas querem implementar um framework sem começar da mentalidade. Da nisso, um monte de gente que rusha certificação e nao entende nada de agilidade de verdade e mais atrapalha do que ajuda os devs.
As empresas acham que agile é entregar o dobro de features em metade do tempo ou o mais rápido possível. Hoje as empresas vivem o cascágil... e isso eh uma bosta.
Framework não é norma, agilidade não é velocidade e microgerenciamento e síndrome do pequeno poder sempre vão distorcer qualquer coisa.
Caraaa, o roteiro até os @03:08 matou a pau no speech, se fosse um elevator pitch pra me vender uma solução eu já tinha comprado kkkkkkkk
A mente da jovem aquu fica surtada kkkkk O Scrum destrói a coisa mais importante em inovações: a criatividade. O produto vai ficando cada vez mais chapado naquilo que ja é sempre esperado e nunca traz uma real inovação porque o dev não tem tempo e espaço de usar criatividade.
XGH é vida, aliás norteia todo dev roots ... hahaha
E aquele Kanban maroto, que a galera divide uma atividade em 50 post its sendo que só dava no máximo 3 e a entrega em 2 dois dias, mas precisam fazer isso pra dizer que tem um monte de trabalho... haha!
Curti muito esse vídeo. Dei umas risadas pelas criticas.
Share the screen Lucas Montano
video recomendado logo em seguida: Fabio Akita "esqueça metodologias "Ageis" KKKKKKKK
Realmente, algo de errado não está certo. Sou da filosofia; melhor feito do que perfeito, entrega logo pro cliente ver se é mesmo o que ele queria, falhe rápido, arrume rápido. O que vi em 28 anos de dev é que geralmente o excesso em planejamento não resulta em melhor desenvolvimento. É bom ter requisitos mais certos, mas quase sempre a tentativa e erro é mais rápida, porque nem todo mundo no fluxo, do cliente final ao dev, sabem realmente o que querem e o que precisam.
O cliente pediu um cachorro pra cavalgar, dá logo um cachorro pra ele cavalgar, é mais rápido do que passar por todos os especialistas e convencer o cliente que ele não vai conseguir cavalgar num cachorro. Vai passar seis meses, o cliente vai pater o pé que quer um cachorro, você vai acabar fazendo um cavalo e dizendo que é um cachorro, e o cliente: porque demorou tanto pra fazer só um cachorro?
Xtreme Go Horse É O Q HÁ!
Devs das bola azul USAM!
Muito massa o seu conteúdo. Sugiro informar os links dos principais sites que você cita nos seus vídeos. Valeu!
Eu aqui me matando atrás de um curso ou minicurso de scrum porque tem empresas que estão me procurando exigindo certificado scrum master. Quer saber, vou pular pra outras oportunidades...
Engraçado que tudo isso começou exatamente como muitas das coisas que hoje são consideradas "hype" ou "melhores praticas" ... Vamos ver qual sera o próximo câncer em alguns anos ... Eu ja tenho o meu chute kkk
Quem será o Scrum Master... a IA! Hahahahahaha A máquina mandando nos Devs!
Muito bom a reflexao, tenho pensado sobre isso a anos me sentindo afundando nesse mar de ineficiencia. Antigamente eu percebia as entregas e a evolucäo com a experiencia de errar e acertar... tambem haviam pontos ruins e a evoluçäo do metodo parecia necessaria, mas como todos sabemos, um passo pra trás é bem mais custoso que varios a frente. A falacia do "fail fast" é muito difundida e pouco aplicada porque gestores que literalmente se descolaram da realiadade quando tudo está dando errado ai dane-se o framework apenas entregue até o deadline.
Esqueceu o six sigma, esses dias apareceu uma vaga pedindo yellow belt
Tava demorando sair um vídeo, ja tava com sudades dos vídeos. :)
Reuniões demais, funcionalidades low utility, muito Cacique pra pouco índio.
Meu Scrum é refinar a task pro dev, explicar via call SE ELE QUISER e deixar o cara codar. Tem prazo estimado? Informa na task. O prazo está próximo? Pega status PELO CHAT. O prazo estimado venceu? Pega status PELO CHAT. Nas últimas das instâncias, eu encho o saco do dev. Cara.. Pense num scrum bom esse!!! As demandas voam!
Fiz uma especialização de Software Product Manager só pra encher linguiça. Na prática é igual ser chefe de time de formula um. Bota teus pilotos no carro e deixa os caras correrem.
Pra onde envia o CV? Kkkkk
Tudo fica pior quando o Scrum master não sabe nem fazer um Hello World em Python e quer da pitaco.
Isto o fabio akita ja dizia há 4 anos atrás sobre mitologias "ágeis"
Mas o Scrum falhou "per se" ou teve influências "externas" minando seus pontos positivos até que eles se tornassem negativos?
Eu estou falando de Scrum?
Akita já tinha aviso isso.
Camarada Lucas ? o problema do comunismo não é que ninguém fez certo ainda, não existe países comunistas. só socialistas, e o problema dos socialistas são as sanções e bombardeios burgueses, mas enfim, perdão o comentário o canal nem é sobre isso kkk, ademais ótimo vídeo e conteúdo como sempre
Ninguém sobrevive até a implantação do socialismo, infelizmente o povo morre de fome antes.
@Lucas Montano do canal Lucas Montano, tem um suporte de notebook ali man.
Eu sou tech-lead numa empresa, porém meu "PO" não me permite exercer a função de Tech-lead, meu "PO" é ansioso e hyper ativo, ele é aquele tipo de pessoa que precisa estar fazendo tudo, e rápido, e não espera ninguém, toma decisões ao mesmo tempo que está te perguntando sua opinião sobre o que é melhor, enquanto ele está te falando a pergunta, ele já decide a resposta da própria pergunta e não te dá tempo de responder. Você tem que ou bater na mesa, ou gritar, ai sim, ele entra em choque e para de falar.
É terrorismo puro !!!!
Quando você está apresentando o progresso do seu trabalho para ele, que está seguindo EXATAMENTE o que foi planejado, ele já percebe mudanças que precisam acontecer, e polimentos na tarefa que você ainda não entregou, está apenas mostrando o progresso. 😞
eu passo codando somente 1 hora por dia o resto eh reuniao , analisando bugs e make a PR
Acho que o problema é ficar tentando jogar poker. Não faz sentido nenhum: não dá para prever a dificuldade/tempo/complexidade de uma tarefa antes de realizá-la.
Também tem a questão de que reuniões são importantes, mas, apenas na medida que são realmente produtivas. É preciso encontrar um equilíbrio.
Ta soltando só às pill heim.
Oi Luca, eu sei que você está interessado em algumas vagas na gringa. Então fica a pequena correção no inglês. Você pronunciou SCRUM errado. Busque no Google a pronuncia certa.
A expressão que eu mais uso aqui no trabalho é: PP.
No meu time, a gente tenta equilibrar as reuniões. Tenho impressão que da certo.
Quase um pós credito "Extreme Go Horse da certo no Brasil (true) e quando o pessoal vem para fora a galera se apavora (true)"
E esse video saiu um dia depois de eu ter feito uma prova na faculdade que tinha metodologias ágeis, e o SCRUM incluso.
E eu que estava fazendo um trabalho ontem falando bem do Scrum pra entregar até sexta-feira... Acho que vou mudar tudo kkkk 😂
Odeio planning poker. Não é bala de prata, mas acho que software deveria ser estimado em pontos de função.
Sinto falta do Go-Horse programming 😂😂😂
deduzo que um tempo de scrum poderia ser um tempo para codigo teste. Se ha um Scrum, após ele existirá um codigo teste de alguma feature, nisso foram gastos dois tempos, se não houver Scrum fica apenas um gasto de tempo que é o codigo teste. Usar os tempos de Scrum e codigo teste para apenas Codigo Teste e Codigo final(refatorado) me parece mais eficiente.
Se tu passa 8 horas desenvolvendo e não está alinhado com o que o stakeholder/business quer, tu está perdendo tempo.
Na empresa onde trabalho, temos cards no Trello com as atividades que devemos desempenhar, você consegue ver o que todo mundo ta fazendo e temos apenas 1 reunião por dia para cada um dizer o que fez no dia anterior e esse sistema funciona muito bem.
Não entendi o final, brasileiros quando trabalha na gringa tem mais difícil, por que?
A primeira a ser venerada foi o B.I. apos dissidências, muitos dobraram seus joelhos para o UML. Hoje o Agile e' a religiao . Nao sei como vai ser o futuro, mas seria bom pararmos de dogmatizar frameworks, patterns, paradigmas e vibes do momento
mto bom o lucas fazendo react em terceira pessoa kkkkk
Assistindo o vídeo (com o cara de toca), ai me aparece um anuncio com o cara trajado da mesmas forma kkkkkkkkk
muito boa essa nova modalidade de react: segurar o notebook e mostrar na câmera. acredito que virará tendência no futuro