A verdade sobre MÉTODOS ÁGEIS

A elaboração do manifesto ágil e o impulso do movimento ágil, globalmente, representaram marcos significativos para o avanço do desenvolvimento de software. No entanto, ao longo dos anos, surge a dúvida: ainda há relevância? As empresas estão aptas a implementar eficazmente esses princípios ou estão simplesmente adotando uma abordagem que pode resultar em mais burocracia e rigidez na produção de novos softwares?

Manifesto ágil:

======================================

🖥️ Setup:

======================================

👨🏼‍💻 GUSTAVO CAETANO:

#scrum #agile

[raphaeldinellineto]

Minha Daily tem em média 45 minutos. 40 nos contamos piadas da quinta série e nos zoamos e 5 minutos falamos de trabalho. Eu amo as Daylies

[rrestituti]

Faz muito sentido o que você falou.
As daylies do meu time são para eu saber se o dev precisa de ajuda. Se teve alguma dificuldade que eu preciso ajudar. Nao fico cobrando o que a pessoa fez no dia anterior.
Além disso, o gerente do time DEVE ser um bloqueio de demandas urgentes ou mudanças de escopo abruptas. Tem que bater de frente com a área de negócios e segurar o tranco.
Os devs precisam de tranquilidade para desenvolver. É o que venho fazendo e as coisas estão andando bem.
Abraço, Gus!

[marceloandrj]

Seu vídeo é ótimo! Trabalho com TI há mais de 30 anos e passei por diversos tipos de projetos e tecnologias que não necessitavam de tantas cerimônias e profissionais intermediando. No início a confiança era plena na capacidade de organização e auto-gestão do desenvolvedor. Não existia front e back, a gente fazia tudo. Eu ganhava projetos e tinha prazos semanais ou mensais para reportar e mostrar as produções. Testes, funcionalidades, desempenho, tudo fazia parte do processo de desenvolvimento, assim como em diversos produtos como por exemplo em SAP. Aliás tenho certificação SAP funcional e sei programação ABAP, isto é, o universo SAP era um bom exemplo de simplicidade: existe o profissional funcional para coletar requisitos e organizar as demandas, e na outra ponta, o profissional desenvolvedor Abap, só isso, e assim foi desenvolvido por anos o maior ERP Alemão do mercado.

Esta estrutura e metodologia de produção de sistemas hoje faz o produto do desenvolvimento deixar de ser uma arte que dá gosto de se fazer e viver, para uma uma batata quente que pula de mão em mão e ninguém quer ser responsável se ela cair no chão. Todos ficam com burnout, putos com a profissão, com a capacidade própria, com síndrome de impostor, com modinhas sendo criadas o tempo todo para justificar uma complexidade que não deveria existir, fora a quantidade de líderes medíocres, que mesmo tendo bom conhecimento, parecem capatazes ou leões de xácara vaidosos, que para justificar seu cargo, precisam humilhar sua equipe. O bagulho tá doente.

Se nós fôssemos de fato unidos, iríamos perceber que o mundo está todinho em nossas mãos: TI.

[igorcastilhos]

O ThePrimeagen fez uma live com o Uncle Bob, um dos fundadores do Agile Manifesto, e lá ele fala que o conceito foi totalmente deturpado por Gerentes e pessoas que não eram programadoras. Tem no YouTube a gravação

[raphaeldinellineto]

Hahahaha no fim é tudo go horse. Concordo, gastam-se horas numa planing para no dia seguinte o PO chegar com uma demanda que do neida que virou prioridade máxima.

[RodrigoMFSP]

Ontem fiz uma entrevista e me perguntaram se eu trabalhava com SCRUM. Minha resposta sempre é.. Quem tem que saber isto são vocês.. o SCRUM se adapta a realidade da sua empresa ? Eu trabalho como vocês precisarem.

Duro é empresa que faz daily a tarde..

[xxultz]

