项目生命周期指项目从启动到收尾所经历的一系列阶段，生命周期是项目经理和团队组织项目过程的方式。项目阶段通常按顺序排列，阶段的名称和数量取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域。

不同的生命周期有不同的风险处理方式。目前，主要有四种不同类型的生命周期：顺序式、迭代式、增量式、敏捷开发。表1和图1给出了几种生命周期模型的比较。

表1 几种生命周期模型的比较

http://s7/mw690/001WNOgkgy6VWsNU5QGa6&690
图1 几种生命周期模型的比较

一、顺序式生命周期

在顺序式生命周期（也称预测型生命周期）中，团队首先获取所有的需求，基于这些需求，项目可以进入分析和设计阶段，以决定系统的整体布局。项目团队就整体布局达成一致意见后进入开发阶段。开发完成后，团队将会整合所有的功能，再开始最终测试。在现实状况中，当前阶段尚未完成时，下一个阶段就可以开始了。不过，“一次只做一个阶段该做的工作”，这是顺序式生命周期中最常见的约定。如图2是顺序性生命周期的实例（瀑布模型），项目经过一系列顺序或交叠的阶段，其中每个阶段通常关注一组项目活动和项目管理过程。每个阶段的工作通常与前续阶段和后续阶段有本质的差别，项目团队的组成和所需技能也因阶段而异。

http://s2/mw690/001WNOgkgy6VWsTLArfa1&690
图2 顺序式生命周期

顺序式生命周期会花费较长时间。顺序式生命周期可以预测工作持续时间：实现功能需要多久、找到并修复缺陷需要多久、整合系统功能需要多久、管理需求变更要多久，等等，当然这是困难的。除非项目经理和他的团队可以完全预测项目未来，否则不可能估计到未来要知道的每件事情。在顺序式生命周期中，项目经理要允许占用计划外的时间，比如项目结束时的系统测试，以弥补项目过程中的未知风险和问题可能造成的损失。

以下情况优先选择预测型生命周期：

l   充分了解拟交付的产品；

l   有厚实的行业实践基础；

l   整批一次性交付产品有利于干系人。

即使采用了预测型生命周期，仍可使用滚动式规划的概念。先编制一份高层级的概要计划，再随新工作的临近、资源得到分配，针对某个合理的时间段编制更详细的计划。

二、迭代和增量型生命周期

迭代式生命周期先创建系统的部分原型，以此解决一些预测问题。在迭代式生命周期中，项目团队会在每次迭代中开发产品的一个部分。至于是否必须在迭代结束时完成产品某部分的开发，对此常不作要求。迭代式生命周期不要求同时进行测试和集成。（当你在构建架构原型时，无法对未来有很好的预测，除非已经开始构建和集成功能。）

增量式生命周期与顺序式生命周期在需求收集和分析阶段有类似之处。不同的是，增量式生命周期用时间盒限制需求的收集和分析，然后按照功能分成不同模块并交付不同团队来实现。各团队每开发一个功能，完成相应的测试和集成后，再开始开发下一个功能。使用增量式生命周期的项目，在进行增量式开发之前，也会遇到预测不准的问题。进行增量式开发后，项目团队会得到使用这种生命周期构建功能的反馈，从而决定项目的走向。

在迭代和增量型生命周期中，随着项目团队对产品的理解程度逐渐提高，项目阶段(也称为迭代）有目的地重复一个或多个项目活动。采用迭代和增量方式的项目也可以技阶段推进，迭代本身可以顺序或交叠进行。

在大多数迭代和增量式生命周期中，都会制定一个高层级的框架计划以指导整体实施，但一次只针对一个迭代期制定详细的范围描述。通常，随着当前迭代期的范围和可交付成果的进展，开始规划下一个迭代期的工作。完成一组既定的可交付成果所需的工期和投入可能发生变化，项目团队在迭代期之间或之内也可能发生变化。对那些不属于当前迭代期工作范围的可交付成果，通常只需要简单概述，暂且留给未来的某个迭代期实施。一个迭代期工作开始，就需要仔细管理该迭代期的工作范围变更。

以下情况优先选择迭代和增量型生命周期：

l   组织需要管理不断变化的目标和范围；

l   组织需要降低项目的复杂性；

l   产品的部分交付有利于一个或多个干系人，且不会影晌最终或整批可交付成果的交付。

大型复杂项目通常采用迭代方式来实施，这使项目团队可以在迭代过程中综合考虑反馈意见和经验教训，从而降低项目风险。

三、敏捷生命周期

敏捷生命周期迭代更短、增量更少。用敏捷生命周期组织启动一个项目，只需要一点点前期的规划工作——只要足以启动项目，而且知道产品负责人对当前发布版本的期望就可以了。项目负责人甚至可以将他们需要的功能划到指定的迭代中，但是项目团队不会花很长时间做版本规划。实际上，他们会去规划一个有时间限制的迭代（一至四周）中要完成的工作。

项目团队在这些时间盒中开始工作，首先实现最有价值的功能。他们会收集很多数据，比如他们的工作进展速度、问题解决情况、需求理解状况，等等。随着项目的推进，团队从项目负责人那里获得关于项目功能的反馈。然后基于团队的工作效率和环境变化，重新规划后续迭代。由于团队会主动寻求对于工作和流程的反馈，这种生命周期能够将收集到的反馈与项目进展完美地整合到一起。这些反馈包括项目的真实状态、开发效率、寻找和修复缺陷的效率以及团队的假定，等等。

除非项目团队主动按照功能去规划开发、测试和集成的工作（正如在并行工程或敏捷中所做的），否则他们一般会遵循“设计-编码-测试-调试”这样的循环（图3）。开发人员首先设计产品，接下来进行编码，然后测试，再进行调试。这个过程可能花费数周甚至数月。

http://s14/mw690/001WNOgkgy6VWsNTTM95d&690
图3 设计-编码-测试-调试循环

以下情况优先选择适应型方法：

l   需要应对快速变化的环境；

l   需求和范围难以事先确定；

l   能够以有利于干系人的方式定义较小的增量改进。

四、切勿僵化地看待和执行生命周期模型

生命周期是组织项目的理想化方式。选择了某种生命周期，并不意味着就要僵化地执行下去。项目经理可以根据项目的风险情况，整合其他生命周期的管理方式。

如果项目经理遭遇过必须提早确定架构所带来的风险，而且知道目前收集到的需求只是一部分（还不能使用敏捷生命周期），那么图4可能会对此有所帮助。使用这种结合方式，项目团队可以先在迭代中做一些原型化的工作。了解到足够情况后，团队可以按照进度进行增量式开发、实现、测试和集成。

图4所示是一种组合式的生命周期，用到了迭代式生命周期的一部分（原型化）、增量式生命周期的一部分（3个完整的功能实现和后续的开发），其中有些想法来自敏捷社区（对需求的初步了解，并随着项目进展将需求迭代化），项目结束时的最终测试用来管理风险。

http://s13/mw690/001WNOgkgy6VWuwKffucc&690

图4 生命周期的复合使用

在项目开始时，不必获得所有需求。按照功能进行实现，用时间盒限制迭代，与客户一起工作，这些措施可以确保开发的产品符合客户的要求。无论选择哪种生命周期，在项目开始时都要做规划，千万不要觉得可以在没有客户的情况下启动项目。