STOP DOING SCRUM 

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.

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 ,

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

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.

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.

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

Camaradas.

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 😂

esse foi o sentimento né mano, puts

vai ver o cara não tem tempo de fazer edição, não julgo

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

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

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.

um time de dev só deve existir dev, nao precisa de PO enchendo o saco, nem scrum master, nem agile master

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

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á.

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

Quem será o Scrum Master... a IA! Hahahahahaha A máquina mandando nos Devs!

E eu que estava fazendo um trabalho ontem falando bem do Scrum pra entregar até sexta-feira... Acho que vou mudar tudo kkkk 😂

Acho que a questão é que o scrum é mais uma ferramenta e vale a pena extrair o melhor dela, ela dá uma resposta pra muitos problemas que podem surgir no processo de desenvolvimento. Podem não ser as melhores respostas, mas vale a pena conhecer e fazer um esforço pra ver se é aplicável.