Quando comecei a pensar sobre gestão de projetos, há uma penca de anos atrás, o que sempre me arrepiou foi a gestão dos prazos. No cascata era uma desgraça, porque era necessário decidir todos os passos do projeto inteiro, estimar todos os prazos, juntar tudo e passar pro cliente um prazo de entrega e um preço. Mas desenvolvimento de tecnologia sempre acaba envolvendo algum tipo de inovação, o que quer dizer desenvolver algo que ninguém nunca fez, e é impossível saber todos os percalços e dificuldades, então a estimativa de tempo sempre foi um chute, e some N chutes de um projeto inteiro, e o prazo de entrega vira uma aposta com chance menor de estar certa que a mega sena. O que enxergo no Scrum é que a tentativa é pensar nos prazos só de uma sprint, mas mesmo isso dá ruim, o tempo todo, porque na Review todo mundo tem que mostrar que fez o que foi planejado na Planning, e no final da PI tem que mostrar que fez o planejado na PI planning. E não existe almoço grátis: se o prazo tá acabando e a tarefa tem muita coisa prá ser feita ainda, algo terá que ser sacrificado. E na grande maioria das vezes, o que se sacrifica é a qualidade (que é o que entendi do vídeo quando diz que é entregue porcaria, e é mesmo), entrega qualquer coisa, só prá arrastar o card e todo mundo "ficar feliz". Quem faz gestão não consegue entender que a estimativa de prazos de projetos inovadores não é resolvível, nem tem cerimônia que faça ficar determinístico.

[herreramartos]

isso é algo que passa na cabeça de todo dev em algum momento, eu vejo valor no que esse pessoal "não dev" entrega pro time, mas a parte dos processos podia ser muitas vezes revisitada, e também flexibilizar esses prazos de 2 semanas, já deixei de iniciar coisas cruciais porque era grande de mais pra por naquela sprint, GENTE!!!! quanto mais rapido começar mais rapido termina BORAAAA!!!!

[paulofigueiredo]

A última empresa que trabalhei, tinha tanta reunião, que atrapalhava a produção. Era daily, sprint review, retrospectiva, refinamento, reunião sobre isso, sobre aquilo e etc. Difícil o dia que não tinha umas duas reuniões.

[Augusto_Tenorio]

Vc falando e eu lembrando do meu trabalho burocrático em.uma distribuidora de eletricidade aqui de Pernambuco. Eu era fiscal de obra e, com seis meses de empresa comecei a ficar muito tempo dentro do escritório, sejdo obrigado "algumas" vezes a fiscalizar as redes sem ir ao local. Mais seis meses e comecamos a ter reuniões semanais nas segundas às 9 h (o trabalho iniciava as 8 h e eu ja estaria no ponto da obra terminando um serviço). Depois as reuniões comecaram a se reproduzir para as quartas-feiras de manhã também, e com pouco mais de 1, 5 anos de empresa, fui demitido por não dar conta dos serviços que abriam o tempo todo, mas as chefias ao invés de ajudarem, atrapalhavam...

[msdsdev]

Salve Gustavo.

Vim lá do Papinho Tech #043 com o Prof. Isidro, mas te conheci pelo react que o @manodeyvin fez desse mesmo vídeo.

Muito bacana esse formato de vídeo aí. Vc falando algo de tech caminhando num parque, e ainda aqui da cidade onde moro. O parque Barigui fica lindo demais em vídeo. Se vc não fala eu não conseguiria identificar. kkkk.. Top demais!

Já vou pedindo desculpa pelo textão mas me deu vários insights aqui! 😅

Trabalhei numa empresa que tinha alguns Scrum Master e realmente, no fim das contas depois de certo tempo ninguém sabia o que faziam, onde viviam, o que comiam. Porém, apenas uma delas, no projeto que trabalhamos, a mina fez um bootcamp focado em Scrum.

A mina era braba. Salve Marcela se tiver vendo esse comentário! ✌

Colocou a gente pra rodar um projeto em equipe utilizando o Scrum e suas cerimônias.

Aprendemos muito. E ela falava que, o trabalho dela só acabaria quando as equipes já tivessem aprendido de fato o que é o Scrum. E foi o que aconteceu. Depois disso, ela sumiu. Foi pra outros projetos e acho que até saiu da empresa.

O problema disso é que, depois ninguém mais utilizava o Scrum 100%. Acho que nem 30% direito..

Só fazia dailys de mais de 30 minutos, as vezes 45 ou 1h (com o cliente, devs, PO, Gerente, etc.. se não fosse home-office até o porteiro, a tia do café e da limpeza tava lá), e no máximo um peer-review. Nem poker planing a gente tinha pra poder dar pitaco na pontuação.

