迭代式开发

软件开发是复杂的脑力活动，这意味着管理软件开发的进度变的不那么容易。事实上，几乎每个软件公司都会面临进度管理的问题。延期的意思就是实际完成时间和计划时间不符，我们假设所有的人员都在努力工作，那么延期的原因是什么呢？显然是计划有问题。

然而也不是所有的软件开发都会延期，“Hello World”这样的程序就肯定不会延期。这是为什么？因为它需要的工时足够少。当活动所需工时很少的时候，我们很容易估计它的完成时间，也就是说，很容易制订正确的计划。

在复杂的项目中也是这样，我们可以精确估计某个简单功能的完成时间，然而当所有的事情聚集在一起的时候，时间就难以估计了。因此，我们需要对工作进行拆分。

传统的开发过程被称为“瀑布式”开发。实际上这是一个自发形成的开发过程，因为我们干任何事情都是这样：先做a，再做b，最后做c。在“瀑布式”开发中，我们的工作沿着需求分析-模块设计-编码-测试这样的瀑布不断前进。然而当这个瀑布大到一定程度的时候，我们就很难看清前方，因此计划也就变得不明朗了。
为了改变这样的状况，迭代开发就产生了。迭代就是把一个长期的活动拆分成易于管理的较短期的活动。

当提到迭代的时候，往往会有2种反映，1种是：这是书本上的东西，只有大公司大项目才能实施。另1种是：我们已经在迭代了啊，从产品1.0版到1.1版，这不就是迭代吗？
这2种反映，都说明对迭代不够了解。

迭代的英文原词是iteration，也就是循环的意思，但同时也有递进的含义。因此迭代就是一个不断循环并且前进的过程。现代软件开发过程，几乎都是迭代的开发过程，比如rup，xp等，我们可以认为，迭代是敏捷的基础，从这个意义上说，rup、xp都是敏捷的过程。

rup定义的软件开发过程是这样的：
首先，软件的整个周期被划分为：初始、细化、构造、移交这4大规程。我们在每个规程中，侧重不同的活动。
初始：侧重业务分析，需求分析，项目前景规划，项目目标和范围设定。
细化：侧重架构设计，框架的编码，性能评估。
构造：侧重详细设计，子系统的编码，单元测试，子系统测试。
移交：侧重系统测试，综合场景测试。
在每个规程中，都存在以下的活动：需求、设计、编码、测试、变更管理、项目管理。


在软件开发中，采用下面的6条实践：
1、迭代的开发软件
2、需求管理
3、使用基于构件的体系结构
4、可视化软件建模
5、验证软件质量
6、控制软件变更
实际上后面5条，大多数软件公司都在做到，但是对于迭代，却实施得不那么好。

为什么说迭代是敏捷的基础？因为每一次迭代都会有需求分析和测试，这意味着，在每一个迭代，我们都可以重新审视开发方向和验证软件的质量。这就增加了我们规避风险的机会。并且如果迭代周期足够短，我们就可以精确制订该迭代内的项目计划。
这听起来是一个诱人的蛋糕，但问题是：迭代周期应该多长？答案是：越短越好。因为只有迭代周期足够短，在该迭代内的活动才更有利于管理和监控，同时意味着我们有更多的机会去对应变化。在极端的敏捷方法中，提倡每日构建，每日构建的好处是每天都可以进行测试，这几乎是每天一次迭代。
根据以往的实践经验，迭代周期最好在4周以内，因为4周以内的进度可以比较精确的得到管理，并且随着软件开发的深入，迭代周期可以越来越长，这很容易理解，因为软件越来越稳定，风险越来越少。
在细化阶段，迭代周期在1至2周比较适合。构造阶段，可以慢慢延长到3到4周。

我们应该在初始阶段定义好每次迭代都干些什么，但是不用太细致，而且也不可能做到很细致。而每次迭代的具体需求，都在该次迭代开始的时候进行分析。

这样以来，我们就把一个长期的，复杂的软件开发活动，拆分为若干个短期的，简单的活动了。