问SDLC的敏捷Vs螺旋模型

EN

敏捷螺旋()就是敏捷螺旋。完全是这样。在某种程度上，更名是为了营销目的。

问题是，螺旋倾向于暗示“预先的大设计”--你计划了许多螺旋，每个螺旋都是按风险排序的。然而，螺旋不是敏捷--它只是按照风险的顺序递增执行。

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

敏捷还增加了很多其他的东西。螺旋是一种非常技术性的方法。然而，敏捷认识到技术是由人建立的。Agile Manifesto有四条原则，这四条原则超出了博姆的简单风险管理方法。

在我看来，最基本的不同之处在于，大多数螺旋开发模型仍然坚持大的、预先的设计。重点是尽可能多地了解系统将如何使用；发现所有用例。一旦你知道了这些，然后你设计系统并将其分解成迭代细节-设计，实现，测试，重构-设计循环。在敏捷中，他们是一些预先的计划--也许是收集大颗粒的理解(故事标题) --以便合理的发布可以被描述，但是每个发布都是独立计划的，我们推迟发现细节，直到我们准备好开始实现那个发布。我们期待着变化，而不是试图先知道所有事情。

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

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

我不是螺旋模型的专家，但从维基百科的定义来看，似乎有一些显著的区别。

例如，在敏捷项目中，在迭代的末尾并不是一个原型，而是一个功能齐全、经过充分测试、潜在可部署的系统，包含特性列表中最高优先级的特性。

在项目开始时收集的需求意味着仅能勉强开始(下一步)，并意味着在实际实施之前不久就会充实。欢迎对要求进行更改。

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

如果您还没有看到它，请看一下Agile Manifesto，它基本上是敏捷软件开发的定义。

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