agile - SDLC 的敏捷与螺旋模型

Question

我相信敏捷不过是螺旋模型的另一种实现。我是 Spiral 的大力支持者（螺旋模型是一个软件开发过程，结合了设计和原型设计阶段的元素，努力结合自上而下和自下而上概念的优势），并且已经看到许多项目在不知道它们在螺旋世界中运行的情况下实施螺旋。从敏捷开始流行的那一天起，螺旋的概念就开始被忽视了。我确信对于复杂的项目螺旋仍然是最好的选择，但我想更好地了解敏捷和螺旋技术之间的异同。谁能解释他们的差异/相似之处？

Answer 1

敏捷是螺旋式的。完全。部分原因是出于营销目的而更改了名称。

问题是螺旋往往意味着“预先设计大”——你计划出许多螺旋，每个螺旋都按风险顺序排列。然而，Spiral 并不是敏捷——它只是按风险顺序执行的增量执行。

敏捷增加的一大区别是“不要过度计划你还不知道的事情”。敏捷是螺旋式的，但您一次只为一个增量创建详细计划。

敏捷还增加了很多其他的东西。螺旋是一种非常技术性的方法。然而，敏捷认识到技术是由人构建的。敏捷宣言有四个原则，超越了 Boehm 的简单风险管理方法。

Answer 2

在我看来，基本的区别在于，大多数 Spiral 开发模型仍然坚持大型的预先设计。重点是尽可能多地了解系统的使用方式；发现所有用例。一旦您了解了这些，您就可以设计系统并将其分解为遵循迭代的详细设计、实施、测试、重构设计循环的阶段。在敏捷中，他们是一些预先计划——也许是收集大粒度的理解（故事标题）——以便可以描述合理的发布，但是每个发布都是独立计划的，我们会延迟发现细节，直到我们准备好开始该版本的实施。我们期待改变，不要试图先了解一切。

另一个不同的是，大多数敏捷哲学都涉及“测试优先”的方法。这与螺旋式不同，螺旋式测试通常是一项自身的活动，并且测试不是在代码之前开发的。大多数情况下，它们是提前计划好的，但同时或在编码之后开发。许多敏捷方法坚持首先开发测试作为代码的规范。

它们的相似之处在于它们是迭代的。它们在迭代的实现和理解上有所不同。

Answer 3

我不是螺旋模型的专家，但从维基百科的定义来看，在我看来存在一些显着差异。

例如，在敏捷项目中，迭代结束时不会有原型，而是功能齐全、经过充分测试、潜在可部署 (1) 的系统，其中包含功能列表中优先级最高的功能。

在项目开始时收集的需求只是勉强可以开始（采取下一步），并且意味着在它们实际实施之前不久就被充实。欢迎更改要求。

此外，敏捷不仅仅是进行迭代开发——专注于面对面的对话而不是书面交流，专注于在日常工作中将业务人员和技术人员结合在一起。专注于协作最大化价值，而不是定义然后履行合同。

如果您还没有看到它，请查看敏捷宣言，它基本上是敏捷软件开发的定义。

(1) 这并不意味着部署系统必须具有商业意义，“只是”它在技术上是可行的。是否在迭代结束时部署系统应该是一个纯粹的业务决策。

Answer 4

我相信敏捷是迭代 SDLC 的类型，而螺旋是增量 SDLC 的类型。Scrum 是敏捷的一种类型，其他是 DSDM/FDD/XP 等。瀑布之后的所有 SDLC 在一些不同的组合中遵循相同的一组行为（需求分析、设计、编码和测试）。所以顺序或迭代或增量中的基本动作集是相同的。

就敏捷和螺旋而言，两者都有共同的优势 1.更改需求处理 2.短期发布 3.由于 SDLC 的持续时间更短，风险管理很容易 4.跨团队帮助产品和项目顺利进行

Answer 5

首先，敏捷实际上是许多遵循相似理念的不同过程。使其与众不同的哲学之一是每次迭代都会产生一个工作产品。它可以被描述为迭代和增量。很多重点都放在工作产品和测试上。在许多敏捷模型中，测试先于编码。

在螺旋模型中，迭代次数是固定的，而敏捷模型的每个阶段可能包含任意次数的迭代。

你是对的，有相似之处，但潜在的哲学却有所不同。本页更详细地解释了敏捷与其他方法的比较。

你可以说敏捷过程是用例驱动的……非常强调人，最终用户。

Answer 6

我想说螺旋和敏捷是相似的。然而，最近敏捷似乎经常成为为牛仔编码开脱的宣传系统。IE

• 极低的要求
• 最少的技术分析
• 最少的文档
• 没有代码注释
• 特别奖励——滥用领域驱动设计使对象模型过于复杂

这从来不是螺旋式的想法。我会争辩说这也不是敏捷的真正意义，尽管你会惊讶于我最近看到了多少次。 越来越多有经验的开发人员/PM 开始看到在瀑布式和“敏捷”之间采用更平衡的方法的智慧——也许这只会让我们回到螺旋式。

尽管在敏捷思维空间中有一些有用的想法，但它通常似乎来自那些拥有特别繁重/无用的软件设计方法的组织中的人，并且是对此的反应/过度反应。