Есть ли какие-либо исследования по эффективности / результативности Agile vs Waterfall [закрыто]

На встрече на днях было заявлено, что agile был всего лишь на 60% эффективнее во время разработки по сравнению с водопадом. Я не собираюсь подтверждать или опровергать это утверждение. Мне интересно узнать, проводились ли какие-либо исследования, сравнивающие 2 методологии.

Есть ли какие-либо исследования, сравнивающие их?

Книга «Создание программного обеспечения: что действительно работает и почему мы в это верим» содержит несколько глав, посвященных гибким методам, включая XP, Scrum, динамическую разработку программного обеспечения и Lean, с хорошей научной поддержкой. Это высокое качество, как и следовало ожидать от O'Reilly. Одним из редакторов был превосходный Грег Уилсон , надежный автор компьютерных наук, редактор и ведущий.

В самой книге кратко изложены многочисленные исследования, в том числе и по agile. В одном разделе обобщены исследования, в том числе «Лучше ли две головы, чем одна? Об эффективности парного программирования» , Dybå, T .; Arisholm, E .; Шёберг, ДИК; Hannay, JE; Shull, F .; и « Эмпирические исследования гибкой разработки программного обеспечения: систематический обзор » Торе Дайбо и Торгейра Дингсойра.

Общий смысл заключается в том, что большинство гибких практик полезны, но эффект парного программирования, TDD и других гибких арендаторов не так силен, как можно было бы надеяться. Есть даже тревожная сноска, что TDD может на самом деле вызывать привыкание *.

Книга - отличный способ получить доступ ко многим исследованиям, которые были сделаны, все в одном целом. Есть несколько блогов и других сайтов в Интернете, которые рецензируют книгу.

* Это не обязательно мое мнение!

Как бы мне не нравилось название, я считаю, что « Балансировка ловкости и дисциплины: руководство для недоумевающих» может содержать некоторую информацию, которая имеет отношение к вам. Эта книга написана двумя экспертами в области разработки программного обеспечения и управления проектами - Барри Бём и Ричард Тернер. В этой книге рассматриваются различные аспекты гибких и управляемых планами методологий, сравниваются и сопоставляются их, а также обсуждается их интеграция для достижения ситуации «лучшего из двух миров».

Приложение E «Балансировка гибкости и дисциплины» содержит обширную эмпирическую информацию о затратах и ​​выгодах различных гибких и плановых методов. Тем не менее, нет никаких данных относительно эффективности времени. Но, просматривая данные, кажется (как я подозревал), что это не тот или иной выбор - некоторые проекты испытали меньшие усилия, более быстрые графики и меньшие дефекты при применении гибких методов. Тем не менее, другие проекты, которые использовали. В этом разделе рассматривается ряд различных проектов в разных отраслях, тип используемых ими процессов и опыт, которые они испытывали в ходе проекта.

В Приложении E приведено множество примеров, приводящих эти данные. Для меня слишком много, чтобы просто начать именовать случайным образом, поскольку многие из них сосредоточены в конкретной отрасли или даже в конкретной организации. Если вы собираетесь рассматривать дела, я бы предложил найти те из них, которые по своей природе похожи на вашу команду, проект, организацию и отрасль, чтобы сделать достаточно обоснованные выводы.

В статье «Быстрое развитие: Укрощение графиков программного обеспечения» Стив Макконнелл выделяет ряд факторов, которые следует учитывать при выборе методологии жизненного цикла: уровень понимания требований, уровень понимания архитектуры, желаемая надежность, управление рисками, ограничения графика, объем процесса накладные расходы, «корректировка курса» в середине проекта, способность предоставить заказчику видимость, способность обеспечить управление видимостью, а также изощренность команды разработчиков и руководства. Есть и другие, такие как организационная культура, так что, вероятно, нигде нет исчерпывающего списка.

Даже учитывая точно такой же проект, есть и командный фактор. Если вы возьмете команду, которая постоянно поставляла программное обеспечение с использованием методологии, основанной на планировании спирали, и бросили ее в Scrum, то они столкнутся с падением производительности, увеличением обмолота и должны будут преодолеть новую модель процесса, прежде чем они смогут прийти. вокруг, чтобы быть успешным. Даже при том, что другая методология может быть более подходящей, всегда есть деловая потребность фактически поставить программное обеспечение. Вот почему усилия по улучшению процессов часто являются долгосрочными усилиями, а не в одночасье - серьезные изменения шокируют команду и (даже если методология может лучше подходить на бумаге) могут привести к снижению производительности.

Это намного больше, чем просто эффективность или результативность процесса, и вы не можете просто посмотреть на снимок той же команды, работающей в среде, управляемой планом, и в гибкой среде. При принятии решения необходимо учитывать производственный и организационный контекст, атрибуты проекта, команды, клиента и т. Д.

Исходя из того, что я прочитал, мне придется не согласиться с вашей оценкой коллег. Я уверен, что вы можете найти какое-то конкретное исследование, где быстрая гибкость проекта была на 60% менее эффективной по некоторым показателям производительности, чем аналогичный проект, управляемый планом. Тем не менее, есть также исследования, которые показывают, что Agile дает на 80% меньше усилий, на 50% меньше времени и высокую степень удовлетворенности клиентов продуктом.

У меня нет учебы, но я бы хотел поделиться своим опытом.

Эффективность любой из упомянутых методологий сильно зависит от аналитиков.

Если у вас есть отличный владелец продукта, то, например, SCRUM, безусловно, быстрее, чем водопадный подход с плохой спецификацией.

Agile с плохим владельцем продукта, конечно, медленнее, чем водопад с отличными характеристиками.

Однако чаще всего мы не знаем точных требований достаточно рано, и гибкие методологии имеют более быстрые циклы обратной связи. Это означает, что в условиях неопределенной местности Agile является лучшим способом доставки высококачественного продукта при разумных затратах. Есть множество других преимуществ, например, гибкие проекты легче отменить, когда они не работают, и, таким образом, могут снизить потери до минимума.

Можно сказать, что гибкие методологии снижают риск, в то время как водопад, даже если иногда он может быть быстрее, может быть довольно денежной игрой.

Agile был только на 60% эффективнее во время разработки

Правда.

Но это хромое измерение.

Гибкие методы обычно приносят реальную ценность раньше.

Водопад просто придерживается графика независимо от того, что доставлено, и часто не доставляет ничего ценного, пока не пройдет огромный промежуток времени.

Дальше.

Вы можете измерить «время разработки» отдельно от «времени разработки и тестирования».

Agile обычно включает в себя тестирование. Так что, кажется, медленнее.

Развитие водопада можно четко отделить от испытаний. Таким образом, код «готов к тестированию» раньше. Но не "сделано", пока гораздо позже.

Так. Они абсолютно правы. За что они мерили.