敏捷是RAD的变体吗？

维基百科说敏捷是一种“ RAD”，我猜是不正确的。据我所知，敏捷开发是因为RAD本身在90年代并没有那么成功（对于变更而言过于僵化）。还是我错了？

（注：显然在Wikipedia上，有关敏捷软件开发的文章有所改进，只是将RAD列为敏捷的前身，而不是超集）。

本书来自Radical Project Management（Thomsett）

“ ..新的开发风尚，例如RAD，敏捷，面向对象...”

CISA认证信息系统审核员：

..意识到两个替代软件的开发。方法：敏捷和快速的应用程序开发

软件的敏捷管理：

敏捷方法主要源自RAD的轻量级方法。

软件评估最佳做法：

SW的主要方法。开发。可以概括如下：
1.瀑布..
4. RAD
5.敏捷

这个问题的重点是：
是RAD的敏捷类型还是独立的开发方法？

RAD的术语比敏捷的术语要早十年左右，但它实际上并不是敏捷的“父母”。两者都是对传统软件开发管理技术对已知缺点的反应。但是，RAD是一种编写软件的规范方法，它使用连续的原型来引出需求并改进应用程序。最初引入的敏捷是一种哲学立场，描述了传统方法与敏捷实践者所关注的价值观之间的差异。

因此，不，敏捷软件开发不是RAD的一种。他们以不同的抽象层次解决问题。

我认为在层次结构中对开发方法进行分类是不正确的。因此，没有任何一种方法可以“低于”或“高于”其他方法。考虑方法论的共同点要合乎逻辑。方法论在现实世界中的应用经常涉及许多相似方法论的结合，并且管理者需要提出可行的开发模型。

在RAD（我没有经验）和Agile的情况下，似乎只有通用性是迭代开发。RAD似乎更喜欢具有特定目标和输出的刚性阶段。敏捷更多地是在发生一切的单一开发阶段。此外，Agile直接开发软件，可能会删除功能，而不是预先制作原型。（最终可能与敏捷相同，因为很多时候原型会立即集成到工作软件中，而不是再次正确执行）

敏捷方法论更具剃须刀模式，因为它旨在以迭代模型构建应用程序，并向利益相关者进行快速迭代演示。它并没有免除开发人员保留设计范式（尤其是模块化）的注意，但并没有直接强调它，而是专注于不断提供迭代并快速响应业务需求的快速变化。它实际上是针对隔离产品的开发而设计的，并且可以在产品的框架中工作。但是，它不需要明确地重用解决方案的组件，而且，不需要在公司级别为产品系列构建任何通用平台。没有人会赞成将同一工作重复N次。幸运的是，RAD从领域，模块及其集成，以及从技术角度将开发分开，更适合于开发模型的技术组织，从公司技术管理的角度来看这是合理的。这使得该模型更加灵活，解决方案可重用，并且可以适应其他产品。最后-公司不是自由职业者的社区，并且比一个产品的寿命更长。但是，如果一家公司生产的单个产品没有任何迁移和修改，那么RAD的作用就不是那么具有表现力。但是通常，敏捷的业务优势与RAD的技术组织优势完美地结合在一起。最后，公司不是自由职业者的社区，并且比一个产品的寿命更长。但是，如果公司生产的单个产品没有任何迁移和修改，那么RAD的作用就不是那么具有表现力。但是通常，敏捷的业务优势与RAD的技术组织优势完美地结合在一起。最后，公司不是自由职业者的社区，并且比一个产品的寿命更长。但是，如果公司生产的单个产品没有任何迁移和修改，那么RAD的作用就不是那么具有表现力。但是通常，敏捷的业务优势与RAD的技术组织优势完美地结合在一起。