问敏捷是RAD的变体吗？

EN

RAD这个词比敏捷这个词早十年，但它并不是敏捷的“父”。两者都是作为对传统软件开发管理技术的缺陷的反应而创建的。然而，RAD是一种用于编写软件的指令性方法，它使用连续的原型来激发需求并细化应用程序。敏捷，在最初引入的形式中，是一个哲学立场，描述了传统方法与敏捷实践者所关注的价值观之间的差异。

因此，不，敏捷软件开发不是RAD的一种类型；它们在不同的抽象级别上解决问题。

我认为在雇用人员中对开发方法进行分类是不正确的。因此，没有任何方法是“低于”或“以上”任何其他。考虑方法的共同点更符合逻辑。在现实世界中，方法的应用常常涉及到许多类似方法的结合，这取决于管理人员提出工作开发模型。

在RAD (我不熟悉)和敏捷的情况下，似乎只有共同之处是迭代开发。RAD似乎更喜欢带有特定目标和产出的僵化阶段。敏捷更多的是关于单个开发阶段，在那里一切都会发生。此外，敏捷直接开发软件时，可能会删除特性，而不是预先进行原型设计。(这可能最终与敏捷相同，因为通常情况下，原型会立即集成到工作软件中，而不是再次正确地执行)

• 敏捷方法是面向迭代模式构建应用程序的，向涉众快速交付或演示，敏捷方法需要适合具体项目的开发过程。其主要思想是将一个项目分解为小型团队的小迭代，其中每个交互都是一个用户故事的小列表，可以在2-3周内实现，包括测试和交付。它强调工程师、利益相关者和领域专家之间的密切合作，以定义用户故事，甚至UML流程图来演示输出中必须包含的内容。最小的功能改变是应该的。然后，开始并执行产品的开发、测试和交付，以获得反馈。敏捷方法鼓励自主团队，他们决定如何执行开发过程。它不宣布任何要求的设计和工程规范，特别是固体，干燥，或技术限制。它可能与一家公司的设计和工程规范相冲突，该公司开发多个项目，并具有技术栈、设计和工程规范。公司的技术领导对重复多次的代码不感兴趣，或者使用相同类型的框架。因此，例如，敏捷并不否定许多团队重复开发相同的块。非常清楚的是，在现实生活中，敏捷团队应该在技术监督和约束下工作。在这种情况下，敏捷非常有效。简而言之，敏捷团队必须得到协调，并有一个共同的平台(这是官方的敏捷规则之外的)。
• 从工程的角度来看，RAD方法是更结构化的，包括业务建模、数据建模、流程(流程)建模、创建应用程序和测试周转。RAD将开发周期定义为比通常更短，并且更多地关注代码的重用块。当敏捷迭代交付实现时，RAD阶段面向产品的快速迭代原型(！)用户故事。与敏捷不同，RAD更面向对象，是模块化系统的一个很好的选择(许多作者都注意到了这一点)。RAD被标记为鼓励组件的可重用性，这对于组织公司规模的开发非常重要。RAD更适用于大型项目，而不是小型项目。对于进度监控，RAD不如敏捷那么友好。

但是.

• RAD也是针对封闭原型的，可伸缩性也是一个挑战。
• 尽管关注OOP和代码可重用性，但在我看来，RAD更多地与单核体系结构联系在一起，而不是与SOA和微服务体系结构联系在一起，而敏捷则是相反的。但是，当最初为这两种架构模式规划时，RAD当然可以应用于这两种架构模式。但是在这种情况下，整个RAD框架应该被划分为每个服务的类似敏捷的框，或者是基础设施框。
• 总之，尽管有许多相似之处，但在实际实践中，这些方法是不同的。

然而，它们可以结合到大型系统中。