敏捷开发和迭代式开发(敏捷型开发)

需求开发的迭代特性与软件开发过程的迭代开发有什么关系？它们会互相影响吗

迭代就是循环程序开发基本就这几个过程：提出需求对应需求反馈问题（包括新需求和原有BUG）解决问题（对应新需求和解决BUG）迭代就是不断循环3和4的过程中把程序做到尽可能满足客户的需求。这样做管理成本比较小，需要一定量的文档跟踪记

敏捷开发和迭代开发是一回事么

敏捷开发和迭代开发是不同的

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。

什么是迭代式开发？

每次只设计和实现这个产品的一部分,

逐步逐步完成的方法叫迭代开发,

每次设计和实现一个阶段叫做一个迭代。

在迭代式开发方法中，整个开发工作被组织为一系列的短小的、

固定长度（如3周）的小项目，被称为一系列的迭代。

每一次迭代都包括了需求分析、设计、实现与测试。

采用这种方法，开发工作可以在需求被完整地确定之前启动，

并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。

再通过客户的反馈来细化需求，并开始新一轮的迭代。

迭代式开发的优点：

1. 降低风险。

2. 得到早期用户反馈。

3. 持续的测试和集成。

4. 使用变更。

5. 提高复用性。

敏捷软件开发又称敏捷开发， 是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不 尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织 型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

人和交互 重于过程和工具。

可以工作的软件 重于求全而完备的文档。

客户协作重于合同谈判。

随时应对变化重于循规蹈矩。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

人员彼此信任 人少但是精干 可以面对面的沟通

项目的敏捷开发：

敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果；

关注业务优先级； 检查与调整。

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，

因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。

大规模的敏捷软件开发尚处于积极研究的领域。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，

最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。

敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

互联网产品都在使用「敏捷开发」模式，它的具体流程是什么样的？

前面我发过产品从发现需求到上线整个开发流程的文章，由于激烈额竞争和市场迅速的变化，几乎所有的团队在开发这块都采用了敏捷开发模式，今天就来跟大家详细聊聊这种开发模式到底是什么样的。

在这之前，简单说说另一种常见模式：瀑布流模式。它是以文档为驱动，在整个开发过程中，开发人员根据需求文档进行开发，一切以文档为依据。

而敏捷开发则是一种以人为核心、迭代、循序渐进的开发方法。它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人，注重的是人与人之间，面对面的交流，它只写有必要的文档，或尽量少写文档，采用的是迭代式开发，适用于以下情况：

敏捷开发的过程主要通过产品范围内迭代内容和周期的确认，规划合理的迭代范围，安排各岗位人员分步骤协同工作，通过开发过程中的任务项的快速跟进和渐进明细原则，保证资源的平衡和工作效率的最大化。

由产品经理驱动，订制公司产品战略，从而进行需求的采集与确定，根据竞品分析以及用户调研，进行产品原型的制作以及产品需求文档的撰写，在这个过程中，需要与项目经理进行评审，了解产品的开发难度以及可行性，从而对产品需求以及原型图进行合适地调整。

由 UE 完善产品原型的交互细节，有关页面的跳转等用户体验做到极致，然后由 UI 设计师进行界面的设计美化，及时与产品经理进行沟通，设计出与产品经理所想要的效果出来，结合自身的设计理念和技术，将界面设计得人性化、扁平化。

由开发人员进行产品具体的功能设计开发，根据项目进度安排时间，做好工作安排，认真查看设计图以及原型图、产品需求不懂，不清楚的地方及时与产品经理进行沟通，以免辛苦做出的功能与产品的意思不符，造成浪费时间精力的后果，产品进行开发完成后，由测试人员根据测试用例进行测试，将出现的问题进行反馈，及时修复产品的 bug，确保产品在规定的时间进行上线。

了解了这个流程，就容易解释为什么一旦产品出现问题，产品就成为当之无愧的背锅侠，事实上，这怨不得其他人，好比造房子，产品的工作类似打地基，地基不好，房子会塌，房子塌了怪谁，地基打得不好，当然是产品。

所以在工作中产品经理特别需要注意以下三个要点：

丨全程参与