Até tinha a pontuação nas demandas, mas ao invés de ser o time fazendo, já vinha lá de cima (top-down) e eles entendiam que a pontuação era inteiramente e puramente PRAZO de entrega da task.

Não era considerado o grau de dificuldade da demanda, muito menos débitos técnicos do dev. Era o caos!



Abraço!

[alexandergroove]

Muiiiito bom! Lembro da frase: o rei está n%& ! Todos simplesmente aceitam aquela verdade e seguem. Um novo processo atrás do outro para justificar a incompetência. O princípio do manifesto ágil no scrum é magnífico, mas já virou bagunça. Trabalho com projetos de engenharia e realmente... cortei tudo isso que vi que não serve p nada... é até agora em mais de 2 anos não faz falta.

[LuisFernandoGaido]

Você me ganhou por completo na hora da sua interpretação da reunião diária.

[sonsoriak]

nao entendo de engenharia de software (preciso estudar), mto bom video e grande parte das coisas fazem sentido.
Vivi num contexto mto simples de desenvolvimento (so gestor, q é um prog pleno ou sênior + devs), imagino que em um ambiente de DEVS PLENOS OU SÊNIORS, oq vc diz a respeito das reunioes faz sentido pra mim. Mas eu vi (e fiz) desastres, dificuldades erros de comunicação no desenvolvimento com trainees e jrs que foram percebidos nas dailys. As vezes o dev vai ter dificuldade e não vai comunicar, vai tomar decisão errada sozinho, enfim...tudo pode acontecer quando o time de desenvolvimento n tem tanta proficiência, qdo n se é tão...profissional. É smp bom ter um acompanhamento nesses casos

[chpsilva]

18:10 O que você descreveu é, em linhas gerais, o que já se fazia no waterfall. Cada vez mais as pessoas chegam à conclusão de que o waterfall na realidade não era tão ruim, apenas precisava ser melhorado em vez de ser jogado fora para todo mundo obrigatoriamente ter que abraçar essa insanidade chamada movimento ágil.

[jessandro]

Na vinha curta vida trabalhando com desenvolvimento, o que posso cravar na pedra 'e que metodologia agil 'e uma forma de tentar forçar a entrega de uma funcionalidade nova a cada duas semanas.

[CodeArtisanGPS]

"Não produzi nada ontem, o que vou dizer na daily?" -> Desenvolvimento é arte, codar das 8 as 18 NÃO É SER PROGRAMADOR ( Exceto por períodos de hiper-foco ), mas via de regra, codar é o de menos, nosso trabalho é conceitual/estratégico. Algo como: Codamos muito 2 ou 3 horas por dia, o resto é desenho. Do contrário, é ficar dando marretada até funcionar. Muito melhor ter um bom mapa mental e quando for codar, codar um produto decente, não código marretado... Tem dia que não vai sair qualquer coisa, adianta ficar na frente do pc? Só matando o tempo e enrolando, empurrando com a barriga. Não produziu nada em um dia? Ótimo, perceba que você não está na vibe e vá meditar! Depois volta com a cabeça leve...

[josealysson]

Odeio daily só serve pra micro gerenciamento que daria pra fazer olhando o board, sprint review a mesma coisa

[PablinoSabloque]

Poxa, achei bacana que nosso campeão de CS e CrossFire também é um entendedor de desenvolvimento e programação, nos ajudando com dicas!! Parabéns FalleN, tamo junto!

[kleberbrum]

Eu concordo em partes e discordo em partes também. rsrs
Se o Scrum for bem utilizado, ele é muito bom. O problema é que as empresas acham que projeto ÁGIL é projeto que vai entregar mais rápido kkkk. Eles acham que fazer daily todo dia já é considerado Scrum. O problema é mais cultural/conhecimento do que a metodologia em si, que eu acho muito boa. Scrum Master é um papel importante quando ele sabe que a função dele é resolver impedimentos da equipe, seja burocráticos seja técnicos e até pessoais. P.O. faz o funcional e cuida das entregas e comunicação com o cliente. E Dev bota a mão na massa e faz acontecer. Daily não é status report, é apenas um alinhamento dos Dev's pra saber se esta tudo andando bem conforme planejado na Planning. Eu gosto muito de trabalhar com o real Scrum. Mas de fato pouquíssimas empresas sabem como funciona. O problema não é a metodologia, mas sim as pessoas despreparadas que não sabem usar.