I'm not an expert for the Spiral Model, but from the wikipedia-definition, it seems to me that there are some significant differences.
For example, in an Agile project, at the end of an iteration doesn't stand a prototype, but a fully functional, fully tested, potentially deployable (1) system, containing the highest priority features on the feature list.
The requirements gathering at the start of the project is meant to be just barely enough to get going (to take the next step) and are meant the be fleshed out just shortly before they get actually implemented. Changes are to the requirements are welcomed.
Also, there is much more to Agile than just doing iterative development - a focus on faces to face conversation instead of written communication, a focus on bringing business people and technical together in their day-to-day work. A focus in collaboratively maximizing value instead of defining and then fulfilling a contract.
In case you didn't see it yet, take a look at the Agile Manifesto, which basically is the definition for Agile Software Development.
(1) That doesn't mean that it has to make business sense to deploy the system, "just" that it is technically feasible. It should be a pure business decision whether to deploy the system at the end of an iteration.
I believe Agile is type of Iterative SDLC while spiral is type of Incremental SDLC. Scrum is one the type of Agile other are DSDM/FDD/XP etc. All SDLC after waterfall followed same set of acts(Requirement Analysis, Design, Coding and Testing) in some different combinations. So basic set of action in sequential OR Iterative OR Incremental are same.
As far as Agile and Spiral are concern both have common advantage 1.Changing Requirement handling 2.Short term releases 3.Risk management is easy due to shorter duration of SDLC 4.Cross team helps product and project going smooth
First Agile is actually a number of different processes that follow a similar philosophy. One of the philosophy's that makes it different is that each iteration produces a working product. It could be described as iterative and incremental. A lot of emphasis is placed on the working product and on testing. In many agile models testing comes before coding.
In the spiral model the number of iterations are fixed, while each phase of an agile model may consist of any number of iterations.
You are right that there are similarities but the underlying philosophy makes the difference. This page explains in more detail and compares agile to other methods.
You can say that agile processes are Use Case driven...placing a lot of emphasis on people, the end user.
I'd say spiral and agile are similar. However, lately agile has often seemingly become a propaganda system to excuse cowboy coding. I.e.
Extremely minimal requirements
Minimal technical analysis
Minimal documentation
No code comments
Special Bonus-- misuse of Domain Driven Design to over-complicate the object model
This was never the idea with spiral. I would argue that it's not really the point of Agile either, although you'd be surprised how many times I've seen this recently. More and more experienced developers/PMs are beginning to see the wisdom of a more balanced approach between waterfall and "agile" -- perhaps this simply brings us back to spiral.
Although there are some useful ideas in the Agile mind-space, it often seems as though it manifested from people who were in organizations that had particularly over-burdensome/unhelpful software design methodologies, and was a reaction/over-reaction to that.
Agile is spiral. Totally. In part, the name was changed for marketing purposes.
The problem is that spiral tends to imply "big design up front" -- where you plan out many spirals, each in order of risk. Spiral, however, isn't Agile -- it's just incremental execution in order of risk.
One big distinction that Agile adds is the "don't overplan things you can't know yet." Agile is spiral, but you create detailed plans for just one increment at a time.
Agile adds a lot of other things, also. Spiral is a very technical approach. Agile, however, recognizes that technology is built by people. The Agile Manifesto has four principles that are above and beyond the Boehm's simple risk management approach.
The basic difference, as I see it, is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.
They are similar in that they are iterative. They differ in the implementation and understanding of what an iteration is.
发布评论
评论（6）
我不是螺旋模型的专家，但从维基百科的定义来看，在我看来存在一些显着的差异。
例如，在敏捷项目中，迭代结束时并不存在原型，而是一个功能齐全、经过充分测试、可能可部署的 (1) 系统，其中包含功能列表中最高优先级的功能。
项目开始时收集的需求只是勉强足以开始（采取下一步），并且意味着在实际实施之前不久就会充实起来。 欢迎对要求进行更改。
此外，敏捷不仅仅是进行迭代开发 - 注重面对面对话而不是书面沟通，注重将业务人员和技术人员在日常工作中结合在一起。 专注于协作最大化价值，而不是定义然后履行合同。
如果您还没有看到，请查看敏捷宣言，它基本上是敏捷软件的定义发展。
(1) 这并不意味着部署该系统必须具有商业意义，“只是”它在技术上可行。 是否在迭代结束时部署系统应该是一个纯粹的业务决策。
I'm not an expert for the Spiral Model, but from the wikipedia-definition, it seems to me that there are some significant differences.
For example, in an Agile project, at the end of an iteration doesn't stand a prototype, but a fully functional, fully tested, potentially deployable (1) system, containing the highest priority features on the feature list.
The requirements gathering at the start of the project is meant to be just barely enough to get going (to take the next step) and are meant the be fleshed out just shortly before they get actually implemented. Changes are to the requirements are welcomed.
Also, there is much more to Agile than just doing iterative development - a focus on faces to face conversation instead of written communication, a focus on bringing business people and technical together in their day-to-day work. A focus in collaboratively maximizing value instead of defining and then fulfilling a contract.
In case you didn't see it yet, take a look at the Agile Manifesto, which basically is the definition for Agile Software Development.
(1) That doesn't mean that it has to make business sense to deploy the system, "just" that it is technically feasible. It should be a pure business decision whether to deploy the system at the end of an iteration.
我相信敏捷是迭代 SDLC 的类型，而螺旋是增量 SDLC 的类型。 Scrum 是敏捷的一种类型，其他还有 DSDM/FDD/XP 等。
瀑布之后的所有 SDLC 都以一些不同的组合遵循相同的一组行为（需求分析、设计、编码和测试）。 因此，顺序或迭代或增量中的基本操作集是相同的。
就敏捷和螺旋而言，两者都有共同的优势
1.改变需求处理
2.短期发布
3.SDLC持续时间较短，风险管理容易
4.跨团队帮助产品和项目顺利进行
I believe Agile is type of Iterative SDLC while spiral is type of Incremental SDLC. Scrum is one the type of Agile other are DSDM/FDD/XP etc.
All SDLC after waterfall followed same set of acts(Requirement Analysis, Design, Coding and Testing) in some different combinations. So basic set of action in sequential OR Iterative OR Incremental are same.
As far as Agile and Spiral are concern both have common advantage
1.Changing Requirement handling
2.Short term releases
3.Risk management is easy due to shorter duration of SDLC
4.Cross team helps product and project going smooth
首先敏捷实际上是遵循类似理念的许多不同过程。 使其与众不同的理念之一是每次迭代都会产生一个工作产品。 它可以被描述为迭代和增量。 重点放在工作产品和测试上。 在许多敏捷模型中，测试先于编码。
在螺旋模型中，迭代次数是固定的，而敏捷模型的每个阶段可以由任意次数的迭代组成。
你说得对，有相似之处，但潜在的哲学却有所不同。 此页面更详细地解释了敏捷方法并将其与其他方法进行了比较。
您可以说敏捷流程是用例驱动的……非常重视人（最终用户）。
First Agile is actually a number of different processes that follow a similar philosophy. One of the philosophy's that makes it different is that each iteration produces a working product. It could be described as iterative and incremental. A lot of emphasis is placed on the working product and on testing. In many agile models testing comes before coding.
In the spiral model the number of iterations are fixed, while each phase of an agile model may consist of any number of iterations.
You are right that there are similarities but the underlying philosophy makes the difference. This page explains in more detail and compares agile to other methods.
You can say that agile processes are Use Case driven...placing a lot of emphasis on people, the end user.
我想说螺旋和敏捷是相似的。 然而，最近敏捷似乎经常成为一种为牛仔编码开脱的宣传系统。 即，
这从来都不是螺旋的想法。 我认为这也不是敏捷的真正意义，尽管你会惊讶于我最近多次看到这种情况。 越来越多经验丰富的开发人员/PM 开始看到瀑布式和“敏捷”之间更加平衡的方法的智慧 - 也许这只会让我们回到螺旋式发展。
尽管在敏捷的思维空间，通常看起来像是来自那些在具有特别繁重/无用的软件设计方法的组织中的人们，并且是对此的反应/过度反应。
I'd say spiral and agile are similar. However, lately agile has often seemingly become a propaganda system to excuse cowboy coding. I.e.
This was never the idea with spiral. I would argue that it's not really the point of Agile either, although you'd be surprised how many times I've seen this recently. More and more experienced developers/PMs are beginning to see the wisdom of a more balanced approach between waterfall and "agile" -- perhaps this simply brings us back to spiral.
Although there are some useful ideas in the Agile mind-space, it often seems as though it manifested from people who were in organizations that had particularly over-burdensome/unhelpful software design methodologies, and was a reaction/over-reaction to that.
敏捷是螺旋式的。 完全。 部分名称的更改是出于营销目的。
问题在于，螺旋往往意味着“预先进行大设计”——你计划出许多螺旋，每个螺旋都按风险顺序排列。 然而，螺旋并不是敏捷——它只是按照风险顺序增量执行。
敏捷增加的一大区别是“不要过度计划你还不知道的事情”。
敏捷是螺旋式的，但是您一次只为一个增量创建详细的计划。
敏捷还增加了很多其他东西。 螺旋是一种非常技术性的方法。 然而，敏捷认识到技术是由人构建的。 敏捷宣言有四个原则，超越了 Boehm 的简单风险管理方法。
Agile is spiral. Totally. In part, the name was changed for marketing purposes.
The problem is that spiral tends to imply "big design up front" -- where you plan out many spirals, each in order of risk. Spiral, however, isn't Agile -- it's just incremental execution in order of risk.
One big distinction that Agile adds is the "don't overplan things you can't know yet."
Agile is spiral, but you create detailed plans for just one increment at a time.
Agile adds a lot of other things, also. Spiral is a very technical approach. Agile, however, recognizes that technology is built by people. The Agile Manifesto has four principles that are above and beyond the Boehm's simple risk management approach.
在我看来，基本的区别在于大多数螺旋式开发模型仍然坚持大型的预先设计。 重点是尽可能多地了解系统的使用方式； 发现所有用例。 一旦了解了这些，就可以设计系统并将其分解为遵循迭代详细设计、实现、测试、重构设计循环的阶段。 在敏捷中，他们是一些预先计划——也许收集大颗粒的理解（故事标题）——以便可以描述合理的版本，但每个版本都是独立计划的，我们延迟发现细节，直到我们准备好开始该版本的实施。 我们期待改变，并且不会试图首先了解一切。
另一个不同之处是大多数敏捷哲学都涉及“测试优先”方法。 这与螺旋式不同，在螺旋式螺旋式中，测试本身通常是一项活动，并且测试不是在代码之前开发的。 大多数情况下，它们是提前规划的，但并行开发或在编码之后开发。 许多敏捷方法坚持首先开发测试作为代码规范。
它们的相似之处在于它们都是迭代的。 它们在迭代的实现和理解上有所不同。
The basic difference, as I see it, is that most Spiral models of development still insist on big, up-front design. The emphasis is on knowing as much as you can about how the system will be used; discovering all the use cases. Once you know these, then you design the system and break it down into phases that follow an iterative detail-design, implementation, test, refactor-design loop. In Agile, their is some up-front planning -- perhaps gathering large grain understanding (story titles) -- so that reasonable releases can be described, but each release is planned independently and we delay discovery of the details until we are ready to begin implementation of that release. We expect change and don't try to know everything first.
Another thing that differs is that most Agile philosophies involve "test-first" methods. This is different from spiral where testing is often an activity unto itself and tests are not developed prior to code. Most often they are planned in advance, but developed in parallel or after coding. Many agile methods insist on developing tests first as the specification for the code.
They are similar in that they are iterative. They differ in the implementation and understanding of what an iteration is.