前期的产品战略以及需求，产品经理都是参与其中的。特别是大的产品方向突出的功能点，你都必须全局进行了解。对公司的战略方向是否匹配，之后在产品的开发以及以后产品的迭代是否难度太大；这些问题一定要想清楚，不懂的就问，不断地进行评审深入下去。因为一旦进入开发阶段，突然变更需求，那么这段时间的精力以及时间就浪费了，这对于公司的损伤是巨大的。

丨勤写文档

一个人的记忆不可能会记住所有的东西，所以你必须记录下来，这样能更好地开展工作，在写需求文档的时候，我们需要要对每个用词定义紧抠，少用差不多、不确定等用词来模糊定义，千万不要以为需求文档开发不看，只看设计图，起码测试是需要根据你的需求文档写测试用例的，所以需要慎重对待。

丨做好评审记录

在评审的过程中，与项目经理进行评审后，记得做记录。哪些功能要做，哪些功能不错；什么时间开始，什么时间结束，这些都做好记录。

在互联网时代，使用敏捷开发模式可以让产品在市场上快速试错，根据数据的反馈进行及时的战略调整，让产品在市场立于不败之地，而在这个模式中，产品经理无疑是最重要的一个角色。最后用敏捷开发的 slogan 来总结它的几个特点吧：

「个体与交互」胜过「过程与工具」

「可以工作的软件」胜过「面面俱到的文挡」

「客户协作」胜过「合同谈判」

「响应变化」胜过「遵循计划」

敏捷开发过程中的一点感受

????????在利用敏捷开发过程中，用户（业务）也是作为相关人员参与到项目与之中，用户可以对每个周期完成的软件产品进行使用和评估，根据操作体检对功能、界面等各方面提出改进意见，并且可以激发用户对进步功能点的思考，有利于促进项目特性的快速积累，迅速到达完整的软件产品。

? ? 敏捷的三个要素是迭代开发、坦诚合作和自适应性。

? ? 迭代开发：把功能进行小粒度的分割，采用迭代和增量式的开发方法，时间段是按周而不是按月进行度量。频每交付使用，而不是等待项目开发完成一次性提交。这样也就能有比较明显的阶段性成果，可以按周交付新功能。这对于Web应用程序尤其适合。持续性的更新，可使用户有新鲜感，提高其访问频度和使用次数。也有助于开发人员根据用户的反馈数据，应对需求的变更，及时做出响应与改进。

　坦诚合作：以我来说，做为开发人员，合作应该主要是有两类：一类是与开发人员的合作，另一类是与业务人员。与业务人员的合作很容易理解，能做到一起紧密工作，可使得产品更能切合实际的需求。而不是作完需求分析后，就将他们一脚踢开，直至产品交付。以往所做项目都不算大，几个人而已，合作也是分模块分别开发再整合。所以与开发人员的合作体会还不是很深，没看出敏捷开发有什么明显的改善。

? ? 自适应性：现实不断发展与变化，需求也在不断改变，未来状态难以预测，也就很难提前用一个文档来规范所有的开发行为。自适应方法就是不断变化的现实情况，来及时作出改变。这也就需要信任开发人员的能力，给其更多的活动空间。相信对于一个合格的开发人员，这也会有助于调动其主观能动性，以更加积极的态度来参与开发。

1 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

3 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

4 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。?

7 工作的软件是首要的进度度量标准。

8 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

9 不断地关注优秀的技能和好的设计会增强敏捷能力。

10 简单——使未完成的工作最大化的艺术——是根本的。

11 最好的构架、需求和设计出自于自组织的团队。

12 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

? ? 如果仅仅从软件过程的角度去认识敏捷实施敏捷，效果不会太好。敏捷相对以前的软件工程最大的革新之处在于把人的作用提高到了过程至上，正如敏捷宣言的第一条“个体和交互胜过过程和工具”所说的。涉及到人的问题，就已经不再是过程所能覆盖的了，就到了企业管理的层面上了，包括企业的价值观和文化。这也是敏捷在国内实施的最大障碍：把客户当作合作伙伴而不是对手，从客户角度出发去想问题，充分的跟客户沟通，而不是出了问题推诿责任。目标是让软件实现客户的价值，而不是收钱就完事儿。把人的能动性调动起来，给动力而不是给压力。要实用而不是要规范。让开发人员理解并实施，体验到敏捷的好处，而不是盲目机械地实施规范。没有绝对的权威，每个人都有可取之处。