Является ли проворное научно доказанным?

Ответ 1

См. этот ответ на другой вопрос для некоторой информации о том, почему редко бывают хорошие эмпирические исследования по любым аспектам построения программного обеспечения.

Ответ 2

Научные? Ну, я очень впечатлен работой Алистера Кокберна. Слушайте его здесь

Алистер Кокберн был разработчиком аппаратного обеспечения и исследователем в течение 16 лет, когда IBM попросила его написать методологию для объектно-ориентированных проектов. В течение последнего десятилетия он изучал и писал о разработке программного обеспечения и узнал, что некоторые из наиболее успешных проектов имеют самые простые процессы. В 2001 году он и еще 16 других тяжеловесов по разработке программного обеспечения собрались для обсуждения так называемых легких методологий, и одним из результатов был Манифест разработки Agile Software Development, который включает в себя четыре заявления о ценности: отдельные лица и взаимодействия над процессами и инструментами; работающее программное обеспечение по полной документации; сотрудничество с клиентами по заключению договоров; и реагировать на изменения в соответствии с планом.

Ответ 3

Некоторые аспекты схватки имеют подтверждающие эмпирические данные. Проведено немало эмпирических исследований по разной части схватки. Я слышал, что Джефф Сазерленд (http://jeffsutherland.com/scrum/ изобретатель схватки) упоминает множество конкретных исследований и наблюдений в своих беседах.

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

Ответ 4

Лори Уильямс из NCSU опубликовал много действительно интересных исследований эффективности парного программирования, а затем начал заниматься более гранями гибких.

Ответ 5

Я не думаю, что можно "доказать" такую ​​вещь.

Я пойду еще дальше и скажу, что я не думаю, что действительно можно изучить вопрос "Производительность разработки программного обеспечения" с таким исследованием. Именно поэтому все доказательства, которые нам когда-либо были действительно, продолжались, - это то, что говорят нам опытные люди (и, к сожалению, у каждого из них разные взгляды на различные методологии).

Там есть простая причина: люди совершенно разные. Сядьте в команду из 5 человек для проекта в течение нескольких месяцев (что более того, я предполагаю, чем большинство исследований когда-либо управляют, пусть кто-нибудь финансирует несколько месяцев времени разработчиков), и вы обязательно получите полностью разные результаты. Проблема в том, что здесь нет возможности уладить множество разных факторов:

• Способность отдельных программистов.
• Посвящение/усилие, наложенное программистами.
• Опыт работы с инструментами.
• Способность любого, кто действует как руководитель группы (просто следовать методологии, недостаточно. Если кто-то не знает, как управлять командой, методология не будет действительно хорошо представлена).

И, вероятно, есть много факторов.

Так что я пытаюсь сказать, не верьте исследованиям, которые "доказали", что одна методология/инструмент/что-то работает лучше других. Их почти невозможно сделать.

Ответ 6

Нет, это не научно или не доказано. Для "доказательства" это означало бы:

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

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

С другой стороны, эмпирические исследования были проведены, но результаты необоснованны. Например, Роберт Гласс показывает некоторые интересные результаты в своей книге Software Creativity 2.0.

Так что нет, гибкость не доказана. Даже не близко.: -)

Ответ 7

То, что мне доказано, - это статистический провал водопада, т.е. научный менеджмент, применяемый для разработки программного обеспечения. Гибкость, как движение, является просто ответом на эти эмпирические данные (см., Например, отчеты CHAOS).

Ответ 8

Этот интервью с Linda Rising on InfoQ в какой-то мере затрагивает ваш вопрос. Она говорит об эффективности плацебо и наших убеждений в медицине и о том, как эти самые вещи могут относиться к разработке программного обеспечения. В основном, мы находимся в Agile-сообществе, давая себе "Sugar Pill"?

Отрывок из интервью

Наука о экспериментах, о том, чтобы провести идею на короткий период времени и проверить ее, а затем изучить результаты этого теста, чтобы выяснить, сохраняется ли гипотеза. Это действительно то, о чем говорит Agile. Agile - это небольшие эксперименты. Теперь я считаю, что все, что мы делаем, а не только разработка программного обеспечения, но наша жизнь должна быть серией небольших экспериментов.

Мы привлекаем всех заинтересованных сторон, привлекаем клиентов, привлекаем пользователей, тестировщики работают с разработчиками. Мы всегда тщательно изучаем эти сахарные таблетки. Это действительно работает? Как вы думаете? Вы довольны результатами? Это единственное, что спасает нас - само по себе. Эта серия небольших экспериментов.

Ответ 9

В этом документе анализируется рентабельность инвестиций (ROI) Agile vs Traditional methods. Это основано на фактических результатах опубликованных исследований.

Из реферата:

Agile Methods ROI был в четыре раза больше чем дорогие традиционные методы, в два раза меньше, чем недорогие, и лучший Agile и традиционный Методы имели равный ROI.