Trabalho na área de TI a mais de 20 anos... e juro.... me sinto aliviado em ver este video... achei q era a ovelha negra... mas agora percebo que mais pessoas sofrem desse mau.... 🙏🏻
Cara, eu também estava com essa impressão, de que eu estava totalmente por fora, e eu não teria mais espaço se não me acostumasse as horas perdidas nos "rituais", mesmo que a data de entrega do artefato já tenha estourado... Que vídeo lindo..
É como acabei de postar no linkedin, modismos, modismos é mais modismos, lá eu falo do tal DEVOPS, caraca véio, engenharia de software neles, tá tudo lá, para que alimentar estes coachs/gurus de tecnologia?
O mercado de TI no Brasil está engatinhando em planejamento de projetos... Os profissionais que dão coach do assunto então, coitados... Piores ainda! Não tem metodologia que funcione sem um bom trabalho de gestão de produtos e planejamento.
"O foco não são as ferramentas, não são as cerimônias... o objetivo não é atingir um determinado número em um gráfico arbitrário, é entregar valor". Perfeito.
02:42 - Livro Refactoring - Martin Fowler 02:50 - Livro Cystal clear - Alistair Cockburn 02:56 - Livro Adaptive software development - Jim Gighsmith 02:59 - Livro Test driven development 03:03 - Livro Extreme programming 03:33 - Livro The pragmatic programmer 03:50 - Livro Shlaer-Mellor 04:08 - Livro Clean code 04:15 - Livro The Scrum Guide 22:45 - Livro Como mentir com estatísticas
Sou empresário e gestor da área de TI, além de desenvolvedor e arquiteto de software. Você realmente é impressionante e consegui me fazer concordar em 90% do seu raciocínio. Sigo os valores do manifesto ágil, Lean e Kaizen não só na vida profissional mas também na vida pessoal e isso me trouxe horizontes que nunca imaginei. A verdade é simples, ágil, Lean e kaizen é cultura, estilo de vida, mas onde divergimos é nas metodologias, que apesar de desnecessárias para mim hoje em dia, são práticas para ensinar valores e padrões as pessoas envolvidas (time, empresa,etc). Daily ensina sobre interações entre indivíduos, o que é importante alinhar e dar transparência ao trabalho. Planning fala muito mais sobre o trabalho que se tem a fazer é o comprometimento das pessoas com ele e inclusive entre elas. Isso são exemplos de scrum, já kanban fala de produção puxada (iniciativa) fluxo de valor e gestão visual. No kaizen temos a melhoria contínua que pode ser através do PDCA, porém contraditório ao que você afirma e desafirma, como você ajusta o processo/fluxo sem métricas? Ainda sobre métricas, hoje como desenvolvedor de software consigo saber pelo menos 80% de toda a implementação técnico que vou fazer conversando ou lendo uma documentação. Com base na experiência consigo aferir o tempo necessário para desenvolver, e graças ao Lean que me abriu horizontes me tornei multidisciplinar conseguindo entender todas as etapas do processo e aferir o tempo médio para cada tendo assim o leadtime da entrega de valor. Falando de profissionalismo, pelo menos aqui em Brasília o que se tem mais são amadores com currículos e certificações enchedoras de linguiça. Como gestor posso afirmar infelizmente que 90% do mercado são de profissionais imaturos fazendo da TI um parque de infância. Tem aqueles que conhecem teoricamente de tudo e se apresentam como os gedis da programação, mas na hora de botar a mão na massa e resolver o problema são os primeiros que correm e querem os maiores prazos. Não sou gestor babá e se precisae dar o exemplo, arregaço as mangas e mostro como se faz um código rápido, limpo e funcional. Software não é ciência exata, mas eu trabalho com código padronizado (sem muita frescura), e com isso consigo saber exatamente o que tem na classe sem abrir o arquivo ou até identificar onde está o problema sem perder horas ou dias debugando. Não sou nenhum ninja nem evangelista, sou uma pessoa determinada, com princípios, auto responsável e que sabe o que quer. Não tenho a mínima dúvida que você sabe de tudo que falei e que só quis polemizar um pouco o vídeo. Abraço!
Por isso mesmo eu prefiro trabalhar para mim mesmo, prefiro me responsabilizar pelo meu produto ou serviço ao ter que aguentar asneiras do mundo corporativo
Parabéns, expressou tudo o que sinto trabalhando na área de suporte. Equipes de desenvolvimento comemorando alguma coisa besta implementada, enquanto o core do sistema segue zuado, cheio de falhas, mas eles não tem tempo de evoluir pq precisam entregar outra funcionalidade besta que dá mais visibilidade para algum chefe.
Na realidade o time de dev não decide a priorização do backlog na grande maioria das vezes. E te garanto que 95% do time ideia retrô e review, além do excesso de ritos e excesso de interrupções para coletar status.
"Todo não programador sabe que se perguntar a um programador quanto tempo alguma coisa leva para ficar pronta e ele responder 200 horas, você sabe que em 200 horas, seja lá o que foi pedido, vai estar pela metade." (AKITA, 2019)
Trabalhei durante 6 anos como desenvolvedor e, mesmo sem usar metodologias ágeis, a empresa que trabalhava entrega resultado. Sempre segui essa mesma filosofia que o Akita falou: foco em resultados, boas práticas de programação e muita responsabilidade. Primeiro vídeo que vejo no canal e larguei a mão no "Inscreva-se". Parabéns!
Li o título e vim assistir indignado, mas acabei concordando com cada ponto do vídeo kkkkkkk Não fazia ideia da existência do manifesto, sempre trabalhei em empresas auto proclamadas de "ágeis", mas que pisava em todos os princípios. Recentemente me mudei para uma empresa que segue o manifesto muito bem, e agora percebo a importância desses valores.
@@BrunoSep182 Opaa, salve! Agora já somos dois na associação MQQSP - motoboys que querem ser programadores. Tmj! Haha Edit: Aliás, seu comentário tem 2 anos, então é provável que você já é programador.
Resumindo... Parte 1 de 2 -> 3 passos dentro de um loop... Repita ... --> passo 1 entender onde você está --> passo 2 dar um pequeno passo em direção a onde quer ir --> passo 3 avaliar o que aconteceu Até terminar... Parte 2 de 2 -> Quando encontrar duas ou mais opções: --> escolha aquela que torna as coisas mais fáceis de mudar no futuro. --> tome decisões que são mais fáceis de mudar no futuro. O problema é o Ctrl+c Ctrl+v ( entre o STP e o desenvolvimento de software )... são necessárias várias adaptações que quando realizadas funcionam muito bem... A propósito, qual metodologia/filosofia utiliza em sua empresa? Acredito que a resposta seja: uma metodologia própria, carregada de uma mistura das coisas boas que várias metodologias oferecem... com pessoas ágeis... É preciso saber filtrar o que cada forma de trabalho oferece e fazer adaptações... Acertei? Muito obrigado!
@@Akitando Excelente... Gosto de trabalhar assim... entender cada método, e aplicar o que há de melhor em cada um deles, para a minha realidade... valeu... :)
Como digo para os colegas aqui do trabalho : ainda teremos saudades do tempo do desenvolvimento em cascata. O ágil se transformou em uma burocracia sem fim. Uma verdadeira muleta para os enganadores.
5 лет назад+12
Akita, você conseguiu extrair todos os meus sentimentos, pensamentos e conclusões dos últimos anos, pois acompanhei o surgimento do manifesto para desenvolvimento e observei o quanto foi deturpado ao longo dos anos. Muito obrigado por conseguir compilar e organizar em vídeo! Sinto-me aliviado.
Meu herói! rsrsrs Muito bom ouvir alguém sensato! Há muito tempo eu já venho com uma sensação de "stranger in this town" em relação a esse assunto. Obrigado, você me confirmou que é a cidade que tem se tornado cada vez mais estranha e não eu. Sensação de alívio!
Há muito tempo o "agile" virou muleta, de entregas, transformações. Eu já passei por entrevista em que o entrevistador perguntou se eu era ágil, e atrelou ser ágil às metodologias. Por muito tempo vi o foco em entregar rápido, dar velocidade a sprint, vários gráficos querendo medir a velocidade da equipe, e nenhum kpi dizendo qual o ganho que está sendo gerado para o negócio. Esquecem que tombar para o ágil é muito mais mindset do que metodologia.
Nesse caso tem a questão corporativa, a maioria dos clientes tem prazos impossíveis e a empresa tem medo de perder clientes e acabam fazendo promessas que não vão conseguir cumprir.
Falou tudo o que muita gente precisava ouvir, estão criando jardins de infância atras de metodologias, enquanto o software deixa de ficar pronto. Muita gente dando aula de Scrum, consultores do Sebrae, e por ai vai, um monte de gente que nunca escreveu código nem tocou uma empresa de verdade dando aula de Agile.
Muito obrigado por esse vídeo, me identifiquei muito. Quando li o manifesto ágil pela primeira vez fiquei encantado, mas percebo que a maioria das pessoas confunde ágil com rápido e esperam que o produto seja entregue no menor tempo possível, sem considerar que algo bem feito, com qualidade e que seja fácil dar manutenção é muito mais vantajoso do que algo feito rápido e que a longo prazo terá um custo muito maior com manutenção.
eu racho o bico com essa Fabio Akita, kkkkkkk. Depois de começar a trabalhar com Scrum eu nunca imaginei que meus 4 anos servindo na cavalaria do EB seriam tão úteis kkkkk, podem acreditar kk
Olá Fabio, boa tarde e como vai? Cara eu sou de infra, mas tudo isso que falou no vídeo eu vejo acontecer em meu atual emprego. Perdem muito tempo com um monte de técnicas, Frameworks e metodologia para no final mostrar tudo em PPT com gráficos cheios de perfumarias para a diretoria com o mesmo resultado de sempre... Nenhum valor agregado, nada mudou no faturamento da empresa e só gastou o tempo dos analistas com reuniões diárias sem sentido. Resumindo, bullshit e dinheiro jogado fora com os profissionais perdendo o seu tempo fazendo estas reuniões e amarrando os processos com firulagem "não ágeis". Virei sei fã por ser direto, sem mimimi, adulto e mostrando o seu ponto de vista profissional da sua carreira que é longa e por isso sabe muito do bem do que está falando! Valeu pelo excelente vídeo e fui ágil em dar o like se inscrever e clicar no sininho para não perder seus próximos videos! rs Forte abraço!
Muito bom o conteúdo. De agora em diante pensarei diferente quando o assunto é "Ágil". A forma errada que falam sobre "ágil" é exatamente a forma que aprendi. Em artigos que aprendi sobre o assunto, não lembro em nenhum deles mencionar o manifesto. O pessoal só escrevem que ser ágil é fazer tudo em menos tempo e dão exemplo de várias técnicas de organização e ferramentas que aceleram o desenvolvimento. Depois de assistir ao vídeo e refletir sobre o que estão escrevendo, você percebe que tem bastante desenvolvedor/empresa ágil caminhando para o lado contrário do manifesto ágil. Por exemplo: - Desenvolvedores focando nas ferramentas, processos e na linguagem de programação mais "hipster" do mês. - Focando mais na documentação abrangente, dinâmicas de grupo, reuniões enquanto nem iniciaram o desenvolvimento do software. - E quando as coisas saem fora do controle, buscam outras ferramentas, processos e linguagem ou contratam uma consultoria que entregam ágil :D.
Vagnerlandio Nunes isso esta acontecendo na minha facul, só reunião, palestras motivacionais, ferramentas e metodologias para criar o software, prototipar a ideia e os requisitos do software em caixa de papelão, definir o modelo de negocio com trello, mas ate agora nenhum grupo começou a botar a mão na massa pra desenvolver o software, pq tem cumprir esses cronogramas do curso kkkkkkkk
Alguém traga um Oscar para esse Akita! Cara, você falou tudo o que eu sempre pensei sobre as baboseiras numerológicas de gerenciamentos de projetos. Parabéns pelo vídeo!
5 лет назад+17
Me senti representado, sou Adm e lean e kanban são coisas antigas para mim. Tbm passo raiva com os “gurus” que enganam a galera com sambarilove de agilidade.
Sou certificado com a PSM1 como SCRUM master, e concordo com tudo que foi dito, o individuo precisa ser ágil na sua essência, porque não são rituais, nem formulas mágicas que fazem a pessoa ser ágil, na época a minha falta de experiência me fez brilhar os olhos com a metodologia, mas depois aplicando em uma agência de marketing, e depois ajudando uma software house cheguei nessa conclusão, como as pessoas vão se organizar para dar o resultado não importa, desde que se consiga avaliar se está dando resultado.
Primeiramente agradeço o vídeo muito bom para abrir os olhos de muita gente. Sou desenvolvedor há muito tempo e pensei que estava ficando louco. Tudo que disse é verdade sinto na pele quando a empresa usa essas metodologias... que a procupação de ser ágil e estar tudo perfeito no Jira ou em qualquer outra ferramenta desse tipo é mais importante do que agregar valor... Quando dinheiro e tempo que se perde jogando Planning Poker e fingindo que está planejando algo sem entregar nada no final... Gostatei muito vídeo parabéns!
Que vídeo esclarecedor! E como você disse: "Não começar algo inseguro demais é ser Ágil". Se puder faça um vídeo sobre componentização de software, gostaria de saber o que pensa sobre isso. Abraço e Parabéns pelo video!
Dei pause no meio do vídeo só pra "plantar" um like!!! Trabalho com TI (Infra) a quase 8 anos e estou migrando para desenvolvimento, seu canal tem me ajudado bastante. Parabéns pelos conteúdos de qualidade!!!
Cara muito bom seu vídeo, tenho quase 10 anos na área, nem chega a ser metade de muitos aqui, mas me identifico plenamente com seu modo de pensar. Depois de alguns anos decidi entrar mudo e sair calado. Não consigo mais depositar meus esforços em projetos sem escopo definido, com data de entrega e com metade da sprint com analise funcional rasa, com 20 mil pontos em aberto e no final das contas, pesando muito mais nas costas do programador.
Nunca esteve tão atual esse video. Estou revistando o video 2 anos depois daquele boom e polêmica que esse video gerou na comunidade agil e percebe-se cada vez mais o qto. ainda continua verdadeiro.... show
Parabéns pelo video Akita! Há muito tempo venho rejeitando essas metodologias (inclusive sendo ulgado por isso). Assim como mencionou, desenvolvimento de software é um processo criativo , é uma organismo vivo sujeito a adaptações constantes, é estranho querer estruturar em processos bem definidos algo que é de uma natureza diferente. Adicionar regras/processos para quantificar e dar um ar de profissionalismo não resolve o problema, só adiciona uma camada para quem não quer assumir os riscos se esconder mais facilmente. Infelizmente, existem os riscos associados ao desenvolvimento, nem sempre é possível estimar com precisão. Como sugestão para deixar seu ponto ainda mais claro, seria vc legal falar sobre o que o Uncle Bob já dizia a muito tempo: Profissionalismo no desenvolvimento de software.
Eu acho que falei no meu outro vídeo. "Estimar com precisão" não existe. Tem outra palavra pra isso: Adivinhar. Profissionalismo é estimar e tentar alcançar o objetivo, e se não for conseguir, avisar com antecedência pra gente negociar enquanto ainda está em tempo de ajustar o percurso.
Akita vc é fantástico!!! Comecei a ver seus vídeos e foram um vdd tapa com luvas de pelica. Agora estou maratonando os vídeos do seu canal! Muito obrigada por compartilhar seu conhecimento sabiamente!
Então, a única prática que adoto é o feedback constante. Dou preferencia pelos e-mails devido validade legal e por todo mundo já saber usar. Como comentado, estimar prazos é uma tarefa complicada, e eu mesmo tenho certa dificuldade em prever, então faço o mínimo que esperaria que fizessem se eu estivesse na liderança: um relatório curto resumindo oq eu estou ou não fazendo e porque. Para que quando peçam algo pra meu líder, ele ao menos saiba explicar com que tarefa estou perdido. Se tem uma coisa que aprendi em alguns anos de experiência, é que ser previsível e manter tudo bem documentado são as habilidades mais essenciais e genéricas, que se aplicam a qlqr tipo de trabalho. Qlqr coisa que não envolva deixar a equipe inteira ciente do que está sendo feito e porque, para mim é perda de tempo.
Nunca entendi as empresas de software utilizando metodologias de produção ou engenharias. Sempre imaginei " mas que p**** esses caras estão fazendo???". Agora tudo faz sentido.
Não sou programador, sou ti infra mas encontrei no Fábio Akita um ótimo ponto de reflexão nos trabalhos, não só em tecnologia e programação, mas na vida. Ele tem uma didática sensacional e boa base naquilo que expõe, obrigado pelos seus vídeos.
Os métodos só são válidos quando conseguimos adequá-los a realidade do negócio. Acho que o KANBAN, SCRUM, etc são super interessantes, e pode ser usado em diversas áreas, mas engessá-los não é o caminho. O problema não é a ferramenta, é sim a mentalidade engessada de alguns que a aplicam.
Ponto muito bem levantado meu caro Fabio Akita. Se a preocupação está mais na metodologia, nos numeros (q podem ser mascarados), nas entregas por entregar e o valor da entrega o problema que está sendo resolvido e a forma que está sendo resolvida vira coadjuvate pega tudo e joga fora. Admiro muito o que você faz aqui no youtube. Obrigado por compartilhar sua opinião, um grande abraço,
O vídeo mais realista e mais direto sobre todo esse marketing sobre metodologias ágeis nas empresas. O que vi constante nas empresas por onde passei é que a maioria delas fazem o que foi dito aqui. Coloca o kanban, algumas métricas que eles criam sei la baseado em que, e agora em uma passe de mágicas a empresa e as equipes são ágeis. E agora os devs e todos envolvidos nos processos que na maioria das vezes são engessados, estão mais rápidos, mas com o passar de algumas horas eles (diretores, ceos e todos acham simples desenvolver softwares) descobrem que adotar ferramentas e falar jargões da modas não os deixam mais ágeis, por diversas razões. Parabéns pela chamada de responsabilidades de ambos os lados que trabalham com desenvolvimento de software.
Akita, o tom "hater" generaliza suas observações e, no meu ponto de vista, acaba com qualquer tipo de mensagem que você queira passar :slightly_smiling_face: Obviamente "instalar ágil" ou se "mostrar ágil" é atrativo e chama a atenção. O mundo é feito de ondas que se tornam moda e o ágil está neste momento. Como qualquer movimento, você tem bons casos e outros que não são. Participar das conferências ajuda a entender o que está acontecendo e talvez seja interessante você compartilhar sua visão na comunidade. Você começa resgatando os valores do manifesto, mas depois todos os comentários ficam soltos (ex: o que microgerenciamento tem a ver com ágil? desenvolver software não passa por um fluxo? como seu sei se estou entregando ~ pelo achismo? como lidar com prazos em processos criativos?) e perde a essência do tom crítico aos métodos! No final eu fiquei me perguntando: será que era mais fácil ele ter dito em 5 minutos que o XP e os seus princípios refletem o que ele entende como o "ser ágil"? Acho que sim.... Uma mensagem que você aborda, mas não aprofunda é: como o tal movimento ágil tem tratado a gestão de desenvolvimento de software? Para mim, esta seria a riqueza do seu conteúdo e da sua experiência, mas o vídeo não entregou uma resposta estruturada para esta pergunta.
Não está errado, como o que mais se acha hoje ainda é sales pitch de agile o objetivo desse vídeo não foi ser uma aula nem nada disso, eu disse que ia ser um rant e foi um rant :-) Quem sabe mais pra frente eu falo sobre os aspectos que realmente fazem sentido de uma forma mais estruturada.
Interessante o debate e acrescento ao coment do Rapha Albino: Metricas de resultado seriam de fato importantes estar aqui presentes para embasar tudo o que foi dito. Aplicando tudo o que é abordado com agilidade, se tem qual real valor, uma vez que o movimento é deturpado? NPS de clientes, indicadores de retrabalho, rentabilidade de contratos... importante em minha opinião ter tudo isso, e claro, inclusive quando se coloca o XP na jogada tbm é valido.
galera o fato é que modinhas de longe são fatais para os projetos. Eu mesmo sempre utilizo uma metodologia própria de estudar, aplicar e validar antes de sair utilizando para todo quanto é tipo de projeto. Isto gera polêmicas mas modinhas só servem na minha opinião para preencher lista de requisitos de empresas de TI
Eu ia postar algo nesse rumo, mas você já o fez e fez melhor do que eu faria. O pior é que induziu um monte de desavisados/ignorantes/juniores a ignorar a agilidade.
Obrigado por compartilhar o material. Concordo com você principalmente no ponto em em que você toca no assunto "Medo e Insegurança". Realmente, é o que mais acontece, um programador promete que irá fazer no "X" tempo, só que depois que inicia o projeto, o fator tempo vai para "X2". Importante é ter sim as expectativas alinhadas e entregar o que prometeu no tempo acordado. do contrário é chute!
CONTEÚDO ABSOLUTAMENTE AUTÊNTICO! Parabéns por ELEVAR A BARRA DA CONVERSA! 18:38 resume demais! Muito bom! Me lembra aquele conceito apresentado por Ralph Waldo Emerson : “Quanto aos métodos, pode haver mais de 1 milhão deles, mas são poucos os princípios. Aquele que souber os princípios pode selecionar com sucesso os próprios métodos." O negócio é resolver os desafios que importam para o objetivo da melhor forma possível, da forma mais adequada a meta!
Cara, muito bom. Eu sou estudante de Engenharia Mecânica, acompanho o canal há pouco tempo e tenho me identificado com grande parte das suas ideias. Durante o meu estágio presenciei e fui parte de uma tentativa falha e sem resultados da implementação de "novas metodologias" dentro da empresa, inclusive com a contratação de consultorias externas pra "auxiliar" nesse processo. Na minha percepção, aquilo só serviu pra vender a ideia modernização de processos usando algo que claramente não estava adequado ao que a empresa produz (equipamentos mecânicos e hidráulicos) e nem às ferramentas que esta utiliza.
Virou mais uma moda na verdade, pois todas as metodologias de Design que aprendi na faculdade e sempre usei lindamente pra criar produtos físicos e virtuais são a mesma coisa com um nome novo (e muito mais burocracias e reuniões que roubam tempo de produção). Sem contar que pra determinados produtos uma metodologia é melhor que outra, eu ainda prefiro escolher a metodologia de acordo com os requisitos do projeto. Mas né... ao invés de Designer de Produto, Gerente de Produto, ou Gerente de Equipe tenho que falar que sou "Product Owner, Master e blablabla" senão não consigo recolocação. Mil vezes puff. É muito foco em cumprir etapas e pouco foco no cliente final, como resultado temos produtos bem medianos, mas cheios de nomes chiques em inglês. Tem os casos também que o gestor é alguém que não entende patavinas de Design ou Development, pra mim não faz sentido algum um coach que não entende da área rs. O mais triste é nas vagas de emprego medirem os candidatos pela quantidade de softwares que eles dominam e se eles aplicam Ágile... sinceramente é possível contratar um micreiro que mexe em mil programas e leu sobre Ágile, mas não entende absolutamente nada de processos, funcionalidade, experiências e estética. Nem pedem mais curso superior... sendo que cérebro e capacidade criativa não pode ser medido em quantidade de skills. Quem cria é o Designer, o Programador e estes criam o fluxograma, o desenho técnico e sketches na mão se for preciso.. agora corta a energia elétrica pra ver se um micreiro resolve alguma coisa kkk. CARA TEU VÍDEO MERECE UM PRÊMIO!!! Assino embaixo de tudo o que você disse! Quem perde é a empresa que limita o potencial dos PROFISSIONAIS DE VERDADE.
Semana passada conversei com um amigo sobre o trabalho dele. Perguntei o que ele fazia na empresa onde trabalha. Pensei " ele é analista de sistemas, deve trabalhar com códigos ou banco de dados". Minha decepção quando ele contou que só enrola, e que sabe tudo de metodologias ágeis, enquanto escrever um simples hello world ele não faz. Notei que , mesmo eu batendo cabeça aqui pra aprender como se desenvolve sistemas, estou muito mais engajado do que um show man das agilidades. Lembrei do cara do ligue jhá.... Ah, e mais um escrito. Gostei dos assuntos.
Ganhei um treinamento de Lean h na empresa, parece que o Akita já tinha metaforado cada palavra do consultor. Fico impressionado como a galera empurra qualquer coisa e consegue vender. Enquanto a gente estava fazendo as atividades eu só me perguntava, A gente é burro demais se a gente se conversasse não precisava dessa bulshitagem
Após 5 anos, seu vídeo contínua sendo uma utilidade e verdade tão absoluta quanto. Leciono em uma Universidade, e o que pedem é para falar sobre essas metodologias ágeis, Scrum e Kabam, etc. A ementa pende para assuntos teorizados demasiadamente. Ao fim, o aluno que termina o semestre igual aquando começou, sem entender o que realmente importa ao meio desses mares de metodologias que empresas tentam vender. Não que, não seja importante os princípios, mas tentam seguir como se fosse uma regra, e acaba acontecendo o mesmo com a bíblia, cada um lê e interpreta como quer e logo vira uma verdade. Parabéns novamente pelo vídeo.
Muito bom seu vídeo, mas foram 42min falando genericamente sobre os problemas atuais da 'agilidade'. Podemos entrar em detalhes de alguns pontos? Por ex: O que voce acha da utilização de uma ferramenta como o JIRA, em conjunto com um quadro físico (onde programadores e QA tem que ficar atualizando os 2 constantemente pra agradar o gestor)?
Isso é ridículo e uma tremenda perda de tempo... na minha empresa tentaram vender isso. Eu com lider do time, ignorei. Tremenda perda de tempo e desperdício.
Fábio, parabéns pelo canal, é mais um projeto que você tem feito brilhantemente. Fui um assíduo usuário do Akita on Rails vindo do PHP e sempre gostei da quantidade de coisas que você faz bem ao mesmo tempo. Programo há muitos anos estou em uma empresa também há anos e já faz tempo que sinto que fiquei pra trás, nunca gostei de estudar a fundo as coisas, mas sim fazer tudo funcionar... Agora nós estamos em processo de migração para microserviços e microfrontends inclusive. Os códigos tem ficado tão estranhos para os old programmers, tudo tão diferente que eu nem sei o que eu perdi. Se você pudesse listar uma ordem de estudos, em termos de livros ou outros materiais, para que pudessemos retomar para a atualidade quais seriam. []'s
Perfeito! Bom saber dos teus vídeos. Lembro das tuas palestras no Centro de Convenções SulAmérica nos eventos da Locaweb. Era revolucionário para o mercado da época! E de fato, se perdeu totalmente. Ótimo vídeo!
Fabio Akita, não é exatamente relacionado ao tópico, mas você poderia comentar/talvez fazer um vídeo sobre insegurança de um dev jr? Porque pessoalmente eu aceitava quase todos os prazos que me estipulavam, com medo justamente de ser demitido, pois sempre seriam os elos mais fracos, e também não tinha ideia de como estimar o prazo, pois praticamente não tinha a ideia do que precisava ser feito, de ponta a ponta. E ai logicamente ferrava tudo, projetos atrasavam, bugs pra todo lado e ai talvez aparecer a tal necessidade de um couch de agile. Talvez eu estivesse aceitando projetos e tasks que eu não deveria estar pegando? Se for o caso, como iria evoluir só pegando "tasks de juniors"? No caso é simplesmente aceita, e estuda até conseguir orçar melhor ou tem algo que eu não enxergava?
Falou tudo que eu sempre senti, mas eu nunca soube dizer. Vejo bastante, equipes durante mezes inteiros atoladas em reunioes e procedimentais interminaveis, indo trabalhar todo dia, muito mais para cumprir uma liturgia, um ritual, um procedimental, do que produzir o software em si. E no processo, quem produz de fato, acaba tendo que levar nas costas uma turma que só serve para burocratizar e politizar a producão.
Planning que dura 1 dia inteiro .... sprints que duram 1 mês porque tem tanta reunião durante a semana que não sobra tempo pra programar ... e isso é chamado de "'ágil". É o famoso "ágil pra inglês ver".
Como catarse o vídeo é excelente! Inclusive dá vazão às minhas próprias frustrações com a implementação da "cultura ágil" em empresas. Acho que vale um outro vídeo mais didático sobre métodos como XP ou sobre os conceitos do manifesto no geral.
Fantástico encontrar profissionais com conteúdo com a qual nos identificamos. É como ouvir ecos próprios pensamentos traduzidos de forma clara. Excelente trabalho. Você é simplesmente "oohh caaaraaa"!!!
Muito bom, vim aqui justamente porque a empresa em que trabalho está tendo muitos problemas com o Agil, ou a má interpretação dele, temos mil ferramentas que tem a função de dar visibilidade das entregas e nos "ajudar" a melhorar como time. Durante meses essas ferramentas apontam que nosso time é excelente, vem melhorando cada vez mais, fomos de uma nota 5, para 6, para 7, para 8, nota que foi muito comemorada, porém, quando alguém de cima parou para questionar/analisar as nossas entregas, não temos nada de concreto feito em meses. Ou seja, o time aprendeu a trabalhar de uma forma que nos garante uma nota boa e garante que a gente possa apresentar essa nota e falar como o time é bom e tem evoluído, mas é o ponto que o Akita trouxe, é fácil torturar números com o objetivo de chegar a uma conclusão desejada, embora não tenha nenhuma relação direta. Que poha quer dizer um time nota 8 se não tem nada funcionando?
Maratonando me deparei com esta pérola, Obrigado. Nunca foi um exímio programador, no entanto sempre consegui ver além do projeto, ver o todo, e harmonizar o desejado com o possível a se fazer. Isso me rendeu a responsabilidade de gerenciar alguns projetos, em algumas empresas, e com a idade acumulando foram também acumulando "métodos pessoais" para ancorar os 'Stakeholder' a realidade. Excelente vídeo, novamente...
Transparência é o que falta!!! Empresas querem muito mais essas numerologias do que resultado real, digo até a empresa clientes desses ágeis mesmo. O gerente mostrando números a gerência, e a gerência fica feliz porque isso tudo é mais fácil, e exibe status, aparência de qualidade e produtividade.
A dois anos atras vi pela primeira vez esse video, a época eu trabalhava em uma startup que praticava um "agil" a sua maneira ... eles tinham seus processos e adptavam o que lhes interesava do scrum e dava super certo, era muito bom, mudei de trampo passei por lugares que aplicavam umas mais outras menos o scrum, e depois de dois anos esse video ta mais atual que na época que foi lançado.
Estou entrando na área de T.I e atualmente trabalho como técnico de enfermagem no setor de UTI e realmente tudo que foi comentado neste vídeo é uma grande realidade, devemos ser profissionais resolutivos a todo momento independente do área que se atua, sempre buscando uma alta performance, sem esperar elogios por isto.
Melhor vídeo do ano ! Muito bom Akita, tenho exatamente a mesma opinião. Sempre fico surpreso com como conseguem complicar e "empacotar" as idéias originais de forma absurda pra poder vender "Ágil"
Ok. Eu pensei que já tinha consumido o teu melhor material, mas tu se superou. 👍 Mais uma vez, obrigado por falar o que eu sempre não consigo por não conseguir organizar as ideias dessa forma.
Interessantíssimo. Tentei apenas uma vez aplicar metodologias de desenvolvimento de software e, para não supresa, deu no resultado mais conhecido, fracasso. Desde então passei para esse "ágil tradicional" (ou raiz, rsrs) aí, sem saber, seguindo basicamente estas 4 regras básicas (que ninguém me disse na faculdade de engenharia que existiam). Legal saber... Valeu pelo vídeo.
Sou universitário de engenharia de produção e esse vídeo é melhor doque aulas de muitos doutores na área na minha opinião, parabéns pela qualidade Akita.
Entendo e compreendo muito sobre este tema e o que acontece em empresas de software, mas tendo uma ótica voltada para empresas de serviço, quando pegamos uma ferramenta simples faz a diferença em toda a operação, igual ao vídeo que você mesmo disse a alguns dias a pratica leva à perfeição que neste caso, sim a pratica de ferramenta específica para a operação faz a empresa chegar a um patamar que não é apenas esperar o cliente entrar e sair sem saber o motivo. Com tudo deixo bem claro que quando tem um propósito para entregar faz a operação ser ágil, mas apenas o propósito em si não faz milagre e por alguns motivos que a minha startup encontrou está dor e estamos solucionando ela. Claro, este é meu ponto de vista e de total responsabilidade descrita pela minha pessoa. Tenha uma boa noite.
@@KubernetesEverton com coach nem tanto, apesar de existir agile coach. Porém, ele faz essa relação mais pela característica de "modismos" que ambas tem, com buzzwords, etc...
Dúvida pra um possível próximo episódio: por onde você acha que podemos começar a questionar as práticas atuais da empresa? É mais importante que a empresa pare de usar métricas arbitrárias ou que nós programadores ignoremos tais números?
![Chicken P - People's Favorite (Remix) [Feat. 42 Dugg] (Official Video)](http://i.ytimg.com/vi/a6Bn8FEtxmY/mqdefault.jpg)
Em setembro do ano passado eu expliquei o básico de "agilidade" sem chamar de Ágil. Aprendam: ruclips.net/video/akKRtjIqRjs/видео.html
Adaptativo.
Quando os "agiles coach" chamam pra mais uma reunião desnecessária me sinto num episódio do The Office
exatamente isso!!
Já desconfio só pelo fato de alguém ágil fazer uma reunião
Hahahahahah, se as reuniões forem hilarias como as do Michael até vale a pena 😂
Exatamente kkkk
🙄 nem me fala e a única coisa que acertamos é apenas o horário da próxima daily
A coisa mais fácil do mundo é colar um post-it na parede, a coisa mais difícil é tirar ele de lá no final do trabalho kkkkkkkkkkkkkkkkkkkk
uheauaehueah Boa
🤣🤣🤣🤣🤣🤣🤣
Muito sábio!!! auauh
Mais fácil e mais ridículo :)
Descreveu a vida do ser humano
Trabalho na área de TI a mais de 20 anos... e juro.... me sinto aliviado em ver este video... achei q era a ovelha negra... mas agora percebo que mais pessoas sofrem desse mau.... 🙏🏻
Eu sou um pouco mais novo na área kkkkk mas sempre achei isso kkkkkkk
Somos 2!
Cara, eu também estava com essa impressão, de que eu estava totalmente por fora, e eu não teria mais espaço se não me acostumasse as horas perdidas nos "rituais", mesmo que a data de entrega do artefato já tenha estourado... Que vídeo lindo..
É como acabei de postar no linkedin, modismos, modismos é mais modismos, lá eu falo do tal DEVOPS, caraca véio, engenharia de software neles, tá tudo lá, para que alimentar estes coachs/gurus de tecnologia?
O mercado de TI no Brasil está engatinhando em planejamento de projetos... Os profissionais que dão coach do assunto então, coitados... Piores ainda! Não tem metodologia que funcione sem um bom trabalho de gestão de produtos e planejamento.
"O foco não são as ferramentas, não são as cerimônias... o objetivo não é atingir um determinado número em um gráfico arbitrário, é entregar valor". Perfeito.
Estou passando por isso... o meu chefe é "agile scrum dungeon master" das reuniões, mensagens e e-mails desnescessários...
02:42 - Livro Refactoring - Martin Fowler
02:50 - Livro Cystal clear - Alistair Cockburn
02:56 - Livro Adaptive software development - Jim Gighsmith
02:59 - Livro Test driven development
03:03 - Livro Extreme programming
03:33 - Livro The pragmatic programmer
03:50 - Livro Shlaer-Mellor
04:08 - Livro Clean code
04:15 - Livro The Scrum Guide
22:45 - Livro Como mentir com estatísticas
Sou empresário e gestor da área de TI, além de desenvolvedor e arquiteto de software. Você realmente é impressionante e consegui me fazer concordar em 90% do seu raciocínio. Sigo os valores do manifesto ágil, Lean e Kaizen não só na vida profissional mas também na vida pessoal e isso me trouxe horizontes que nunca imaginei. A verdade é simples, ágil, Lean e kaizen é cultura, estilo de vida, mas onde divergimos é nas metodologias, que apesar de desnecessárias para mim hoje em dia, são práticas para ensinar valores e padrões as pessoas envolvidas (time, empresa,etc).
Daily ensina sobre interações entre indivíduos, o que é importante alinhar e dar transparência ao trabalho.
Planning fala muito mais sobre o trabalho que se tem a fazer é o comprometimento das pessoas com ele e inclusive entre elas.
Isso são exemplos de scrum, já kanban fala de produção puxada (iniciativa) fluxo de valor e gestão visual.
No kaizen temos a melhoria contínua que pode ser através do PDCA, porém contraditório ao que você afirma e desafirma, como você ajusta o processo/fluxo sem métricas?
Ainda sobre métricas, hoje como desenvolvedor de software consigo saber pelo menos 80% de toda a implementação técnico que vou fazer conversando ou lendo uma documentação. Com base na experiência consigo aferir o tempo necessário para desenvolver, e graças ao Lean que me abriu horizontes me tornei multidisciplinar conseguindo entender todas as etapas do processo e aferir o tempo médio para cada tendo assim o leadtime da entrega de valor.
Falando de profissionalismo, pelo menos aqui em Brasília o que se tem mais são amadores com currículos e certificações enchedoras de linguiça. Como gestor posso afirmar infelizmente que 90% do mercado são de profissionais imaturos fazendo da TI um parque de infância. Tem aqueles que conhecem teoricamente de tudo e se apresentam como os gedis da programação, mas na hora de botar a mão na massa e resolver o problema são os primeiros que correm e querem os maiores prazos.
Não sou gestor babá e se precisae dar o exemplo, arregaço as mangas e mostro como se faz um código rápido, limpo e funcional.
Software não é ciência exata, mas eu trabalho com código padronizado (sem muita frescura), e com isso consigo saber exatamente o que tem na classe sem abrir o arquivo ou até identificar onde está o problema sem perder horas ou dias debugando.
Não sou nenhum ninja nem evangelista, sou uma pessoa determinada, com princípios, auto responsável e que sabe o que quer.
Não tenho a mínima dúvida que você sabe de tudo que falei e que só quis polemizar um pouco o vídeo.
Abraço!
Ótima resposta! Parabéns!
Por isso mesmo eu prefiro trabalhar para mim mesmo, prefiro me responsabilizar pelo meu produto ou serviço ao ter que aguentar asneiras do mundo corporativo
"Ser ágil é ser adulto!". Excelente, obrigado Fábio.
Nobre Achiles
Parabéns, expressou tudo o que sinto trabalhando na área de suporte. Equipes de desenvolvimento comemorando alguma coisa besta implementada, enquanto o core do sistema segue zuado, cheio de falhas, mas eles não tem tempo de evoluir pq precisam entregar outra funcionalidade besta que dá mais visibilidade para algum chefe.
Se estão atuando com agilidade dessa forma esta TOTALMENTE errado.
Na realidade o time de dev não decide a priorização do backlog na grande maioria das vezes.
E te garanto que 95% do time ideia retrô e review, além do excesso de ritos e excesso de interrupções para coletar status.
"Todo não programador sabe que se perguntar a um programador quanto tempo alguma coisa leva para ficar pronta e ele responder 200 horas, você sabe que em 200 horas, seja lá o que foi pedido, vai estar pela metade." (AKITA, 2019)
O erro ja tava em perguntar so pro programador kkk
Trabalhei durante 6 anos como desenvolvedor e, mesmo sem usar metodologias ágeis, a empresa que trabalhava entrega resultado. Sempre segui essa mesma filosofia que o Akita falou: foco em resultados, boas práticas de programação e muita responsabilidade. Primeiro vídeo que vejo no canal e larguei a mão no "Inscreva-se". Parabéns!
Li o título e vim assistir indignado, mas acabei concordando com cada ponto do vídeo kkkkkkk
Não fazia ideia da existência do manifesto, sempre trabalhei em empresas auto proclamadas de "ágeis", mas que pisava em todos os princípios. Recentemente me mudei para uma empresa que segue o manifesto muito bem, e agora percebo a importância desses valores.
"o software vc xinga, o hardware vc chuta" - desconhecido,. kkkkkkkkkkkk
E o peopleware vc demite.
vamos fundar a associação de programadores anti coach!!!
APAC
ser anti-coach é bom senso
Eu sou motoboy mas quero entrar na associação tbm kkkkk
Up
@@BrunoSep182 Opaa, salve!
Agora já somos dois na associação MQQSP - motoboys que querem ser programadores.
Tmj! Haha
Edit: Aliás, seu comentário tem 2 anos, então é provável que você já é programador.
Resumindo...
Parte 1 de 2 -> 3 passos dentro de um loop...
Repita ...
--> passo 1 entender onde você está
--> passo 2 dar um pequeno passo em direção a onde quer ir
--> passo 3 avaliar o que aconteceu
Até terminar...
Parte 2 de 2 -> Quando encontrar duas ou mais opções:
--> escolha aquela que torna as coisas mais fáceis de mudar no futuro.
--> tome decisões que são mais fáceis de mudar no futuro.
O problema é o Ctrl+c Ctrl+v ( entre o STP e o desenvolvimento de software )... são necessárias várias adaptações que quando realizadas funcionam muito bem...
A propósito, qual metodologia/filosofia utiliza em sua empresa? Acredito que a resposta seja: uma metodologia própria, carregada de uma mistura das coisas boas que várias metodologias oferecem... com pessoas ágeis... É preciso saber filtrar o que cada forma de trabalho oferece e fazer adaptações... Acertei?
Muito obrigado!
Acertou, é isso mesmo: metodologia "própria" que é parte do agile original, sem propagandear e sendo ajustado ao longo do caminho pra minha realidade.
@@Akitando Excelente... Gosto de trabalhar assim... entender cada método, e aplicar o que há de melhor em cada um deles, para a minha realidade... valeu... :)
Por mais vídeos [Rated R].
O que siginifica [Rated R]? (Não a tradução o sentido proposto?)
Pre planning, planning, sprint,entrega da sprint...retrospectiva ... só eu fico cansado desse looping?
Novatos: Olha isso, entregamos muitas sprints
Akita: Bullshit, entregou o que o cliente pediu?
Uma verdadeira lavagem cerebral.
Um neo-Sísifo! Vida de rolar e rolar a rocha montanha acima...
Como digo para os colegas aqui do trabalho : ainda teremos saudades do tempo do desenvolvimento em cascata. O ágil se transformou em uma burocracia sem fim. Uma verdadeira muleta para os enganadores.
Akita, você conseguiu extrair todos os meus sentimentos, pensamentos e conclusões dos últimos anos, pois acompanhei o surgimento do manifesto para desenvolvimento e observei o quanto foi deturpado ao longo dos anos. Muito obrigado por conseguir compilar e organizar em vídeo! Sinto-me aliviado.
Meu herói! rsrsrs
Muito bom ouvir alguém sensato!
Há muito tempo eu já venho com uma sensação de "stranger in this town" em relação a esse assunto.
Obrigado, você me confirmou que é a cidade que tem se tornado cada vez mais estranha e não eu. Sensação de alívio!
Há muito tempo o "agile" virou muleta, de entregas, transformações. Eu já passei por entrevista em que o entrevistador perguntou se eu era ágil, e atrelou ser ágil às metodologias. Por muito tempo vi o foco em entregar rápido, dar velocidade a sprint, vários gráficos querendo medir a velocidade da equipe, e nenhum kpi dizendo qual o ganho que está sendo gerado para o negócio. Esquecem que tombar para o ágil é muito mais mindset do que metodologia.
É impressionante como este vídeo nunca fica velho. Eu volto aqui, vejo de novo e fico triste. As empresas continuam insistindo nisso.
O tom dos vídeos é ótimo. Sem frescura... :-)
Foi exatamente o que me chamou a atenção. Muito legal!
sensacional
Nesse caso tem a questão corporativa, a maioria dos clientes tem prazos impossíveis e a empresa tem medo de perder clientes e acabam fazendo promessas que não vão conseguir cumprir.
E no final acaba perdendo... A realidade é essa
Cara primeiro vídeo seu que vejo e acabou de ganhar um fã.
idem kkk
Falou tudo o que muita gente precisava ouvir, estão criando jardins de infância atras de metodologias, enquanto o software deixa de ficar pronto. Muita gente dando aula de Scrum, consultores do Sebrae, e por ai vai, um monte de gente que nunca escreveu código nem tocou uma empresa de verdade dando aula de Agile.
Muito obrigado por esse vídeo, me identifiquei muito. Quando li o manifesto ágil pela primeira vez fiquei encantado, mas percebo que a maioria das pessoas confunde ágil com rápido e esperam que o produto seja entregue no menor tempo possível, sem considerar que algo bem feito, com qualidade e que seja fácil dar manutenção é muito mais vantajoso do que algo feito rápido e que a longo prazo terá um custo muito maior com manutenção.
Fábio Akita já é lenda. Parabéns pelo seu trabalho.
eu racho o bico com essa Fabio Akita, kkkkkkk. Depois de começar a trabalhar com Scrum eu nunca imaginei que meus 4 anos servindo na cavalaria do EB seriam tão úteis kkkkk, podem acreditar kk
Olá Fabio, boa tarde e como vai?
Cara eu sou de infra, mas tudo isso que falou no vídeo eu vejo acontecer em meu atual emprego. Perdem muito tempo com um monte de técnicas, Frameworks e metodologia para no final mostrar tudo em PPT com gráficos cheios de perfumarias para a diretoria com o mesmo resultado de sempre... Nenhum valor agregado, nada mudou no faturamento da empresa e só gastou o tempo dos analistas com reuniões diárias sem sentido.
Resumindo, bullshit e dinheiro jogado fora com os profissionais perdendo o seu tempo fazendo estas reuniões e amarrando os processos com firulagem "não ágeis".
Virei sei fã por ser direto, sem mimimi, adulto e mostrando o seu ponto de vista profissional da sua carreira que é longa e por isso sabe muito do bem do que está falando!
Valeu pelo excelente vídeo e fui ágil em dar o like se inscrever e clicar no sininho para não perder seus próximos videos! rs
Forte abraço!
Muito bom o conteúdo. De agora em diante pensarei diferente quando o assunto é "Ágil". A forma errada que falam sobre "ágil" é exatamente a forma que aprendi. Em artigos que aprendi sobre o assunto, não lembro em nenhum deles mencionar o manifesto. O pessoal só escrevem que ser ágil é fazer tudo em menos tempo e dão exemplo de várias técnicas de organização e ferramentas que aceleram o desenvolvimento.
Depois de assistir ao vídeo e refletir sobre o que estão escrevendo, você percebe que tem bastante desenvolvedor/empresa ágil caminhando para o lado contrário do manifesto ágil.
Por exemplo:
- Desenvolvedores focando nas ferramentas, processos e na linguagem de programação mais "hipster" do mês.
- Focando mais na documentação abrangente, dinâmicas de grupo, reuniões enquanto nem iniciaram o desenvolvimento do software.
- E quando as coisas saem fora do controle, buscam outras ferramentas, processos e linguagem ou contratam uma consultoria que entregam ágil :D.
Vagnerlandio Nunes isso esta acontecendo na minha facul, só reunião, palestras motivacionais, ferramentas e metodologias para criar o software, prototipar a ideia e os requisitos do software em caixa de papelão, definir o modelo de negocio com trello, mas ate agora nenhum grupo começou a botar a mão na massa pra desenvolver o software, pq tem cumprir esses cronogramas do curso kkkkkkkk
Alguém traga um Oscar para esse Akita!
Cara, você falou tudo o que eu sempre pensei sobre as baboseiras numerológicas de gerenciamentos de projetos.
Parabéns pelo vídeo!
Me senti representado, sou Adm e lean e kanban são coisas antigas para mim. Tbm passo raiva com os “gurus” que enganam a galera com sambarilove de agilidade.
Distorceram muitas coisas pra dizer que são "novas", mas que na verdade existem há anos
"sambarilove de agilidade" kkkkkkkkkkkk. Genial
Espero que você saiba design gráfico, pois para muitos será necessário uma explicação em animação em 3d do que você passou.
Cara, morri de rir desse comentário xD
Kkkkkkkkkkkkk
Com trilha e efeitos sonoros
Sou certificado com a PSM1 como SCRUM master, e concordo com tudo que foi dito, o individuo precisa ser ágil na sua essência, porque não são rituais, nem formulas mágicas que fazem a pessoa ser ágil, na época a minha falta de experiência me fez brilhar os olhos com a metodologia, mas depois aplicando em uma agência de marketing, e depois ajudando uma software house cheguei nessa conclusão, como as pessoas vão se organizar para dar o resultado não importa, desde que se consiga avaliar se está dando resultado.
Primeiramente agradeço o vídeo muito bom para abrir os olhos de muita gente.
Sou desenvolvedor há muito tempo e pensei que estava ficando louco.
Tudo que disse é verdade sinto na pele quando a empresa usa essas metodologias... que a procupação de ser ágil e estar tudo perfeito no Jira ou em qualquer outra ferramenta desse tipo é mais importante do que agregar valor...
Quando dinheiro e tempo que se perde jogando Planning Poker e fingindo que está planejando algo sem entregar nada no final...
Gostatei muito vídeo parabéns!
Que vídeo esclarecedor!
E como você disse: "Não começar algo inseguro demais é ser Ágil".
Se puder faça um vídeo sobre componentização de software, gostaria de saber o que pensa sobre isso.
Abraço e Parabéns pelo video!
Dei pause no meio do vídeo só pra "plantar" um like!!! Trabalho com TI (Infra) a quase 8 anos e estou migrando para desenvolvimento, seu canal tem me ajudado bastante. Parabéns pelos conteúdos de qualidade!!!
Cara incrível, pessoas que pensam igual a mim existe!!! Sempre digo para meu time, o que faz a diferença é o comprometimento.
Cara muito bom seu vídeo, tenho quase 10 anos na área, nem chega a ser metade de muitos aqui, mas me identifico plenamente com seu modo de pensar. Depois de alguns anos decidi entrar mudo e sair calado. Não consigo mais depositar meus esforços em projetos sem escopo definido, com data de entrega e com metade da sprint com analise funcional rasa, com 20 mil pontos em aberto e no final das contas, pesando muito mais nas costas do programador.
os inconformados movem o mundo. sensacional! obrigado por essa experiência!
Nunca esteve tão atual esse video.
Estou revistando o video 2 anos depois daquele boom e polêmica que esse video gerou na comunidade agil e percebe-se cada vez mais o qto. ainda continua verdadeiro.... show
Parabéns pelo video Akita! Há muito tempo venho rejeitando essas metodologias (inclusive sendo ulgado por isso). Assim como mencionou, desenvolvimento de software é um processo criativo , é uma organismo vivo sujeito a adaptações constantes, é estranho querer estruturar em processos bem definidos algo que é de uma natureza diferente. Adicionar regras/processos para quantificar e dar um ar de profissionalismo não resolve o problema, só adiciona uma camada para quem não quer assumir os riscos se esconder mais facilmente. Infelizmente, existem os riscos associados ao desenvolvimento, nem sempre é possível estimar com precisão. Como sugestão para deixar seu ponto ainda mais claro, seria vc legal falar sobre o que o Uncle Bob já dizia a muito tempo: Profissionalismo no desenvolvimento de software.
Eu acho que falei no meu outro vídeo. "Estimar com precisão" não existe. Tem outra palavra pra isso: Adivinhar. Profissionalismo é estimar e tentar alcançar o objetivo, e se não for conseguir, avisar com antecedência pra gente negociar enquanto ainda está em tempo de ajustar o percurso.
Akita vc é fantástico!!! Comecei a ver seus vídeos e foram um vdd tapa com luvas de pelica. Agora estou maratonando os vídeos do seu canal! Muito obrigada por compartilhar seu conhecimento sabiamente!
Vou ter que logar com todas minhas contas do RUclips pra dar um Like nesse vídeo!!!
Então, a única prática que adoto é o feedback constante. Dou preferencia pelos e-mails devido validade legal e por todo mundo já saber usar.
Como comentado, estimar prazos é uma tarefa complicada, e eu mesmo tenho certa dificuldade em prever, então faço o mínimo que esperaria que fizessem se eu estivesse na liderança: um relatório curto resumindo oq eu estou ou não fazendo e porque. Para que quando peçam algo pra meu líder, ele ao menos saiba explicar com que tarefa estou perdido.
Se tem uma coisa que aprendi em alguns anos de experiência, é que ser previsível e manter tudo bem documentado são as habilidades mais essenciais e genéricas, que se aplicam a qlqr tipo de trabalho. Qlqr coisa que não envolva deixar a equipe inteira ciente do que está sendo feito e porque, para mim é perda de tempo.
Nunca entendi as empresas de software utilizando metodologias de produção ou engenharias. Sempre imaginei " mas que p**** esses caras estão fazendo???". Agora tudo faz sentido.
Não sou programador, sou ti infra mas encontrei no Fábio Akita um ótimo ponto de reflexão nos trabalhos, não só em tecnologia e programação, mas na vida. Ele tem uma didática sensacional e boa base naquilo que expõe, obrigado pelos seus vídeos.
Como eu cai nesse canal ?
Que achado magnifico, adorei o conteúdo!
Os métodos só são válidos quando conseguimos adequá-los a realidade do negócio. Acho que o KANBAN, SCRUM, etc são super interessantes, e pode ser usado em diversas áreas, mas engessá-los não é o caminho. O problema não é a ferramenta, é sim a mentalidade engessada de alguns que a aplicam.
esse episódio deveria se chamar: matando coachs ...
Ponto muito bem levantado meu caro Fabio Akita.
Se a preocupação está mais na metodologia, nos numeros (q podem ser mascarados), nas entregas por entregar e o valor da entrega o problema que está sendo resolvido e a forma que está sendo resolvida vira coadjuvate pega tudo e joga fora.
Admiro muito o que você faz aqui no youtube.
Obrigado por compartilhar sua opinião, um grande abraço,
Porra Akita. Você tem que começar a ir nesses TDC da vida e desmistificar essa modinha "ágil". Ágil is dead.
Ágil is dead...e quem tomou o seu lugar? XP ? Waterfall?
@@AndreCarneiro666 eu sei, daí a pergunta!
Agora imagina se fosse no Agil Trendz??? uahauhauhauah
Achei o canal nessa semana e me culpo por não ter o encontrado antes 🤧...mas,antes tarde do que nunca🙌
Excelente, adorei esta parte 35:51 - 37:22.
Cada deslike é de um agile coach.
Abraço, até o próximo.
uaeheauhaeuhaeuhaeuaeh
kkkk
Kkkkkkl boa
Lucas Barros cada deslike é um ágile charlatão 🤣🤣🤣🤣🤣🤣🤣.
kkkkkkkkkkkkkkkk
O vídeo mais realista e mais direto sobre todo esse marketing sobre metodologias ágeis nas empresas. O que vi constante nas empresas por onde passei é que a maioria delas fazem o que foi dito aqui. Coloca o kanban, algumas métricas que eles criam sei la baseado em que, e agora em uma passe de mágicas a empresa e as equipes são ágeis. E agora os devs e todos envolvidos nos processos que na maioria das vezes são engessados, estão mais rápidos, mas com o passar de algumas horas eles (diretores, ceos e todos acham simples desenvolver softwares) descobrem que adotar ferramentas e falar jargões da modas não os deixam mais ágeis, por diversas razões. Parabéns pela chamada de responsabilidades de ambos os lados que trabalham com desenvolvimento de software.
Akita, o tom "hater" generaliza suas observações e, no meu ponto de vista, acaba com qualquer tipo de mensagem que você queira passar :slightly_smiling_face:
Obviamente "instalar ágil" ou se "mostrar ágil" é atrativo e chama a atenção. O mundo é feito de ondas que se tornam moda e o ágil está neste momento. Como qualquer movimento, você tem bons casos e outros que não são. Participar das conferências ajuda a entender o que está acontecendo e talvez seja interessante você compartilhar sua visão na comunidade.
Você começa resgatando os valores do manifesto, mas depois todos os comentários ficam soltos (ex: o que microgerenciamento tem a ver com ágil? desenvolver software não passa por um fluxo? como seu sei se estou entregando ~ pelo achismo? como lidar com prazos em processos criativos?) e perde a essência do tom crítico aos métodos! No final eu fiquei me perguntando: será que era mais fácil ele ter dito em 5 minutos que o XP e os seus princípios refletem o que ele entende como o "ser ágil"? Acho que sim....
Uma mensagem que você aborda, mas não aprofunda é: como o tal movimento ágil tem tratado a gestão de desenvolvimento de software? Para mim, esta seria a riqueza do seu conteúdo e da sua experiência, mas o vídeo não entregou uma resposta estruturada para esta pergunta.
Não está errado, como o que mais se acha hoje ainda é sales pitch de agile o objetivo desse vídeo não foi ser uma aula nem nada disso, eu disse que ia ser um rant e foi um rant :-) Quem sabe mais pra frente eu falo sobre os aspectos que realmente fazem sentido de uma forma mais estruturada.
Aliás, já que comentários recentes demonstram alguém dizendo a mesma coisa que você mas sendo mal.educado vale agradecer pela sua educação. 👏
Interessante o debate e acrescento ao coment do Rapha Albino: Metricas de resultado seriam de fato importantes estar aqui presentes para embasar tudo o que foi dito. Aplicando tudo o que é abordado com agilidade, se tem qual real valor, uma vez que o movimento é deturpado? NPS de clientes, indicadores de retrabalho, rentabilidade de contratos... importante em minha opinião ter tudo isso, e claro, inclusive quando se coloca o XP na jogada tbm é valido.
galera o fato é que modinhas de longe são fatais para os projetos. Eu mesmo sempre utilizo uma metodologia própria de estudar, aplicar e validar antes de sair utilizando para todo quanto é tipo de projeto. Isto gera polêmicas mas modinhas só servem na minha opinião para preencher lista de requisitos de empresas de TI
Eu ia postar algo nesse rumo, mas você já o fez e fez melhor do que eu faria. O pior é que induziu um monte de desavisados/ignorantes/juniores a ignorar a agilidade.
Obrigado por compartilhar o material. Concordo com você principalmente no ponto em em que você toca no assunto "Medo e Insegurança". Realmente, é o que mais acontece, um programador promete que irá fazer no "X" tempo, só que depois que inicia o projeto, o fator tempo vai para "X2". Importante é ter sim as expectativas alinhadas e entregar o que prometeu no tempo acordado. do contrário é chute!
194 scrum masters não curtiram esse vídeo
CONTEÚDO ABSOLUTAMENTE AUTÊNTICO! Parabéns por ELEVAR A BARRA DA CONVERSA! 18:38 resume demais!
Muito bom! Me lembra aquele conceito apresentado por Ralph Waldo Emerson
:
“Quanto aos métodos, pode haver mais de 1 milhão deles, mas são poucos os princípios. Aquele que souber os princípios pode selecionar com sucesso os próprios métodos."
O negócio é resolver os desafios que importam para o objetivo da melhor forma possível, da forma mais adequada a meta!
Cara, muito bom. Eu sou estudante de Engenharia Mecânica, acompanho o canal há pouco tempo e tenho me identificado com grande parte das suas ideias.
Durante o meu estágio presenciei e fui parte de uma tentativa falha e sem resultados da implementação de "novas metodologias" dentro da empresa, inclusive com a contratação de consultorias externas pra "auxiliar" nesse processo.
Na minha percepção, aquilo só serviu pra vender a ideia modernização de processos usando algo que claramente não estava adequado ao que a empresa produz (equipamentos mecânicos e hidráulicos) e nem às ferramentas que esta utiliza.
Virou mais uma moda na verdade, pois todas as metodologias de Design que aprendi na faculdade e sempre usei lindamente pra criar produtos físicos e virtuais são a mesma coisa com um nome novo (e muito mais burocracias e reuniões que roubam tempo de produção). Sem contar que pra determinados produtos uma metodologia é melhor que outra, eu ainda prefiro escolher a metodologia de acordo com os requisitos do projeto. Mas né... ao invés de Designer de Produto, Gerente de Produto, ou Gerente de Equipe tenho que falar que sou "Product Owner, Master e blablabla" senão não consigo recolocação. Mil vezes puff. É muito foco em cumprir etapas e pouco foco no cliente final, como resultado temos produtos bem medianos, mas cheios de nomes chiques em inglês.
Tem os casos também que o gestor é alguém que não entende patavinas de Design ou Development, pra mim não faz sentido algum um coach que não entende da área rs.
O mais triste é nas vagas de emprego medirem os candidatos pela quantidade de softwares que eles dominam e se eles aplicam Ágile... sinceramente é possível contratar um micreiro que mexe em mil programas e leu sobre Ágile, mas não entende absolutamente nada de processos, funcionalidade, experiências e estética. Nem pedem mais curso superior... sendo que cérebro e capacidade criativa não pode ser medido em quantidade de skills. Quem cria é o Designer, o Programador e estes criam o fluxograma, o desenho técnico e sketches na mão se for preciso.. agora corta a energia elétrica pra ver se um micreiro resolve alguma coisa kkk.
CARA TEU VÍDEO MERECE UM PRÊMIO!!! Assino embaixo de tudo o que você disse! Quem perde é a empresa que limita o potencial dos PROFISSIONAIS DE VERDADE.
Eu no minimo vou ver esse video umas 3x de tão bom que é!
Semana passada conversei com um amigo sobre o trabalho dele. Perguntei o que ele fazia na empresa onde trabalha. Pensei " ele é analista de sistemas, deve trabalhar com códigos ou banco de dados". Minha decepção quando ele contou que só enrola, e que sabe tudo de metodologias ágeis, enquanto escrever um simples hello world ele não faz.
Notei que , mesmo eu batendo cabeça aqui pra aprender como se desenvolve sistemas, estou muito mais engajado do que um show man das agilidades. Lembrei do cara do ligue jhá.... Ah, e mais um escrito. Gostei dos assuntos.
Comecei achando insuportável (porque doeu né?) e acabei admirando.
Excelente trabalho! Parabéns!
Ganhei um treinamento de Lean h na empresa, parece que o Akita já tinha metaforado cada palavra do consultor.
Fico impressionado como a galera empurra qualquer coisa e consegue vender.
Enquanto a gente estava fazendo as atividades eu só me perguntava,
A gente é burro demais se a gente se conversasse não precisava dessa bulshitagem
A metodologia mais usada é a eXtreme Go Horse (XGH), altamente prática :)
Após 5 anos, seu vídeo contínua sendo uma utilidade e verdade tão absoluta quanto. Leciono em uma Universidade, e o que pedem é para falar sobre essas metodologias ágeis, Scrum e Kabam, etc. A ementa pende para assuntos teorizados demasiadamente. Ao fim, o aluno que termina o semestre igual aquando começou, sem entender o que realmente importa ao meio desses mares de metodologias que empresas tentam vender. Não que, não seja importante os princípios, mas tentam seguir como se fosse uma regra, e acaba acontecendo o mesmo com a bíblia, cada um lê e interpreta como quer e logo vira uma verdade.
Parabéns novamente pelo vídeo.
Muito bom seu vídeo, mas foram 42min falando genericamente sobre os problemas atuais da 'agilidade'. Podemos entrar em detalhes de alguns pontos? Por ex: O que voce acha da utilização de uma ferramenta como o JIRA, em conjunto com um quadro físico (onde programadores e QA tem que ficar atualizando os 2 constantemente pra agradar o gestor)?
Assim como o Fabiano Pereira tbm quero vídeo 2!!!
Kkkkkkkacildão!
Recentemente passei por isso, mas tinha mais um bocado de planilhas para alimentar!
Ninguem sabia o que elas comiam! :-)))
Isso é ridículo e uma tremenda perda de tempo... na minha empresa tentaram vender isso. Eu com lider do time, ignorei. Tremenda perda de tempo e desperdício.
Porra Fabiano tá querendo tirar o emprego dos Scrum Master?
Fábio, parabéns pelo canal, é mais um projeto que você tem feito brilhantemente.
Fui um assíduo usuário do Akita on Rails vindo do PHP e sempre gostei da quantidade de coisas que você faz bem ao mesmo tempo.
Programo há muitos anos estou em uma empresa também há anos e já faz tempo que sinto que fiquei pra trás, nunca gostei de estudar a fundo as coisas, mas sim fazer tudo funcionar...
Agora nós estamos em processo de migração para microserviços e microfrontends inclusive.
Os códigos tem ficado tão estranhos para os old programmers, tudo tão diferente que eu nem sei o que eu perdi.
Se você pudesse listar uma ordem de estudos, em termos de livros ou outros materiais, para que pudessemos retomar para a atualidade quais seriam.
[]'s
Uma hora preciso falar de novas arquiteturas. E valeu por acompanhar! Akitando seria o AkitaOnRails pra nova geração
Para mim, Extreme Programming sempre fez mais sentido do que Scrum e Kanban.
Pra mim tbm
Pensei que eu estava sozinho no universo
Porque, igual o Akita falou, são ferramentas da engenharia de produção e não de programação
Perfeito! Bom saber dos teus vídeos.
Lembro das tuas palestras no Centro de Convenções SulAmérica nos eventos da Locaweb. Era revolucionário para o mercado da época! E de fato, se perdeu totalmente. Ótimo vídeo!
Fabio Akita, não é exatamente relacionado ao tópico, mas você poderia comentar/talvez fazer um vídeo sobre insegurança de um dev jr? Porque pessoalmente eu aceitava quase todos os prazos que me estipulavam, com medo justamente de ser demitido, pois sempre seriam os elos mais fracos, e também não tinha ideia de como estimar o prazo, pois praticamente não tinha a ideia do que precisava ser feito, de ponta a ponta. E ai logicamente ferrava tudo, projetos atrasavam, bugs pra todo lado e ai talvez aparecer a tal necessidade de um couch de agile. Talvez eu estivesse aceitando projetos e tasks que eu não deveria estar pegando? Se for o caso, como iria evoluir só pegando "tasks de juniors"? No caso é simplesmente aceita, e estuda até conseguir orçar melhor ou tem algo que eu não enxergava?
boa pergunta.
E aí... 3 anos depois, sua experiência te respondeu algo? Enquanto dev jr, tô curiosa real p saber...
Falou tudo que eu sempre senti, mas eu nunca soube dizer. Vejo bastante, equipes durante mezes inteiros atoladas em reunioes e procedimentais interminaveis, indo trabalhar todo dia, muito mais para cumprir uma liturgia, um ritual, um procedimental, do que produzir o software em si. E no processo, quem produz de fato, acaba tendo que levar nas costas uma turma que só serve para burocratizar e politizar a producão.
Planning que dura 1 dia inteiro .... sprints que duram 1 mês porque tem tanta reunião durante a semana que não sobra tempo pra programar ... e isso é chamado de "'ágil". É o famoso "ágil pra inglês ver".
Como catarse o vídeo é excelente! Inclusive dá vazão às minhas próprias frustrações com a implementação da "cultura ágil" em empresas. Acho que vale um outro vídeo mais didático sobre métodos como XP ou sobre os conceitos do manifesto no geral.
Fantástico encontrar profissionais com conteúdo com a qual nos identificamos. É como ouvir ecos próprios pensamentos traduzidos de forma clara. Excelente trabalho. Você é simplesmente "oohh caaaraaa"!!!
Esse homem Fábio akita é desse planeta mesmo kkk, o cara é foda.
Muito bom, vim aqui justamente porque a empresa em que trabalho está tendo muitos problemas com o Agil, ou a má interpretação dele, temos mil ferramentas que tem a função de dar visibilidade das entregas e nos "ajudar" a melhorar como time.
Durante meses essas ferramentas apontam que nosso time é excelente, vem melhorando cada vez mais, fomos de uma nota 5, para 6, para 7, para 8, nota que foi muito comemorada, porém, quando alguém de cima parou para questionar/analisar as nossas entregas, não temos nada de concreto feito em meses.
Ou seja, o time aprendeu a trabalhar de uma forma que nos garante uma nota boa e garante que a gente possa apresentar essa nota e falar como o time é bom e tem evoluído, mas é o ponto que o Akita trouxe, é fácil torturar números com o objetivo de chegar a uma conclusão desejada, embora não tenha nenhuma relação direta.
Que poha quer dizer um time nota 8 se não tem nada funcionando?
Olha sou formado em engenharia, e digo que tenho alguns problemas bem parecido na minha área kkkkk, excelente vídeo inspirador parabéns!!
Tbm sou engenheira, de produção, e tbm vejo isso, com distorção das ferramentas e de algumas áreas que agora virou modinha usar
Maratonando me deparei com esta pérola, Obrigado. Nunca foi um exímio programador, no entanto sempre consegui ver além do projeto, ver o todo, e harmonizar o desejado com o possível a se fazer. Isso me rendeu a responsabilidade de gerenciar alguns projetos, em algumas empresas, e com a idade acumulando foram também acumulando "métodos pessoais" para ancorar os 'Stakeholder' a realidade. Excelente vídeo, novamente...
Fábio Akita, você tem meu respeito !!! parabéns pelo conteúdo !!!
Transparência é o que falta!!! Empresas querem muito mais essas numerologias do que resultado real, digo até a empresa clientes desses ágeis mesmo. O gerente mostrando números a gerência, e a gerência fica feliz porque isso tudo é mais fácil, e exibe status, aparência de qualidade e produtividade.
Caralho!
Quanta "porrada".
O Fabio pareceu a Alemanha!
😂👊🏽👊🏽👊🏽👊🏽👊🏽👊🏽
Vídeo super atual, mesmo ainda estando em 2021.
Todo mundo quer uma Ágil pra chamar de seu no final do dia.
Parabéns pelo conteúdo!
O título poderia ser esqueça as ideologias ágeis hehe
Achei que não veria até o final pela duração, mas não consegui parar de ver. Sensacional.
que video foda! e ai akita quando sai um video sobre TDD e BDD?
A dois anos atras vi pela primeira vez esse video, a época eu trabalhava em uma startup que praticava um "agil" a sua maneira ... eles tinham seus processos e adptavam o que lhes interesava do scrum e dava super certo, era muito bom, mudei de trampo passei por lugares que aplicavam umas mais outras menos o scrum, e depois de dois anos esse video ta mais atual que na época que foi lançado.
A melhor reflexão sobre metodologias ágeis que alguma vez ouvi! Excelente!!!
Obrigado!
Estou entrando na área de T.I e atualmente trabalho como técnico de enfermagem no setor de UTI e realmente tudo que foi comentado neste vídeo é uma grande realidade, devemos ser profissionais resolutivos a todo momento independente do área que se atua, sempre buscando uma alta performance, sem esperar elogios por isto.
Eu espero elogio, um elogio $incero.
Citando o matemático Ledo Vaccaro, trabalho não é família, eu trabalho para ganhar dinheiro!
Melhor vídeo do ano ! Muito bom Akita, tenho exatamente a mesma opinião. Sempre fico surpreso com como conseguem complicar e "empacotar" as idéias originais de forma absurda pra poder vender "Ágil"
Ok. Eu pensei que já tinha consumido o teu melhor material, mas tu se superou. 👍
Mais uma vez, obrigado por falar o que eu sempre não consigo por não conseguir organizar as ideias dessa forma.
Interessantíssimo. Tentei apenas uma vez aplicar metodologias de desenvolvimento de software e, para não supresa, deu no resultado mais conhecido, fracasso. Desde então passei para esse "ágil tradicional" (ou raiz, rsrs) aí, sem saber, seguindo basicamente estas 4 regras básicas (que ninguém me disse na faculdade de engenharia que existiam). Legal saber... Valeu pelo vídeo.
Sou universitário de engenharia de produção e esse vídeo é melhor doque aulas de muitos doutores na área na minha opinião, parabéns pela qualidade Akita.
Conteúdo simplesmente foda ! Tenho uma dúvida: que métricas você usa , como mede eficiência de entrega e como trata os processos na sua empresa ?
Creio que ele respondeu isto quando falou do ROI e do TCO. ;-)
Entendo e compreendo muito sobre este tema e o que acontece em empresas de software, mas tendo uma ótica voltada para empresas de serviço, quando pegamos uma ferramenta simples faz a diferença em toda a operação, igual ao vídeo que você mesmo disse a alguns dias a pratica leva à perfeição que neste caso, sim a pratica de ferramenta específica para a operação faz a empresa chegar a um patamar que não é apenas esperar o cliente entrar e sair sem saber o motivo. Com tudo deixo bem claro que quando tem um propósito para entregar faz a operação ser ágil, mas apenas o propósito em si não faz milagre e por alguns motivos que a minha startup encontrou está dor e estamos solucionando ela. Claro, este é meu ponto de vista e de total responsabilidade descrita pela minha pessoa. Tenha uma boa noite.
Opa video pra assitir no almoço. Valeu Fabio Akita
Cara, tô passando por um período de restruturação na empresa em que trabalho e esse vídeo me ajudou a voltar à realidade. Valeu, Akita!
E complementando com Porta dos Fundos hahahah ruclips.net/video/XOhTEKEOk4U/видео.html
o que agile tem a ver com coach?
@@KubernetesEverton com coach nem tanto, apesar de existir agile coach. Porém, ele faz essa relação mais pela característica de "modismos" que ambas tem, com buzzwords, etc...
O que mais tem hoje em dia é Agile Coach, Innovation Coach, Startup Coach, Bla-bla Coach ... é uma praga
kkkk esse canal é uma bela de uma porcaria, mas esse vídeo foi engraçadão kkk
@@ricanalista huahua magoei ❤ mas valeu
Dúvida pra um possível próximo episódio: por onde você acha que podemos começar a questionar as práticas atuais da empresa? É mais importante que a empresa pare de usar métricas arbitrárias ou que nós programadores ignoremos tais números?