Métodos ÁGEIS são a NEGAÇÃO da engenharia

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:

REDES

[Urukpensador]

Usando o teormea do macaco infinito notamos que em algum momento a IA vai resolver algum problema

[mrFelipext]

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.

[antonio]

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

[magoasa]

Gostei muito do canal, vem de encontro de muitas coisas que penso.

[henriquezolini]

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
.

[clarabatt]

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.

[OGdoCavaco]

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

[lucasnative]

Pior que Ágil é requisito básico de diversas vagas por ai

[ciromoraess]

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 (:

[mrFelipext]

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

[lucasescopelli]

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

[jonashonorato]

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

[Eng.pedroneto]

Está todo mundo viciado em achar que IA vai acabar com o emprego de todo mundo rs

[hainshj]

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

[PeX]

A tecnologia substituiu o ascensorista…

[vinybas]

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.

[luizdiodo]

foda dizer que o manifesto ágil foi feito pelo uncle bob, pai do clean code / clean architecture…. um engenheiro

[odouglascardoso]

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.