Является ли Agile вариантом RAD?

Википедия говорит, что Agile - это тип «RAD», который, я думаю, неверен. Из того, что я знаю, Agile был разработан, потому что сам RAD не был настолько успешным в 90-х (слишком жестким для изменений). Или я не прав?

(Примечание: очевидно, что статья в Википедии о разработке программного обеспечения Agile была улучшена в промежутке, она просто перечисляет RAD как предшественника Agile, а не как надмножество).

Ссылка из книги «Радикальное управление проектами» (Томсетт)

"... новые разработки, такие как RAD, Agile, объектно-ориентированные ..."

Сертифицированный аудитор информационной системы CISA:

... осведомлен о двух альтернативных программных разработках. методы: гибкая и быстрая разработка приложений

Гибкое управление для программного обеспечения:

Гибкие методы в основном основаны на облегченном подходе RAD.

Лучшие практики оценки программного обеспечения:

Основные методы SW. девиация можно подытожить следующим образом:
1. Водопад ..
4. RAD
5. Agile

Суть этого вопроса:
Agile-тип RAD или автономный подход к разработке?

RAD как термин предшествует Agile как термин примерно на десять лет, но на самом деле он не является «родителем» Agile. Оба были созданы как реакция на обнаруженные недостатки с традиционными методами управления разработкой программного обеспечения. Тем не менее, RAD - это предписывающий метод написания программного обеспечения, использующий последовательные прототипы для выявления требований и уточнения приложения. Agile, в первоначально введенной форме, представляет собой философскую позицию, описывающую разницу между традиционными подходами и ценностями, на которых сосредоточены проворные практики.

Так что нет, гибкая разработка программного обеспечения не является типом RAD; они решают проблемы на разных уровнях абстракции.

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

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

Гибкая методология имеет более строгий режим, потому что ориентирована на создание приложения в итерационной модели с быстрой итеративной демонстрацией заинтересованным сторонам. Он не освобождает разработчиков от сохранения парадигм проектирования (особенно модульности), но не подчеркивает их напрямую, концентрируясь на непрерывной доставке итераций и быстрой реакции на быстрое изменение бизнес-требований. Он де-факто ориентирован на разработку изолированного продукта и работает в рамках продукта. Но он не требует однозначного повторного использования компонентов решений и, кроме того, - создания какой-либо общей платформы для семейства продуктов на уровне компании. Ни один технический менеджер не будет сторонником повторения одной и той же работы N раз. К счастью, RAD разделяет разработку по доменам, модулям и их интеграции, а также с технической точки зрения, более применима для технической организации модели развития, которая является разумной с точки зрения технического менеджмента компании. Это делает модель более гибкой, пригодной для повторного использования и адаптируемой для других продуктов. Наконец, компания не является сообществом фрилансеров и имеет более продолжительную жизнь, чем жизнь одного продукта. Однако, если компания производит один продукт без какой-либо миграции и модификации, то роль RAD не столь выразительна. Но обычно сильные стороны бизнеса Agile превосходно сочетаются с сильными сторонами RAD в сфере организации. Наконец, компания не является сообществом фрилансеров и имеет более продолжительную жизнь, чем жизнь одного продукта. Однако, если компания производит один продукт без какой-либо миграции и модификации, то роль RAD не столь выразительна. Но обычно сильные стороны бизнеса Agile превосходно сочетаются с сильными сторонами RAD в сфере организации. Наконец, компания не является сообществом фрилансеров и имеет более продолжительную жизнь, чем жизнь одного продукта. Однако, если компания производит один продукт без какой-либо миграции и модификации, то роль RAD не столь выразительна. Но обычно сильные стороны бизнеса Agile превосходно сочетаются с сильными сторонами RAD в сфере организации.