一次迭代式开发的研究：怎样进行迭代式开发

前面我们提到了迭代式开发的巨大优势，它可以降低我们软件开发的巨大风险，它可以使我们把握用户的真正需求，它可以使我们从错误与偏差中及时纠正过来，那么我们应该如何进行迭代式开发呢？要回答这个问题，我们首先要弄清迭代式开发与传统的瀑布式开发的差别在哪里。

1.需求分析的差别
与传统的软件开发一样，迭代式开发同样需要与客户进行一个充分的需求分析。但与传统的软件开发不一样，迭代式开发不要求初期的需求分析是一个完全的需求分析。它承认需求分析需要一个过程，它承认需求的变化（或者说需求是一个进化的过程）。所以，在迭代式开发中，起初的需求分析只要进行到当时的阶段能够理解到的程度就可以了，而不是瀑布式开发那样需要完成所有的需求分析并最终确认下来。至于其它还没有分析到的内容，我们会在每个迭代的需求阶段逐渐加深理解，逐渐细化，直至最终完成软件的开发。因此，迭代式开发的需求分析始终贯穿整个软件开发的过程。

2.软件开发的差别
迭代式开发的软件开发阶段，与传统软件开发的方式存在着巨大的差异，迭代式软件开发采用的是“持续集成（Continuous Build）”的软件开发方式。传统的开发方式，当需求被确认下来并开始软件开发时，首先进行的工作是分模块进行开发，就如同车间生产一样，不同的模块被分配到了不同的小组或个人进行分头开发。在此期间，谁都不能拿出可运行的软件交付物，直到开发中后期的集成阶段。而迭代式开发不同，它将整个开发过程分为了数个迭代，并且在每个迭代结束时要交付可执行的软件，正因为如此，迭代式开发采用持续集成的方式。

持续集成的基本思想就是每个人每天完成的开发工作都能立即集成为一个可运行的软件产品。为了实现持续集成，我们必须改变我们的开发顺序。传统的开发顺序，首先是开发并完善各个子模块。当各个子模块都完成开发以后，才最终组装并集成为一个可运行的软件。采用这种顺序开发不可能保证持续集成。迭代式开发，在初次确认业务需求以后，首先开发的是软件最主要最基本的功能，在开发这些功能时也往往只考虑主流程而忽略分支流程。采用这种方式，可以在最短时间内交付可以运行的软件。之后我们交给客户去体验、去确认、给我们提意见，我们再不断去调整和完善这些主要功能，或者开发其它次要功能，使软件开发以一种进化式的方式进行下去。

采用持续集成的方式，使软件开发中利益攸关的各方随时可以了解软件开发的进度，以可视化的方式看到软件开发的成果，及时纠正软件开发过程中的问题。更重要的是，所有利益攸关方中最重要的一方——客户，由于自身的局限描述不清自己的需求，通过可视化的方式一次一次看见可运行的软件，更直观地提出自己的意见，使自己的需求越来越清晰，并有效地告知开发者。而我们作为开发中，通过这种方式，使我们有更多的机会与客户有效沟通，从而对业务领域理解越来越深刻，也使我们的开发成果始终有客户确认，与客户的需求保持一致。即使有时出现偏差，也能及时得到纠正。最终，我们交付的软件必然是客户满意的。

由此看来，迭代式开发与传统开发，其开发的过程差异真的不小。

一次迭代式开发的研究：软件开发的风险
一次迭代式开发的研究：什么是迭代式开发
一次迭代式开发的研究：怎样进行迭代式开发
一次迭代式开发的研究：迭代开发从这里开始
一次迭代式开发的研究：准确的工作量评估
一次迭代式开发的研究：功能的优先级评估
一次迭代式开发的研究：一个迭代式项目计划
一次迭代式开发的研究：开始真正的工作
一次迭代式开发的研究：从容应对需求变更
一次迭代式开发的研究：需求变更的关键步骤
一次迭代式开发的研究：Where you are
（续）

楼主所说的迭代式开发是否就是 敏捷开发？

楼主你是项目经理吗？我所在的项目组一直以来都是走敏捷路线的，一般一个项目（100来万的）都要跌4次。不知道有没有必要这样搞，有的东西我们做好了，可是PM吧版本拿到客户那边去演示后，回来就要修改

改是说明做出来的东西不是客户想要的，
早改早托生。。。总比全部做完后改要好

迭代的周期非常重要，周期设得过短改动就比较频繁，过长又会增加修改的成本，因此需要仔细考虑。

另外，用户每提出一个需求的变更，我们一定要与他讨论这个变更的原因，是否合理，从业务角度去理解这些变更，最后能给出一个更合理的方案。很多的变更都是因为方案的不合理才导致的改来改去。

变更一定要落到纸面上，同时还要让客户理解变更的代价，适时地修改项目进度计划。如果客户理解到这一点也许就不变更了。

那最初的项目计划如何制定？
传统瀑布式的开发，根据需求做概要设计、详细设计、任务分工。
这些做完详细的项目计划也就出来了。

迭代式开发如来来做呢？
对于一个项目时间非常有限或有硬性要求的项目，如何管理项目进度？

我这是一系列文章，从制订项目计划前的分析，一直谈到项目执行过程的监控，当然也包括项目计划是怎样制订出来的，你可以链过去看看。

时间有限、人力资源有限，这应当是大多数软件项目的常态，我在后面的文章也提出了一个解决的办法，说白了就是分阶段开发。

迭代开发本身就是敏捷的方法之一。敏捷开发主张与客户沟通、增量开发、简化文档、承认变化。

本文提到了持续集成，持续集成是DDD（领域驱动设计）的重要概念（个人认为，领域驱动设计可以归结为三个词：持续学习、持续集成、持续重构），也是敏捷开发的重要方法。

大师Martin Fowler对持续集成是这样定义的:持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。

但是，要做到持续集成，没有持续集成的管理软件是不行的。持续集成工具提供的功能就是能够定期地、自动化地完成系统的集成、编译、发布、测试等工作。目前比较主流的开源持续集成工具包括：
CruiseControl http://cruisecontrol.sourceforge.net/
Hudson http://java.net/projects/hudson/
LuntBuild http://luntbuild.javaforge.com/
另外还有一些商用的持续集成工具：TeamCity,AntHill Pro,Bamboo,QuickBuild

要使用持续集成工具，首先需要一个代码配置库，如svn,vss,cvs等，然后配置一个持续集成服务器和系统发布服务器。持续集成服务器说白了就是安装了持续集成系统软件的电脑，它定期去配置库获取更新的代码，经过在本地的集成、编译、测试，最后发布到发布服务器上。发布服务器就是一个应用服务器，将集成后的代码发布到tomcat或weblogic中运行。