[UPDATE] Projetos de software que adotam metodologias ágeis têm 268% mais chances de falhar, segundo estudo

Isso me recorda do trecho do texto "O ágil, como o comunismo, nunca tem culpa. A verdadeira causa dos intermináveis relatos sobre o fracasso do Agile são todas as pessoas e projetos que já o experimentaram." que pode ser lido aqui.

Achei interessante o artigo, principalmente pela sinceridade em citar:

Embora a pesquisa encomendada pela consultoria Engprax possa ser vista como um plug velado para a metodologia de Engenharia de Impacto

É interessante ver que projetos com boa documentação tem mais chances do sucesso, mas acho, que como é pontuado ao final do artigo, muitas vezes vai da má compreensão/interpretação dos princípios do ágil.

O princípio de Working software over comprehensive documentation não é de Working software instead comprehensive documentation. Não é um em detrimento do outro, é um acima do outro. Contudo isso é tão amplo, até pra não dizer meio vago, que é quase inevitável que isso seja usado para deixar o processo de documentação completamente de lado.

Li em algum lugar, não me recordo onde, que muitas empresas confundem desenvolvimento ágil com desenvolvimento com pressa e existe uma grande diferença entre esses dois.

Desenvolver com pressa é:

• não documentar,
• não testar
• e mesmo que o código esteja uma porcaria o importante é Vai ser entreue logo.

No desenvolvimento ágil essas etapas, não perceptíveis ao cliente, devem existir, até pra respeitar o princípio de Responding to change over following a plan. Como responder as mudanças de maneira ágil se a maior parte do tempo se está apagando incêndios causados pela pressa de uma entrega?

No fim, vários desses problemas são gerados por má compreensão/interpretação do manifesto, que por sua vez, deve ser criticado, revisado e não ser levado como um dogma.

Interessante! Podemos gerar uma discussão construtiva sob a perspectiva de correlação e causalidade. Afinal, correlação não implica causalidade.

Há diversos fatores que podem influenciar o sucesso ou fracasso de um projeto: competência da equipe, complexidade, suporte da gestão, entre outros. Se projetos com requisitos bem documentados antes de iniciarmos o desenvolvimento possuem maior probabilidade de sucesso (de acordo com o estudo), isto implica que a clareza e precisão de requisitos são fatores críticos para o sucesso, independentemente da metodologia utilizada (aqui podemos eliminar um pouco o viés de qual a melhor metodologia, certo?).

É possível que projetos ágeis falhem não por causa das práticas ágeis em si, mas devido à má implementação ou interpretação dessas práticas, como por exemplo subestimar a importância da documentação.

Por fim, acredito que seja fundamental não esquecer que todas as metodologias possuem suas próprias falhas e desafios. Waterfall, por exemplo, criticado por ser lento e custoso, com mudanças difíceis de implementar. A busca por alternativas pode ser baseada na compreensão equilibrada das vantagens e desvantagens.

Exato, já havia falado sobre, isso, não pagam o tempo para testar e documentar, então segura o código espaguete aí.

gente, ninguém percebeu que 268% de chances simplesmente nao existe? nao faz sentido estatístico você ter 268% de chances de algo. É praticamente "intervenção divina"! kkkkk. Imagina, você vai começar um projeto e você não tem só 100% de chances de dar errado não, você tem 268%, ou seja, seu projeto vai fracassar miseravelmente em dois universos paralelos e você ainda vai ter 68% de chances de estragar sua vida em um terceiro universo. kkkkk é bizarro o que fazem como usam os números para nos enganar.
ps.não uso ágil, só cascata.

Qual o mundo Real vai entender e aprender que a Criatividade Tecnica do Desencolvimento e Programação de Software não é nem nunca será uma esteira produtiva fabril ??? Metodologias ageis são apenas um Norte e não uma Ferramenta de Resultados praticos feito Pastelaria !!!

A reportagem sobre a falha dos projetos de software Ágeis soa um pouco superficial, pois não especifica quais metodologias, frameworks ou métodos Ágeis foram usados para chegar a esses resultados.
Existem várias abordagens Ágeis como Scrum, Kanban e Lean, cada uma adequada para diferentes tipos de projetos. A escolha da ferramenta errada geralmente é um problema de gestão, não dos métodos Ágeis em si.
Por exemplo, ao usar Scrum, é essencial considerar a experiência do Scrum Master (SM) e se a equipe tem as pessoas certas como Product Owner (PO), Scrum Master e Time de Desenvolvimento. Além disso, para afirmar que há 268% mais chances de falhar, seria interessante saber se as equipes estavam utilizando práticas como DevOps, DevSecOps, TDD (Test-Driven Development), BDD (Behavior-Driven Development), ou guias de gerenciamento como ITIL ou COBIT. Muitas organizações também desenvolvem seus próprios métodos Ágeis para se adequarem às suas necessidades específicas.
Um estudo mais completo abordaria essas questões e daria uma visão mais precisa da realidade. Não me coloco nem como defensor nem como opositor, pois é tolice defender uma metodologia simplesmente por preferência. A decisão de usar Ágil ou não deve ser baseada em dados e fatos sólidos.
Acho que dados e fatos sólidos para responder a essas perguntas são difíceis de obter. Um estudo completo e bem feito nesse sentido traria muitos benefícios. Mas, a reportagem atual é tão útil quanto dizer que bolas redondas não são ideais para futebol, sem especificar se estamos falando de futebol americano ou futsal.

Tirar o "SCRUM" do curriculo então?

Fake news go horse não dá quality