引子：我们为什么需要迭代开发？
我们都知道，人对于世界的认识是一项主观活动，它受到各种因素的影响，使得我们不能够一下子对所要认知的事物有一个清晰的了解。具体到软件开发中来，我们会发现，你很难在开发之前弄清楚客户所有的需求。一方面，客户对自己想要什么可能并没有一个明确的想法，这就好比在买衣服的时候，我们在专卖店里看到一个衣服，会觉得自己穿起来很帅，但是你仍然需要把它真实的穿在身上才能看到实际效果，而在你看到这件衣服之前，你能够仅仅凭着想象在脑海里刻画出这件衣服的样子么？
其次，软件工业中我们讲究的是投入和产出比，软件业的成本主要是 人力资源的成本。这也是软件项目对时间特别敏感的原因。时间比计划延长一个月，对于一个数十人的 团队来说就意味着几十万的成本增加。但是又有谁能够保证自己所做的软件是完美无缺的呢？于是很多时候我们必须对已经开发的部分进行修正，而修正就需要时间。 传统的开发方式下，很多软件项目都是在匆忙交付后发现用户不满意，于是继续修正，再次引发用户的不满意，再次修正，在这样反复地拖延中，客户和软件开发商都筋疲力尽。
我们需要迭代开发，是因为我们深知对事物的认知就是一个探索的过程，软件开发也是一样。在温博格《探索需求---设计前的质量》一书中提到：
美国第34任总统艾森豪威尔上将曾经说过，"计划本身什么都不是，而编制计划的过程就是一切"。我们认同这样的说法，并把它推广到需求过程：产品什么都不是，而开发的过程就是一切。
或用另一种方式表达：发现什么都不是，而发现过程（探索过程）就是一切。
软件项目本身的意义就在于和用户一起探索他们真正需要的东西并且帮助他们实现。而这种探索，如同在第一段中我们阐述的那样，需要不断的反复，如果我们没有做好迭代和反复的准备，而是希望一次性的把所有工作都做完并且还做得非常好，结果可能恰恰相反。
我们需要迭代开发，是因为我们追求软件质量的最大化。没有人可以制造出完美无缺的东西，但是我们可以通过不断的检查和反馈，使得那些不适合的东西在早期被暴露出来，迭代给予了我们这样一种检查合反馈的机制，让我们不必在事情结束的时候才惊奇的发现我们所一直努力在做的东西其实是一堆废物。
实践：正确实施迭代开发
事实上在业界，迭代开发的观念早已经深入人心，然而有多少团队在正确地实施着迭代方法呢？有多少团队通过迭代得到了他们想要的东西呢？很多人简单的把迭代理解为开发的分阶段进行。我们常常看到有 项目经理们这样说：我们打算通过4次迭代完成软件的开发，第一次迭代，完成需求分析和软件设计，第二次迭代，完成多少多少模块的开发，第三次，完成其他多少模块的开发，第四次，配置，部署，上线，测试，修正软件bug。虽然我们言必称“迭代”，但是这样的迭代和过去传统的瀑布型开发有多少区别？我们又能够从这样的伪迭代中得到什么好处呢？
在本文以下部分将对迭代开发实践中几个关键方面进行阐述，这几个方面我们概括为以下关键词：变化，周期，目标，反馈，合作。
变化
迭代思想带给我们最重要的一个启示，就是要适应变化，要积极、主动地拥抱变化而不是拒绝变化。
在过去的开发中，我们常常会拒绝变化，以需求分析工作为例，有些项目组在需求分析完成后会要求用户签字，等到交付时，如果客户有什么意见，他们就会拿出那份客户已经签字画押的文件来理直气壮地说：这是你们签字过的东西，我们做的难道不是和这里所说的一样么？
是的，开发出来的可能是和需求定义文件的内容一样的，但问题是：这份需求定义文件上描述的内容是不是真正能够帮客户实现自己的价值呢？难道我们进行软件开发的目的就是让客户在一份他们根本不清楚有什么意义的文件上签字，然后用这个来反驳用户的真正需求么？我们在软件立项之前总是会告诉用户，这个即将开发的软件会帮助他们如何如何。我们有什么理由为我们做不到这一点而理直气壮地责备客户呢？客户亲笔签名的需求文档难道不是我们整理出来并且讲解给他们听的么？
如果一个软件项目的目标是帮助客户实现某一方面的增值，但是这种增值的目的并没有达到，我们就可以认为这个软件项目是失败的。即使软件厂商通过这个项目达到了盈利的目的，满腹牢骚的客户也会把自己的意见传播出去。而如果软件厂商认为这种事情是天经地义的话，那么它在以后的软件项目中也很难帮助自己的客户实现他们想要的价值。
我们必须让自己具有适应变化的能力。因为这种变化是客户需要的，因为这种变化能够让软件更能体现出自己的价值。我并不是说应该无条件地接受这种变化，但是我们可以在事前就这些问题和客户进行充分的讨论和 沟通，让他们明白，世界总是变化的，需求本身可能会变化，而这种变化需要人力和物力的支持。让客户也能够适应自身的变化，这是非常重要的。
文章来源于领测软件测试网 https://www.ltesting.net/
