Existem estudos sobre Eficiência / Efetividade de Agile vs Waterfall [fechado]

Em uma reunião no outro dia, alegou-se que o ágil era apenas 60% mais eficiente no tempo de desenvolvimento quando comparado ao cascata. Não pretendo validar ou refutar esta reivindicação. Eu sou interessante em descobrir se houve algum estudo comparando as duas metodologias.

Existem estudos por aí comparando os dois?

O livro "Making Software: O que realmente funciona e por que acreditamos" tem alguns capítulos sobre métodos Agile, incluindo XP, Scrum, Dynamic Software Development e Lean, com bom suporte científico. É de alta qualidade, como seria de esperar de O'Reilly. Um dos editores foi o excelente Greg Wilson , um autor, editor e apresentador confiável de ciência da computação.

O livro em si resume vários estudos de pesquisa, incluindo muitos sobre agile. Uma seção resume pesquisas incluindo "Duas cabeças pensam melhor que uma? Sobre a eficácia da programação em pares", de Dybå, T .; Arisholm, E .; Sjøberg, DIK; Hannay, JE; Shull, F.; e " Estudos empíricos do desenvolvimento ágil de software: uma revisão sistemática " de Tore Dybå e Torgeir Dingsøyr.

O senso geral é que a maioria das práticas ágeis são benéficas, mas que os efeitos da programação em pares, TDD e outros inquilinos ágeis não são tão fortes quanto se poderia esperar. Há até uma nota de rodapé perturbadora de que o TDD pode ser de fato um pouco viciante *.

O livro é uma ótima maneira de obter acesso a muitas pesquisas já realizadas, tudo em um todo coeso. Existem alguns blogs e outros sites na web que revisam o livro.

* Esta não é necessariamente minha opinião!

Por mais que eu não goste do título, acredito que o equilíbrio entre agilidade e disciplina: um guia para os perplexos pode conter algumas informações relevantes para você. Este livro de dois especialistas em gerenciamento de processos e processos de engenharia de software - Barry Boehm e Richard Turner. Este livro analisa vários aspectos das metodologias ágeis e orientadas a planos, as compara e contrasta e também discute sua integração para obter uma situação "melhor dos dois mundos".

O Apêndice E de Balanceamento de Agilidade e Disciplina contém uma grande quantidade de informações empíricas sobre os custos e benefícios de vários métodos ágeis e orientados a planos. No entanto, parece não haver dados sobre a eficácia do tempo. Mas, olhando através dos dados, parece (como eu suspeitava) que essa não é uma opção de escolha - alguns projetos tiveram menos esforço, agendas mais rápidas e defeitos menores ao aplicar métodos ágeis. No entanto, outros projetos que usaram. A seção discute vários projetos diferentes em diferentes setores, o tipo de processo que eles usaram e o que eles experimentaram ao longo do projeto.

Existem muitos estudos de caso citados no Apêndice E que fornecem esses dados. Há muitos para eu começar a nomear aleatoriamente, já que muitos estão focados em um setor específico ou mesmo dentro de uma organização específica. Se você examinar os casos, sugiro que você encontre aqueles de natureza semelhante à sua equipe, projeto, organização e setor para tirar conclusões razoavelmente válidas.

Em Desenvolvimento rápido: domesticando agendas de software selvagem , Steve McConnell identifica vários fatores a serem considerados ao escolher uma metodologia de ciclo de vida: nível de entendimento dos requisitos, nível de entendimento da arquitetura, confiabilidade desejada, gerenciamento de riscos, restrições de cronograma, quantidade de processo sobrecarga, "correções de curso" no meio do projeto, capacidade de fornecer visibilidade ao cliente, capacidade de fornecer visibilidade ao gerenciamento e sofisticação da equipe e do gerenciamento de desenvolvimento. Também existem outros, como a cultura organizacional, portanto, provavelmente não há uma lista exaustiva em nenhum lugar.

Mesmo com o mesmo projeto, há também o fator de equipe. Se você pegar uma equipe que tenha fornecido software de forma consistente usando a metodologia espiral orientada a planos e lançá-los no Scrum, eles sofrerão uma diminuição na produtividade, um aumento no thrashing e terão que superar um novo modelo de processo antes que possam vir. em torno de ser bem sucedido. Embora outra metodologia possa ser mais adequada, sempre há a necessidade da empresa de realmente entregar o software. É por isso que os esforços de melhoria de processo são frequentemente de longo prazo e não da noite para o dia - as principais mudanças são chocantes para a equipe e (mesmo que a metodologia seja mais adequada no papel) podem causar uma diminuição na produtividade.

Há muito mais do que simplesmente eficiência ou eficácia do processo, e você não pode simplesmente olhar para um instantâneo da mesma equipe trabalhando em um ambiente orientado a planos e um ambiente ágil. Você precisa considerar o contexto industrial e organizacional, os atributos do projeto, a equipe, o cliente e assim por diante ao tomar uma decisão.

Com base no que li, terei que discordar da avaliação de seus colegas de trabalho. Tenho certeza de que você pode encontrar algum estudo de caso em algum lugar em que um projeto ágil seja 60% menos eficiente em relação a alguma métrica de desempenho do que um projeto similar orientado a planos. No entanto, também existem estudos que mostram que o ágil gera 80% menos esforço, 50% menos tempo e alta satisfação do cliente com o produto.

Não tenho estudo, mas gostaria de comunicar minha experiência.

A eficácia de qualquer uma das metodologias mencionadas depende muito dos analistas.

Quando você tem um ótimo proprietário de produto, o SCRUM, por exemplo, é certamente mais rápido do que uma abordagem em cascata com especificações ruins.

Ágil com um proprietário de produto ruim é certamente mais lento que uma cascata com uma grande especificação.

No entanto, na maioria das vezes, não sabemos os requisitos exatos com antecedência suficiente e as metodologias ágeis têm ciclos de feedback mais rápidos. Isso significa que, em terrenos incertos, o agile é um método melhor para fornecer um produto de alta qualidade a custos razoáveis. Existem inúmeras outras vantagens, por exemplo, projetos ágeis são mais fáceis de cancelar quando não funcionam e, portanto, podem reduzir a perda ao mínimo.

Pode-se dizer que metodologias ágeis reduzem o risco, enquanto a cascata, mesmo que às vezes seja mais rápida, pode ser uma aposta monetária.

ágil foi apenas 60% mais eficiente no tempo de desenvolvimento

Verdade.

Mas, isso é uma medida fraca.

Métodos ágeis geralmente oferecem valor real mais cedo.

O Waterfall simplesmente adere a um cronograma, independentemente do que é entregue e, muitas vezes, não entrega nada de valor até que um grande período de tempo seja passado.

Mais distante.

Você pode medir o "tempo de desenvolvimento" separado de "tempo de desenvolvimento e teste".

Ágil geralmente inclui testes. Então parece mais lento.

O desenvolvimento em cascata pode ser claramente separado dos testes. Portanto, o código está "pronto para testar" mais cedo. Mas não é "feito" até muito mais tarde.

Tão. Eles estão totalmente certos. Pelo que eles mediram.