Métodos ÁGEIS são a NEGAÇÃO da engenharia
HTML-код
- Опубликовано: 28 авг 2024
- Será que vamos precisar de engenheiros de software no futuro? Será que a IA vai deixar a gente obsoleto?
Antes de fazer essa pergunta, temos que entender o que nos levou a esse ponto. Será que nosso trabalho é tão simples que um programa pode nos substituir?
A resposta por trás disso está no famoso Scrum, método que levanta paixões entre os desenvolvedores, e esse vídeo explica o porquê.
Links:
Vídeo original: • AGILE & Scrum Failures...
REDES
Site: www.wainejr.com/
Instagram: / waine_jr
TikTok: / waine_jr
Usando o teormea do macaco infinito notamos que em algum momento a IA vai resolver algum problema
kkkkkkkkkkkkkkkkkkkkk
Para mim o principal problema não está na substituição total dos desenvolvedores por IA, e sim o aumento na produtividade do trabalho que pode levar a uma redução nas vagas e, com um mercado saturado, acabar com os salários sendo rebaixados
Esse daí já não é um problema da IA, mas estrutural do sistema de produção...
@@waine_jr concordo plenamente, uma hora ou outra toda mão de obra acaba na precarização e achatamento salarial.
Eu sinceramente achei que eu era um único que tinha esse pensamento. Essas "metodologias ágeis" que não tem absolutamente nada a ver com a ideia inicial do "movimento ágil" estão destruindo as empresas lentamente. Vejam também um video do Fabio Akita chamado: "Esqueça metodologias ágeis". É um bom complemento para este vídeo. E parabéns Wayne pelo seu posicionamento! Hoje em dia sei o quanto é difícil ir contra uma ideia que está tão disseminada
.
Valeu, Henrique! Acho importante dar voz pra essas opiniões contrárias, remar um pouco contra maré e apresentar um contraponto do que já está posto. Tem um "backslash", mas vejo mt gente concordando e pensando dessa maneira tmb, e quem sabe com pensamento crítico cada vez mais pessoas vejam esse lado da moeda
Vender Scrum é mais difícil do que vender cascata. Trabalhei numa software house por muitos anos. Isso acontece porque o cliente quer ter uma garantia de produto final(com razão), mas na prática não tem clareza do que precisa ser resolvido ou muda constantemente. Aí dá o maior problema porque tudo vira óbvio da noite pro dia. Na minha visão usar ágil foi uma tentiva das empresas pra dividir o risco da construção do escopo com o cliente. Especialmente quando se vende desenvolvimento, o cliente tem uma expectativa bem distorcida da realidade em termos de tempo e acha que escopar e planejar o sistema é o mesmo que um orçamento, por isso dificilmente aceitam pagar por essa fase do projeto e quanto mais energia a empresa coloca nisso maior o risco. Sempre foi uma relação problemática. Só que o ágil não resolve o problema, só adia ele, a conta chega na hora de pedir a primeira refatoração.
Gostei muito do canal, vem de encontro de muitas coisas que penso.
Acho que o pessoal ficou com tanto ranço do rational unified process que qualquer tipo fase de planejamento de arquitetura com modelagem é visto como anacrônico. Então como ninguém quer fazer diagramas antes de codificar, virou morar fazer CtrlC e CtrlV do Clean Architecture
Pois é, eu acho que o RUP tem seus problemas, principalmente nessa questão de "programação visual", mas como ele faz a concepção do produto e relaciona com o negócio é mt boa.
As pessoas não se impõe por algo chamado boleto. A área de t.i seta metas de produtividade nas empresas e até reserva uma porcentagem para reestruturação. Não é novo isso, agora isso com time to market e qualidade vai virando uma nova conotação de 'responsabilidade individual'. Você vende seu tempo para alguém e tem o escopo limitado pelo cargo.
Concordo em partes. Vai muito da cultura da empresa. Ao meu ver é responsabilidade do executor repassar os problemas e bater o pé nisso, e se a decisão tomada não for essa, quem deve responsabilizado e penalizado no final é o gestor/gerente/tomador de decisão.
Se algo que eu não concordo é feito, documento toda decisão por e-mail a todos pra depois não sobrar pra mim. Se envolver minha responsabilidade técnica, não assino ou não autorizo a utilização.
Pra mim é muito mais ética sua e como a empresa responde a isso. Eu valorizo mt quem defende suas posições e expõe meus erros, acho mt melhor que alguém que só faz o que é pedido sem o senso crítico ou fazer perguntas
A questão é que o povo tem memória fraca e muitas vezes isso não é documentado as decisões por essa ideologia incrementada. Mandar por e-mail é um bom ponto que você apontou. Senão tudo vira questão de quem queimar.
A qualidade não é so ética é questão de orçamento, o líder técnico idealmente deveria saber disso. O tempo para criar algo de qualidade não é o mesmo. Isso pode se pagar com tempo, mas até lá não dá para pensar em produtos indo contra a engenharia. O problema do codigo hoje é que virou um certificado de estética, arte, engenharia ficando obsoleto muito rápido. Novas práticas saem, decisões e ferramentas que prometem magia. A maioria das empresas querem um parque fechado para amarrar a clientela com stripe. Não são empresas de software, isso envolve pensar em políticas de backup, CMMI. É quase que acidental o software construído hoje, por isso essas questões de manter o legado forever.
@@mrFelipext o tempo pra algo de qualidade não é o mesmo de fato, é não costuma nem ser linear a relação. O foda é ouvir que o "churn tá alto" depois de entregar um produto meia boca que tem 6275834 bugs e tá claramente incompleto.
Muito bom o video.
Cara, acho dificil falar "um é bom e o outro é ruim". Se precisa criar um projeto grande do zero. Metodologias como waterfall feitas com planejamento e tempo são de extrema importancia pra vc nao chegar com algo totalmente aleatório no final. Mas se vc tá mantendo um software, resolvendo bugs, adicionando pequenas novas funcionalidades e etc. o scrum funciona bem.
Com certeza, acho que cada um tem seu caso de uso. Mas vejo que a balança pende muito mais pra um lado do que pro outro, por isso trouxe o contraponto tão forte assim tmb.
Entendo suas críticas ao ágil e ao scrum, mas elas vem de alguns erros de entendimento. Quando a gente estuda os 4 princípios do Manifesto Ágil, o que está depois de "mais que" NÃO é descartado. Por exemplo, "Software em funcionamento mais que documentação abrangente" não significa não ter documentação. Os princípios apenas estabelecem prioridades. Outro erro é achar que no Scrum (e ágil em geral) não há planejamento a longo prazo, escopo definido e nem datas de entrega. Sim, existe, mas as datas de entrega são estimativas probabilísticas, calculadas (sim, calculadas, e não chutadas) no histórico de entregas do time. Mas, conforme você vê que pode haver um atraso, ou se o cliente mudar de ideia sobre o que quer, você tem liberdade para mudar o escopo, porque o planejamento ele é feito de forma profunda a curto prazo, mas rasa a longo prazo (não que você não sabe o que vai fazer, você sabe, mas não detalha como a curto prazo).
O ágil não surgiu de birra contra o cascata, mas porque o de cascata nunca funcionou, não é da natureza do software. Mas o cascata não foi jogado no lixo, ele foi adaptado pra ser iterativo, o que eu acho é que realmente as pessoas jogam mais coisa fora do que deveriam. Por exemplo, na planning você deveria planejar o trabalho da sprint, o "como". Não acho que as coisas deveriam ser tão desorganizadas como são, acho q é tudo má implementação mesmo, como você citou o caso das dailies de 1h com o gerente cobrando. Eu tbm gosto mt da UML, em um meio termo, não profundo como em cascata, mas tbm sou contra o desuso de hj, e acho que ela poderia ser utilizada tanto em documentação geral quanto pra planejamento da sprint. Não há nada no ágil que proíba UML, mas parece que as pessoas acham que há.
Sobre pegar os tickets e resolver, também discordo da visão, porque eu não acho que os programadores do time são engenheiros. Engenheiro/arquiteto de software é uma especialização. A maioria de um time vai ser só programador mesmo e nem tem por que ser mais que isso.
Engenharia de Software é sim mais do que implementação.
Mas meio q n dá pra negar que tem uma demanda gigante direcionada só pra implementação de funcionalidade e teste.
Arrisco dizer que a maior parte das vagas de júnior e algumas de pleno, principalmente.
Será que IA generativa avançando n vai comprometer essas vagas? Eu acho que sim.
A demanda por Design de Software é razoavelmente menor, talvez cresça com essa mudança ai, mas será que vai voltar a ter a demanda que a gente tem hoje em dia?
Fora isso, a entrada de quem é junior no mercado talvez seja mais complicada (o que é até bom, dependendo do ponto de vista, mas sei lá, acho que esse contato mesmo que seja com o código mais "simples" pra que ta começando tb faz a visão num geral ficar mais clara)
Falei num tom meio impositivo, mas claro q eh tudo vendo da minha exp
Ótimo comentário! Esse ponto do quanto das vagas e do trabalho se resume a implementar funcionalidades é oq resume todo a maior parte desse debate pra mim. Acho que só com o tempo vamos saber as respostas pra essas perguntas.
Mt obrigado por trazer esses pontos meu querido
Acho que a questão não é "quem gosta de engenharia não gosta de agile", mas sim que, na minha visão, cada um tem seu caso de uso. Não tenho muitos anos na área, contudo o que pude perceber até agora é que em um produto crítico, onde qualquer falha no produto final pode comprometer todo o projeto o ideal seria a condução através do modelo cascata, pq apesar da rigidez é uma abordagem mais estruturada e definida que permite diminuir/mitigar as falhas (minha visão). Já em produtos onde o requisito muda frequentemente e que seja mais fácil/rápido de evoluir através do feedback de falhas o agile se encaixa muito bem, mas o problema é que na maioria dos projetos o agile costuma ser sinônimo de bagunça (de acordo com a minha experiência de trabalho) ou é empregado apenas por "estar na moda", contudo já trabalhei em projetos que usavam agile de maneira séria e a experiência foi bem bacana e produtiva (:
Perfeito! Nem tudo requer um processo de engenharia pra ser feito, ou todo rigor de qualidade, corretude, etc. pq isso vem com custos que muitas vezes são impeditivos e um bug ou falta de funcionalidade não é nada grave. Aí vem o ágil pra suprir essa demanda
O problema é que t.i sempre foi vendida como uma barreira fácil para empreender. Coisas como melhoria continua só é boa quando você orienta sua empresa a dados. Geralmente as empresas são orientadas a hierarquia e acha que se você usar método curto vai manter o software forever.😅
Gostaria de acreditar que a IA não vai acabar com nossos empregos, mas acho que estamos ferrados mesmo, mas tomara que eu esteja errado.
O canal do Paulo Cacella tem muitos vídeos sobre isso, esse vídeo é apenas um exemplo do potencial assustador das IA,
é um vídeo logo mas vale a pena, principalmente a parte final ruclips.net/video/HVcJFdCWQpI/видео.html.
Se possível, veja do tempo 2:36:00 em diante por exemplo, gostaria da sua opinião a respeito.
O Paulo é engenheiro elétrico, com pos em IA, mexe com computação a muitas décadas, autodidata em inúmera áreas como astronomia, enfim impossível resumir em alguma palavras ele.
Está todo mundo viciado em achar que IA vai acabar com o emprego de todo mundo rs
Pior que Ágil é requisito básico de diversas vagas por ai
Na minha matéria de Eng Software meu gp pegou o XP como tema de seminário. Eu gostei bastante, claro que foi só teoria, mas achei mto interessante
Acho bem massa estudar esses processos e paradigmas, e qnd a gnt coloca numa perspectiva história dá pra entender melhor ainda de onde vieram, o que estavam buscando superar, as áreas que foram pioneiras, etc.
Mas independente do método, colocando a mão na massa cada caso vira um caso, cada projeto é um projeto e vemos que é mt difícil uma metodologia que de fato consiga englobar tudo isso.
foda dizer que o manifesto ágil foi feito pelo uncle bob, pai do clean code / clean architecture…. um engenheiro
Kkkkkkkkkkkkkkk pois é, inclusive também sobre clean code também tenho várias opiniões que não são mt a favor... Quem sabe exponho em algum vídeo ainda
Acho que concordo que o ágil é a negação da engenharia. Nunca pensei e apliquei a todos cenários. Agora a questão é:
- devo usar engenharia para criar 90% dos produtos gerados por programação hoje em dia?
Na minha visão, a depender do que estou criando, posso abandonar os conceitos de engenharia e assumir o ágil.
Você tá lá na fintech, aí aparece no mercado o PIX, quanto mais rápido tu entregar um produto que integra o PIX, mais rápido ganha o mercado, e faz dinheiro, etc...
Óbvio que a engenharia, teoricamente vai construir softwares melhores, mas quem manda é o capital e pro mercado, software perfeito na máquina do dev, é infinitamente pior que software ruim, na rua faturando.
No papel, na teoria, no conceito, ágil pode ser horrível quando se fala do grau de intelectualidade necessário, a ciência por trás da construção de uma aplicação. Mas na prática, em 2024, se a gente te não se adapta, tá fora do mercado. Goste ou não.
Esse é o ponto de discussão que eu considero mais importante mesmo, até que ponto vale a pena ser ágil ou ser "engenheiro"? É sempre um balanço que tento fazer na empresa, mas é mt difícil. Ainda mais quando você coloca na balança as demandas de negócio, aí fica tudo pior. O que custa mais, um bug ou maior rigidez e mais tempo?
Mas acho importante colocar o debate, se não dá impressão que só um existe ou que ágil é "superior" a outros métodos. Pra mim só são diferentes, com objetivos e casos de uso diferentes.
Perfeito!
É a mesma coisa que rebaixar pessoas do teu passado a nada, só pq agora você tem contato com pessoas diferentes no presente. Tem mercado pra ambos e o problema é o pessoal do ágil achar que pode ser aplicado a TUDO.
Trabalhei 6 anos na HP em um produto de faturamento anual bilionário (em dólares). Tinha um mix de ágil sem abandonar processos antigos.
Nem tão livre, nem tão amarrado. Sem perder tempo com documentação durante fase de desenvolvimento e teste, porém a release não era entregue sem documentação e atingimento de métricas e indicadores de qualidade, que muitas vezes são ignorados pelo Ágil e seu misconcept de MVP.
Como tudo na vida, generalizar é perigoso e acho que o ágil generalizou qdo tomou a frente de TODOS os processos de desenvolvimento.