第3章 生存期模型
为了提交一个满意的项目，需要选择项目实施策略，选择生存期模型的过程就是选择策略的过程。下面进入路线图的“生存期模型”，如图3-1所示。
3.1 生存期概述
3.1.1 生存期的定义
软件项目生存期模型的基本特征如下。
1）描述开发的主要阶段。
2）定义每一个阶段要完成的主要过程和活动。
3）规范每一个阶段的输入和输出。
在生存期模型中定义软件过程非常重要，人和过程是保证项目成功的两个关键因素。由合适的人按好的过程进行项目开发，才能最大限度地保证项目的成功。通过过程可以实现一种规范化、流水线化、工业化的软件开发。软件的生产过程不存在绝对正确的过程形式，不同的软件开发项目应当采用不同的或者有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目开发完成后才能明了的。因此，项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断地调整。
软件生存期模型的选择对项目成功的影响非常重要。恰当的生存期模型可以使软件项目流程化，并帮助项目人员一步一步地接近目标。如果选择了适宜的生存期模型，就可以提高开发速度，提升质量，加强项目跟踪和控制，减少成本，降低风险，改善用户关系。
3.1.2 生存期的类型
软件开发模型总体上经历了从传统到敏捷的变迁，从最初的作坊式的单打独斗，到诸如CMM等过程改进式的过程控制，再到敏捷模型，如图3-2所示。敏捷模型也发展出更多模型，如时下流行的DevOps。
项目有多种形式，也有多种实施方式。项目团队根据项目特征选择最可能使项目成功的生存期模型和方法。总体上，项目生存期模型可以是预测型或适应型。适应型模型可以是迭代型、增量型、敏捷型等，如图3-3所示从两个维度展示了这4类模型的关系。从项目变化角度看，预测型低，迭代型高；从提交的频繁度看，预测型低，增量型高。敏捷模型既有迭代型，也有增量型，便于完善工作，可以频繁交付。充分了解或有确定需求的项目要素遵循预测型开发模型，而仍在发展中的要素遵循适应型开发模型。
其中：
- 预测型生存期模型是一种更为传统的方法，需要提前进行大量的计划工作，然后一次性执行。执行是一个连续的过程。
- 迭代型生存期模型允许对未完成的工作进行反馈，从而改进和修改该工作；允许对部分完成或未完成的工作进行反馈，从而对该工作进行改进和修改。
- 增量型生存期模型向客户提供已完成的、可能立即使用的可交付成果。
- 敏捷型生存期模型同时利用迭代属性和增量特征，便于完善工作，频繁交付。团队使用敏捷方法时，他们会对产品进行迭代，创建可交付成果。团队将获得早期的反馈，并能提供客户可见性、信心和对产品的控制。由于团队可以提前发布产品，可以率先交付价值最高的工作，所以项目可以更早产生投资回报。
不同生存期模型的特征如表3-1所示。表3-1从项目需求、开发活动、产品交付及目标等角度展示了四大模型的项目特征。从项目需求上看：预测型的需求最稳定；其他3个类型需求有变化。从开发活动上看：预测型是每个开发活动只执行一次，瀑布模型就是这样；迭代型是不断重复一些活动，直到正确为止；增量型是每个增量活动只执行一次；敏捷型也是不断重复一些活动，直到正确为止。从产品交付上看：预测型、迭代型只提交一次；增量型、敏捷型多次提交小版本。从目标上看：预测型的目标是管理成本；迭代型的目标是获得正确的解决方案；增量型的目标是加快速度；敏捷型通过不断提交和反馈获得用户肯定。这些特征可以作为选择模型的参考。
需要注意的是，所有的项目都具有这些特征，没有一个项目能够完全不考虑需求、交付、变更和目标这些因素。项目的固有特征决定了其适合采用哪种生存期模型。
另一种理解不同项目生存期的方法是使用一个连续区间，从图3-3一端的预测型模型到另一端的敏捷型模型，连续区间中间还有更多的迭代型周期或增量型周期。没有哪个生存期模型能够完美地适用于所有的项目。相反，每个项目都能在连续区间中找到一个点，根据其背景特征实现最佳平衡。实践中还有混合型生存期模型，这种模型是预测型和适应型的组合。
3.2 预测型生存期模型
预测型生存期模型充分利用已知和已经证明的事物，不确定性和复杂性减少，允许项目团队将工作分解为一系列可预测的小组，是一种传统的模型，如瀑布模型。预测型生存期模型预计会从高确定性的明确需求、稳定的团队和低风险中获益。因此，项目活动通常以顺序方式执行，如图3-4所示。
为了实现这种方法，团队需要详细的计划，了解要交付什么及怎样交付。当其他潜在的变更受到限制时，这些项目就会成功。团队领导的目标是尽可能减少预测型项目的变更。
团队在项目初始创建详细的需求和计划时，可以阐明各种制约因素,然后利用这些制约因素管理风险和成本。进而，在实施详细计划时，团队会监督并控制可能影响范围、进度计划或预算的变更。
如果遇到变更或需求分歧，或者技术解决方案变得不再简单明了，则预测型项目将产生意想不到的成本。瀑布模型和V模型是最典型的预测型生存期模型。
3.2.1 瀑布模型
（waterfall model）是一个经典的模型，也称为传统模型（conventional model），它是一个理想化的生存期模型，如图3-5所示。它要求项目所有的活动都严格按照顺序自上而下执行，一个阶段的输出是下一阶段的输入，如同瀑布流水，逐级下落。瀑布模型没有反馈，一个阶段完成后，一般不返回——尽管实际的项目中要经常返回上一阶段。瀑布模型是一个比较“老”的模型，甚至有些过时，但在一些小的项目中还是经常用到的。
瀑布模型的优点：
1）简单、易用、直观。
2）开发进程比较严格，一个进程接着一个进程进行。
3）模型执行过程中需要严密控制。
4）允许基线和配置早期接受控制。
5）为项目提供了按阶段划分的检查点，当前一个阶段完成后，只需要关注后续阶段。
瀑布模型的缺点：
1）在软件开发的初期阶段就要求做出正确、全面、完整的需求分析，这对许多应用软件来说是极其困难的。
2）由于开发模型是线性的，模型中没有反馈过程，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）一个新的项目不适合瀑布模型，除非在项目的后期。
4）用户直到项目结束才能看到产品的质量，用户不是渐渐地熟悉系统。
5）不允许变更或者限制变更。
6）早期的错误可能要等到开发后期才能发现，进而带来严重后果。
瀑布模型的适用范围：
1）在项目开始前，项目的需求已经被很好地理解，也很明确，而且项目经理很熟悉为实现这一模型所需要的过程。
2）解决方案在项目开始前也很明确。
3）短期项目可以采用瀑布模型。
瀑布模型的使用说明：
1）开发前，要进行概念开发和系统配置开发。概念开发主要是确定系统级的需求，提交一份任务陈述；系统配置开发需要确定软件和硬件的情况。
2）开发中，需进行需求过程、设计过程、实施过程。
3）开发后，需进行安装过程、支持过程、维护过程等。
瀑布模型因为缺乏灵活性、适应性不佳而渐渐受到质疑。Royce在1970年发表的《管理大型软件系统的开发》中提到：瀑布模型建议在关键的原型阶段之后应用，在原型阶段要充分地理解所要应用的关键技术及客户的实际需求。
3.2.2 V模型
V模型是由Paul Rook在1980年提出的，是瀑布模型的一种变种，同样需要一步一步进行，前一阶段任务完成之后才可以进行下一阶段的任务，如图3-6所示。
这个模型强调测试的重要性，将开发活动与测试活动紧密地联系在一起。每一步都将比前一阶段进行更加完善的测试。一般，大家对测试存在一种误解，认为测试是开发周期的最后一个阶段。其实，早期的测试工作对提高产品的质量、缩短开发周期起着重要作用。V模型正好说明了测试的重要性，它是与开发并行的，例如，单元测试对应详细设计，集成测试对应概要设计，系统测试对应需求分析。V模型体现了全过程的质量意识。
V模型的优点：
1）简单易用，只要按照规定的步骤一步一步执行即可。
2）强调测试过程与开发过程的对应性和并行性。
3）开发进程比较严格，执行过程需要严密控制。
4）允许基线和配置早期接受控制。
5）为项目提供了按阶段划分的检查点，当前一个阶段完成后，只需要关注后续阶段。
V模型的缺点：
1）软件开发的初期阶段就要求做出正确、全面、完整的需求分析。
2）软件项目的实现方案需要很明确。
3）不能存在变更。
V模型的适用范围：
1）项目的需求在项目开始前很明确。
2）解决方案在项目开始前很明确。
3）项目对系统的安全性能要求很严格，如航天飞机控制系统、公司的财务系统等。
V模型的使用说明：使用V模型，要求开发的全过程是严格按照顺序进行的，一个阶段的输出是下一个阶段的输入。同时，注意图3-6中虚线对应过程的并行考虑，例如，在需求分析阶段，应该有系统测试的准备；在概要设计阶段，应该有集成测试的准备；在详细设计阶段，应有单元测试的准备等。
3.3 迭代型生存期模型
迭代型生存期模型（见图3-7）通过连续的原型或概念验证来改进产品或成果，每一个新的原型都能带来相关方新的反馈和团队见解。然后，团队在下一周期重复一个或多个项目活动，在其中纳入新的信息。这种迭代有利于识别和减少项目的不确定性。
当项目复杂性高、变更频繁或当项目范围受到相关方对所需最终产品的不同观点的支配时，采用迭代型生存期模型会有优势。迭代型生存期模型可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化。
实践中常常将迭代型生存期模型直接等同于原型模型。
原型模型是在需求阶段快速构建一部分系统的生存期模型，实现客户或未来用户与系统的交互，而且用户或客户可以对原型进行评价，这些反馈意见可以作为进一步修改系统的依据。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；开发人员对开发产品的意见有时与客户的不一致，因为开发人员更关注设计和编码实施，而客户更关注于需求。因此，开发人员快速构造一个原型有助于很快与客户就需求达成一致。
原型模型通常从最核心的方面开始，向用户展示完成的部分，然后根据用户的反馈信息继续开发原型，并重复这一过程，直到开发人员和用户都认为原型已经足够好，然后开发人员在此基础上开发客户满意的软件产品，交付作为最终产品的原型，如图3-8所示。
原型模型以逐步增加的方式进行开发,以便随时根据客户或最终用户的反馈来修正系统。在需求变化很快的时候，或者用户很难提出明确需求的时候，或者开发人员对最佳的架构或算法没有把握的时候，渐进原型特别有用。但是，原型模型是以牺牲项目的可控制性来换取较多的客户反馈及较好的过程可视性的。由于原型的功能和特性会随着用户的反馈而经常发生变化，因此较难确定产品的最终形态。
原型模型的优点：
1）可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
2）用户根据快速构建的原型系统的优缺点，给开发人员提出反馈意见。
3）根据反馈意见修改软件需求规格，以便系统可以更正确地反映用户的需求。
4）可以减少项目的各种假设及风险等。
原型模型的缺点：
1）需求定义之前，需要快速构建一个原型系统。
2）所选用的开发技术和工具不一定符合主流的发展。
3）快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
4）使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。
原型模型的适用范围：
1）项目的需求在项目开始前不明确。
2）需要减少项目的不确定性的时候。
原型模型的使用说明：
1）用户和开发人员根据初始需求共同开发一个项目规划。
2）用户和开发人员利用快速分析技术共同定义需求规格。
3）设计者构建一个原型系统。
4）设计者演示这个原型系统，用户来评估性能并标识问题。
5）用户和设计者一起来解决标识的问题，循环这个过程，直到用户满意为止。
6）详细设计可以根据这个原型进行。
7）原型可以用代码或者工具来实施。
3.4 增量型生存期模型
增量型生存期模型的策略是不同时开发项目需求，而是将需求分段，使其成为一系列增量产品，每一增量可以分别实施，每个增量都包括分析、设计、实施、测试、提交等过程。每个增量是一个交付成果。第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，不断重复这个过程，直到产生最终的完善产品。增量型生存期模型如图3-9所示。
增量型生存期模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品。所以，增量型生存期模型向客户提供完成的可交付成果，让客户能够立即使用。如果有些项目是为了加快交付速度，或者无法等待所有的事情全部完成，可以采用频繁交付少量可交付成果的方式，即增量型生存期模型。在这种情况下，客户先接受整个解决方案的一个部分。
与一次交付一个最终产品相比，增量型生存期模型常优化为项目发起人或客户交付价值的工作。在开始工作之前，团队就计划了最初的可交付成果，并会尽快开始第一次交付的工作。某些敏捷项目在项目启动后几天内就开始交付价值，有的项目可能需要更长的时间，从一周到几周时间不等。
增量型生存期模型的优点：
1）软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
2）可以避免一次性投资太多带来的风险，首先实现主要的功能或者风险大的功能，然后逐步完善，保证投入的有效性。
3）可以更快地开发出可以操作的系统。
4）可以减少开发过程中用户需求的变更。
增量型生存期模型的缺点：
1）由于各个构件是逐渐并入已有的软件体系结构中的，因此加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2）在开发过程中，需求的变化是不可避免的。增量型生存期模型的灵活性使其适应这种变化的能力大大优于瀑布模型和原型模型，但一些增量可能需要重新开发，从而使软件过程的控制失去整体性（如果早期开发的需求不稳定或者不完整）。
增量型生存期模型的适用范围：
1）进行已有产品升级或新版本开发，增量型生存期模型是非常适合的。
2）对于完成期限要求严格的产品，可以使用增量型生存期模型。
3）对于所开发的领域比较熟悉而且已有原型系统，增量型生存期模型是非常适合的。
4）对市场和用户把握不是很准，需要逐步了解的项目，可采用增量型生存期模型。
增量型生存期模型的使用说明：使用增量型生存期模型时，首先构建整个系统的核心部分，或者具有高风险的部分功能——这部分功能对项目的成功起到重要作用。通过测试这些功能来决定它们是否是项目所需要的，这样可以排除后顾之忧，然后逐步增加功能和性能，循序渐进。增加功能的时候应该高效而且符合用户的需要。
渐进式阶段模型是一个特殊的增量型生存期模型，每个增量就是一个比较完整的系统，如图3-10所示，即提交的是正式的版本，包括与产品相关的其他资源。例如某操作系统，为了最终完成的1.0版本，先后发布了0.1、0.2、0.3等版本，每个版本都可以是正式的产品，直到最后提交了1.0版本。
对于软件项目来讲，可以将大的项目划分成若干个小项目来做，将周期长的项目划分成若干个明确的阶段。“化繁为简，各个击破”是解决复杂问题的一个方法。例如，一个5年完成的项目可以分成5个阶段，每年提交一个版本，无形中感觉工作时间缩短了，工作量变小了，尽管实际的工作量并没有减少。开发过程中反复和阶段提交是比较合理的过程，渐进式阶段模型恰恰体现了这些特征。
渐进式阶段模型的优点：
1）阶段式提交一个可运行的产品，而且每个阶段提交的产品是独立的系统。
2）关键的功能更早出现，可以提高开发人员和客户的信心。
3）通过阶段式产品提交，可以早期预警问题，避免后期发现问题的高成本。
4）通过阶段式提交可以运行的产品来说明项目的实际进展，减少项目报告的负担。
5）阶段性完成可以减少估计失误，因为通过阶段完成的评审，可以重新估算下一阶段的计划。
6）阶段性完成均衡了弹性与效率，提高开发人员的效率和士气。
渐进式阶段模型的缺点：
1）需要精心规划各个阶段的目标。
2）每个阶段提交的是正式版本，所以工作量会增加。
作者曾负责过一个软件开发项目，该项目前期投入了5人做需求，时间达3个多月，进入开发阶段后，投入了15人，时间达10个月之久，陆续进行了3次封闭开发，在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整，项目组成员的压力极大，大家疲惫不堪，产品上线时间拖期达4个月。项目完工后总结下来的一个很致命的教训就是：应该将该项目拆成3个小的项目来做，进行阶段性版本化发布。这样不仅能缓解市场上的压力，而且可减少项目组成员的挫折感，提高大家的士气。
3.5 敏捷型生存期模型
敏捷生存期模型是符合《敏捷宣言》原则的模型，客户满意度将随着有价值产品的早期交付和持续交付不断提升。此外，功能性的、提供价值的增量可交付成果是衡量进展的主要尺度。为了适应更频繁的变更，更频繁地交付项目价值，敏捷生存期模型结合了迭代和增量方法。
在敏捷环境中，团队预料需求会发生变更。迭代和增量方法能够提供反馈，以便改善项目下一部分的计划。不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。图3-11显示了实现增量交付的两种可能的方法（基于迭代和基于流程），这样便于项目与客户需求保持一致，并根据需要进行调整。
基于迭代的敏捷方法，团队以迭代（相等的持续时间段）形式交付完整的功能。团队集中于最重要的功能，合作完成其工作。然后，团队再集中于下一项最重要的功能，并合作完成其工作。团队可决定一次进行若干功能的开发工作，但团队不会同时完成所有的迭代工作。
基于流程的敏捷方法，团队将根据自身能力，从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流，并管理进行中的工作（Work In Progress,WIP）。完成不同功能所花费的时间可能有所不同。团队一般会让WIP的规模尽量小，以便尽早发现问题，并在需要变更时减少返工。采用敏捷生存期模型，无须利用迭代定义计划和审核点，团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。
敏捷是许多方法的总称，其中包括很多敏捷开发管理实践，如Scrum、XP（eXtreme Programming）、OpenUP、看板方法、Scrumban、精益（lean）模型、持续交付、DevOps等。
3.5.1 Scrum
Scrum有明确的更高目标，具有高度自主权，它的核心是迭代和增量，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝着目标有明确的推进。
Scrum是一个框架，由Scrum团队及其相关的角色、活动、工件和规则组成，如图312所示。在这个框架中可以应用各种流程和技术。Scrum基于经验主义，经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法优化可预测性和管理风险。一个迭代就是一个Sprint（冲刺），Sprint的周期被限制在一个月左右。Sprint是Scrum的核心，其产出是可用的、潜在可发布的产品增量。Sprint的长度在整个开发过程中保持一致。新的Sprint在上一个Sprint完成之后立即开始。
如果Sprint周期过长，对“要构建什么东西”的定义就有可能会改变，复杂度和风险也有可能会增加。Sprint通过确保至少每月一次对达成目标的进度进行检视和调整来实现可预见性。Sprint也把风险限制在一个月的成本上。
Sprint由Sprint计划会议（plan meeting）、每日站立会议（daily meeting）、开发工作、Sprint评审会议（review meeting）和Sprint回顾会议（retrospective meeting）构成。Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（discipline），这些有助于创造自我组织的团队。
1.团队角色
Scrum团队由产品负责人（product owner）、Scrum主管（master）和开发团队组成。Scrum团队是跨职能的自组织团队。Scrum团队迭代增量式地交付产品，最大化获得反馈的机会。增量式地交付“完成”的产品保证了可工作产品的潜在可用版本总是存在。
产品负责人：代表客户的意愿，从业务角度来保证Scrum团队在做正确的事情。同时产品负责人代表项目的全体利益干系人，负责编写用户需求（用户故事），排出优先级，并放入产品订单（product backlog），从而使项目价值最大化。产品负责人利用产品订单，督促团队优先开发最具价值的功能，并在其基础上继续开发，将最具价值的开发需求安排在下一个Sprint迭代中完成。产品负责人对项目产出的软件系统负责，规划项目初始总体要求、ROI目标和发布计划，并为项目赢得驱动及后续资金。
Scrum主管：负责Scrum过程正确实施和利益最大化的人，确保它既符合企业文化，又能交付预期利益。Scrum主管的职责是向所有项目参与者讲授Scrum方法和正确的执行规则，确保所有项目相关人员遵守Scrum规则，这些规则形成了Scrum过程。
开发团队：负责找出可在一个迭代中将Sprint订单（Sprint backlog）转化为功能增量的方法。开发团队对每一次迭代和整个项目共同负责，在每个Sprint中通过实行自管理、自组织和跨职能的开发协作，实现Sprint目标和最终交付产品，一般由5～9名具有跨职能技能的人（设计者、开发者等）组成。
2.工件
Scrum模型的工件以不同的方式表现工作的任务和价值。Scrum中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同的理解。
（1）增量
增量是一个Sprint完成的所有产品待办列表项，以及之前所有Sprint所产生的增量价值的总和，它是在每个Sprint周期内完成的、可交付的产品功能增量。在Sprint的结尾，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。无论产品负责人是否决定真正发布它，增量必须可用。
（2）产品待办事项列表
产品待办事项列表也称产品订单，是Scrum中的一个核心工件。产品待办事项列表是一个包含产品想法的有序列表，所有想法按照期待实现的顺序来排序。它是所有需求的唯一来源。这意味着开发团队的所有工作都来自产品待办事项列表。
最初，产品待办事项列表是一个长短不定列表，可以是模糊的或是不具体的。通常情况下，在开始阶段，产品待办事项列表比较短小且模糊，随着时间的推移，其逐渐变长，越来越明确。通过产品待办事项列表梳理活动，即将被实现的产品待办事项得到澄清，变得明确，粒度也拆得更小。产品负责人负责产品待办事项列表的维护，并保证其状态更新。产品待办事项可能来自于产品负责人、团队成员，或者其他利益干系人。
产品待办事项列表包含已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能性需求和非功能性需求及其他假设和约束条件。产品负责人和团队主要按业务和依赖性的重要程度划分优先等级，并做出估算。估算值的精确度取决于产品待办事项列表中条目的优先级和细致程度，入选下一个Sprint的最高优先等级条目的估算会非常精确。产品的需求清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就随之存在。而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出改变，以保证产品的适用性、实用性和竞争性。
（3）Sprint待办事项列表
Sprint待办事项列表也称Sprint订单，是一个需要在当前Sprint完成的且梳理过的产品待办事项，包括产品待办事项列表中的最高优先等级条目。该列表反映团队对当前Sprint中需要完成工作的预测，定义团队在Sprint中的任务清单，这些任务会将当前Sprint选定的产品待办事项列表转化为完整的产品功能增量。Sprint订单在Sprint计划会议中形成，任务被分解为以小时为单位。如果一个任务超过16小时，那么它应该被进一步分解。每项任务信息包括其负责人及其在Sprint中任一天时的剩余工作量，且仅团队有权改变其内容。在每个Sprint迭代中，团队强调应用“整体团队协作”的最佳实践，保持可持续发展的工作节奏和每日站立会议。
有了Sprint待办事项列表后，Sprint即开始，开发团队成员按照Sprint待办事项列表来开发新的产品增量。
（4）燃尽图
图3-13 燃尽图燃尽图（burndown chart）是一个公开展示的图表，如图3-13所示，纵轴代表剩余工作量，横轴代表时间，显示当前Sprint中随时间变化而变化的剩余工作量（可以是未完成的任务数目）。剩余工作量趋势线与横轴之间的交集表示在那个时间点最可能的工作完成量。可以借助它设想在增加或减少发布功能后项目的情况，可能缩短开发时间，或延长开发期限以获得更多功能。燃尽图可以展示项目实际进度与计划之间的矛盾。
3.Scrum活动
Scrum活动主要由产品待办事项列表梳理、Sprint计划会议、迭代式软件开发、每日站立会议、持续集成、Sprint评审会议和Sprint回顾会议组成。
（1）产品待办事项列表梳理
产品待办事项通常会很多，也很宽泛，而且想法会变来变去，优先级也会变化，所以产品待办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下的内容。
1）保持产品待办事项列表有序。
2）把看起来不再重要的事项移除或者降级。
3）增加或提升涌现出来的或变得更重要的事项。
4）将事项分解成更小的事项。
5）将事项归并为更大的事项。
6）对事项进行估算。
产品待办事项列表梳理的最大好处是为即将到来的Sprint做准备，为此梳理时会特别关注那些即将被实现的事项。
（2）Sprint计划会议
Sprint计划会议的目的是要为这个Sprint的工作做计划。这份计划是由整个Scrum团队共同协作完成的。Sprint开始时，均需召开Sprint计划会议，产品负责人和团队共同探讨该Sprint的工作内容。产品负责人从最优先的产品待办事项列表中进行筛选，告知团队其预期目标，团队则评估在接下来的Sprint内预期目标可实现的程度。Sprint计划会议一般不超过8小时。在前4小时中，产品负责人向团队展示最高优先级的产品，团队则向他询问产品待办事项列表的内容、目的、含义及意图，而在后4小时，进行本Sprint的具体安排。
Sprint计划会议最终产生的待办事项列表就是Sprint待办事项列表，它为开发团队提供指引，使团队明确构建增量的目的。
（3）迭代式软件开发
通过将整个软件交付过程分成多个迭代周期，团队可以更好地应对变更，应对风险，实现增量交付、快速反馈。通过关注保持整个团队可持续发展的工作节奏、每日站立会议和组织的工作分配，实现团队的高效协作和工作，实现提高整个团队生产力的目的。
（4）每日站立会议
在Sprint开发中，每天举行的项目状况会议称为每日站立会议。每日站立会议有一些具体的指导原则，具体如下。
1）会议准时开始：对于迟到者，团队常常会制定惩罚措施。
2）允许所有人参加。
3）不论团队规模大小，会议被限制在15分钟。
4）所有出席者应站立（有助于保持会议简短）。
5）会议应在固定地点和每天的同一时间举行。
6）在会议上，每个团队成员需要回答3个问题：
- 今天完成了哪些工作？
- 明天打算做什么？
- 完成目标是否存在什么障碍？
（5）持续集成
通过进行更频繁的软件集成，实现更早地发现和反馈错误，降低风险，并使整个软件的交付过程变得更加可预测和可控，以交付更高质量的软件。开发团队在每个Sprint都交付产品功能增量。这个增量是可用的，所以产品负责人可以选择立即发布它。每个增量都添加到之前的所有增量上，并经过充分测试，以此保证所有的增量都能工作。
（6）Sprint评审会议
Sprint评审会议一般需要4小时，由团队成员向产品负责人和其他利益干系人展示Sprint周期内完成的功能或交付的价值，并决定下一次Sprint的内容。在每个Sprint结束时，团队都会召开Sprint评审会议，团队成员在会上分别展示他们开发出的软件，并得到反馈信息，并决定下一次Sprint的内容。
（7）Sprint回顾会议
每一个Sprint完成后，都会举行一次Sprint回顾会议，在会议上所有团队成员都要反思这个Sprint。举行Sprint回顾会议是为了进行持续过程改进。会议的时间限制在4小时。这些任务会将当前Sprint选定的产品待办事项列表转化为完整的产品功能增量。开始下一个迭代。
3.5.2 XP
XP是由Kent Beck提出的一套针对业务需求和软件开发实践的规则，它的作用在于将二者力量集中在共同的目标上，高效并稳妥地推进开发。其力图在不断变化的客户需求的前提下，以持续的步调，提供高响应性的软件开发过程及高质量的软件产品，保持需求和开发的一致性。
XP提出的一系列实践旨在满足程序员高效的短期开发行为和项目长期利益的共同实现，这一系列实践长期以来被业界广泛认可，实施敏捷的公司通常会全面或者部分采用。
这些实践如图3-14所示，按照整体实践（entire team practice）、开发团队实践（development team practice）、开发者实践（developer practice）3个层面，XP提供如下13个核心实践：整体实践包括统一团队（whole team）、策划游戏（planning game）、小型发布（small release）及客户验收（customer test）。开发团队实践包括代码集体所有（team code ownership）、编码标准／规约（coding standard/convention）、恒定速率（sustainable pace，又名40小时工作）、系统隐喻（system metaphor）、持续集成（continuous integration/build）。开发者实践包括简单设计（simple design）、结对编程（pair programming）、测试驱动开发（testdriven development）、重构（refactoring）。具体介绍如下。
1.统一团队
XP项目的所有贡献者坐在一起。这个团队必须包括一个业务代表“客户”，提供要求，设置优先事项。客户或他的助手之一是一个真正的最终用户，是最好的；该小组也包括程序员；可能包括测试人员，帮助客户定义客户验收测试；可能包括分析师，帮助客户分析确定的要求；通常还有一个教练，帮助团队保持在正确轨道上；可能有一个上层经理，提供资源，处理对外沟通，协调活动。一个XP团队中的每个人都可以以任何方式做出贡献。最好的团队，没有所谓的特殊人物。
2.策划游戏
预测在交付日期前可以完成多少工作，现在和下一步该做些什么，不断地回答这两个问题，就是直接服务于如何实施及调整开发过程。与此相比，希望一开始就精确定义整个开发过程要做什么事情及每件事情要花多少时间，则事倍功半。针对这两个问题，XP中有两个主要的相应过程：软件发布计划（release planning）和周期开发计划（iteration planning）。
3.小型发布
每个周期开发达成的需求是用户最需要的东西。在XP中，对于每个周期完成时发布的系统，用户都应该可以很容易地评估，或者已能够投入实际使用。这样，软件开发不再是看不见摸不着的东西，而具有实实在在的价值。XP要求频繁地发布软件，如果可能，应每天都发布新版本，而且在完成任何一个改动、整合或者新需求后，应该立即发布一个新版本。这些版本的一致性和可靠性靠验收测试和测试驱动开发来保证。
4.客户验收
客户对每个需求都定义了一些验收测试。通过验收测试，开发人员和客户可以知道开发出来的软件是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费时间，最好能将这些测试过程自动化。
5.代码集体所有
在很多项目中，开发人员只维护自己的代码，而且不喜欢其他人修改自己的代码，因此即使有相应的比较详细的开发文档，但一个程序员很少甚至不太愿意去读其他程序员的代码；而且因为不清楚其他人的程序到底实现了什么功能，一个程序员一般也不敢随便改动其他人的代码。同时，因为自己维护自己的代码，可能因为时间紧张或技术水平的局限性，某些问题一直不能被发现或比较好地得到解决。针对这点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他代码，发现和纠正错误，重整和优化代码。这样，这些代码就不仅仅是一两个人写的，而是由整个项目开发队伍共同完成的，错误会减少很多，重用性会尽可能地得到提高，代码质量会非常好。
6.编码标准／规约
XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。因为有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是实现集体代码所有的重要前提之一。
7.恒定速率
XP团队处于高效工作状态，并保持一个可以无限期持续下去的状态。大量的加班意味着原来的计划是不准确的，或者是程序员不清楚自己到底什么时候能完成什么工作，而且开发管理人员和客户也因此无法准确掌握开发速度，开发人员也因此非常疲劳而降低效率及质量。XP认为，如果出现大量的加班现象，则开发管理人员（如coach）应该和客户一起确定加班的原因，并及时调整项目计划、进度和资源。
8.系统隐喻
为了帮助每个人一致清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。
9.持续集成
在很多项目中，往往很迟才能把各个模块整合在一起，在整合过程中，开发人员经常发现很多问题，但不能肯定到底是谁的程序出了问题，而且只有整合完成后，开发人员才开始使用整个系统，然后马上交付客户验收。对于客户来说，即使这些系统能够通过最终验收测试，因为使用时间短，客户心里并没有多少把握。为了解决这些问题，XP提出，在整个项目过程中，应该频繁地、尽可能早地整合已经开发完的用户故事(user story)。每次整合，都要进行相应的单元测试和验收测试，保证软件符合客户和开发的要求。整合后，发布一个新的应用系统。这样，在整个项目开发过程中，几乎每隔一两天，都会发布一个新系统，有时甚至会一天发布若干个版本。通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况和开发人员进行有效、及时交流，以确保项目顺利完成。
10.简单设计
XP要求用最简单的办法实现每个小需求，前提是按照简单设计开发的软件必须通过测试。这些设计只要能满足系统和客户当下的需求即可，不需要任何多余的设计，而且所有这些设计都将在后续的开发过程中被不断地重整和优化。在XP中，没有传统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯穿着整个项目开发：从制定项目的计划，到制定每个开发周期的计划，到针对每个需求模块的简捷设计，再到设计的复核，以及一直不间断的设计重整和优化。整个设计过程是一个螺旋式的、不断前进和发展的过程。从这个角度看，XP把设计做到了极致。
11.结对编程
在XP中，所有的代码是由两个程序员在同一台机器上一起写的，这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因此得到提高。看起来这样是在浪费人力资源，但是各种研究表明这种工作方式极大地提高了工作强度和工作效率。在项目开发中，每个人会不断地更换合作编程的伙伴，结对编程不但提高了软件质量，而且增强了相互之间的知识交流和更新，增强了相互之间的沟通和理解，这不但有利于个人，也有利于整个项目、开发队伍和公司。从这点看，结对编程不仅仅适用于XP，也适用于其他的软件开发方法。
12.测试驱动开发
在软件开发中，只有通过充分的测试才能获得充分的反馈。XP中提出的测试在其他软件开发方法中都可以见到，如功能测试、单元测试、系统测试和负荷测试等。与众不同的是，XP将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。另外，由于强调整个开发小组拥有代码，测试也是由大家共同维护的，即任何人在往代码库中放程序（check in）前，都应该运行一遍所有的测试；任何人如果发现了一个Bug，都应该立即为这个Bug增加一个测试，而不是等待写那个程序的人来完成；任何人接手其他人的任务，或者修改其他人的代码和设计，改动完以后如果能通过所有测试，就证明他的工作没有破坏原系统，这样测试才能真正起到帮助获得反馈的作用；而且，通过不断地优先编写和累积，测试应该可以基本覆盖全部的客户和开发需求，因此开发人员和客户可以得到尽可能充分的反馈。
13.重构
XP强调简单的设计，但简单的设计并不是没有设计的流水账式的程序，也不是没有结构、缺乏重用性的程序设计。开发人员虽然对每个用户故事都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫作设计的重构。重构的主要作用是努力减少程序和设计中重复出现的部分，增强程序和设计的可重用性。重构概念并不是XP首创的，它已被提出了多年，一直被认为是高质量代码的特点之一。但XP强调把重构做到极致，应随时随地尽可能地进行重构，程序员需要不断地改进程序。每次改动后，都应运行测试程序，保证新系统仍然符合预定的要求。
总之，XP实施原则是：①快速反馈；②假设简单；③包容变化。
3.5.3 OpenUP
OpenUP方法最早源自IBM内部对RUP（Rational Unified Process）的敏捷化改造，通过裁剪掉RUP中复杂和可选的部分，IBM于2005年推出了BUP（Basic Unified Process）和EPF（Eclipse Process Framework）。此后为了进一步推动UP族方法的发展，IBM将BUP方法捐献给Eclipse开源社区，于2006年初将BUP改名为OpenUP。OpenUP虽然受到Scrum、XP、Eclipse Way、DSDM、AMDD等各种敏捷方法的影响，但是主体仍然是RUP，即在一组被验证的结构化生命周期过程中应用增量迭代研发模式。OpenUP基于用例和场景、风险管理和以架构为中心的模式来驱动开发。图3-15显示了OpenUP的总体组织架构。OpenUP方法包含3个层次/领域的实践活动，分别针对利益干系人领域、项目团队领域和个人领域。
1.利益干系人领域
利益干系人通过项目周期计划获知产品的进展情况。项目周期计划被分成4个阶段，每个阶段都是一个里程碑，在里程碑处重点关注风险和交付。在每个里程碑处需要进行下列工作：对上一个里程碑的评审、对下一个里程碑的认可、风险识别和规避。
2.项目团队领域
项目团队需要以周为单位完成产品迭代开发。通常以2～6周为一个迭代周期。每个迭代周期起始时需要进行估算并完成周期迭代计划。通常以输出可演示版本为目标。每个迭代的策划工作通常以小时为单位完成，而不是传统意义上以天为单位的估算，同时需要以天为单位完成本次迭代的架构细化工作。此后进入实际研发，建议在迭代中定期完成每周Build,在迭代结束时完成稳定的迭代交付Build，同时花费少量时间（以小时为单位）完成迭代评审和反思。
3.个人领域
个人领域采用微增量的研发模式。一个微增量周期为几小时或几天不等，通常由一个人或者几个人完成。引入微增量可以将工作分成更为细小、更易于控制的部分。微增量可以是Vision的定义，也可以是模块设计，还可以是具体的研发和Bug修复工作。通过每日团队会议、团队协作工具，团队成员之间可以分享各自的工作进展和成果，同时可以演示自己的微增量成果来加深团队之间的沟通与理解。OpenUP并不明确定义研发中需要哪些微增量，这个部分可以结合项目实际情况或者其他模型加以确定。如何因地制宜、因项目制定敏捷实施方法？如何让敏捷在软件项目管理流程中发挥巨大作用？这是我们要认真思考的问题。
3.5.4 看板方法
看板一词来自日本，源于精益生产实践，大野耐一开发了看板，并在1953年将其应用于丰田的主要制造厂。敏捷开发将其背后的可视化管理理念借鉴过来。看板使得项目管理实现最大的可视化，并且可以对研发的过程进行管理，记录下用户故事研发过程中的细节和历程。
看板可以让研发过程最大限度地可视化，同时是解决团队沟通障碍（实践中发现也可以作为和上级沟通项目进展的重要信息）的主要方法之一。通过看板，项目团队可以清楚了解已经完成的情况，正在做的及后续将有可能需要做的用户故事，如图3-16所示。
看板可以作为敏捷团队每天站会讨论的核心，及时变更看板各个用户故事的状态。通过看板，敏捷团队可以清楚地了解其他成员的工作状况及和自己相关工作的进展。
在状态墙上，除了用户故事、Bug之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这些任务用不同颜色的卡片，放到状态墙上统一管理。
3.5.5 Scrumban方法
Scrumban最初设计为Scrum到看板之间的过渡方法。它是通过其自身衍生演变而成的一种混合敏捷框架和方法。团队将Scrum作为框架，而将看板作为过程改进方法。
在Scrumban中，工作被分解到许多小的“冲刺”，并利用看板面板来可视化和监督工作。将故事列在看板面板上，团队通过使用在制品限制（WIP limit）来管理其工作;团队通过召开每日例会来维持团队之间的协作并消除阻碍；通过设置规划触发因素来了解何时规划下一步工作，通常发生于在制品级别低于预设限制时。
3.5.6 精益模型
精益软件开发模式从一开始便侧重于提高过程的效率。它最初来自丰田公司的制造工业，其主要思想是分析所有的流程，以查明和消除浪费，不断提高效率。为了达到这个目的，精益模式提出了一些概念和实用的工具。大部分的工具在制造业使用而不能直接应用于软件开发。精益软件开发经常提及两个概念。一个是拉式系统（pull system）。在拉式系统中，一个流水线上的任何一个环节的任务完成后，都会从前一个环节自动提取下一个任务。该模式以客户的需求而不是市场预测来推动工作进程。另外，通过精益模式可以最小化未完成工作及半成品的数量，它们通常被认为是开发过程中的浪费。除了拉式系统，价值流图（value stream mapping）也经常被应用于软件开发过程中。价值流图能够有效地识别过程中的浪费。
对于软件开发而言，在开发者或者最终用户的视角上观察软件开发过程，并发现和消除无益于快速交付的行为，即为精益的软件开发。
3.5.7 持续交付
持续交付是经典的敏捷软件开发方法（如XP、Scrum）的自然延伸。以往的敏捷方法并没有过多关注开发测试前后的活动（如前期的需求分析、产品的用户体验设计、产品的部署和运行维护等），然而伴随着敏捷的很多思想和原则在前后端领域的运用和升华，我们在持续交付这个新的大概念下看到了敏捷方法和更多实践活动的结合和更大范围的应用。
持续交付所描述的软件开发，是从原始需求识别到最终产品部署到生产环境这个过程中，需求以小批量形式在团队的各个角色间顺畅流动，能够以较短的周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，需求分析、产品的用户体验和交互设计、开发、测试、运维等角色密切协作。持续交付也需要持续集成、持续部署的支持。持续集成是指个人代码向软件整体部分交付，以便尽早发现个人开发部分的问题；持续部署是指集成的代码尽快向可运行环境交付，以便尽早测试；持续交付是指尽快向客户交付，以便尽早发现生产环境中存在的问题。
持续交付的前提是持续部署，持续部署和持续交付之间的一个区别在于，部署可以很频繁，然而实际交付给用户使用则可能根据计划进行，比部署的频率低。要实现产品的持续部署，还需要自动化构建流水线（build pipeline）。以自动化生产线作比，自动化测试只是其中一道质量保证工序，而要将产品从原料（需求）转变为最终交付给客户的产品，自动化的生产线起着核心作用。特别对于软件产品，多个产品往往要集成在一起才能为客户提供服务。多个产品的自动化构建流水线的设计也就成了一个很重要的问题。
产品在从需求到部署的过程中，会经历若干种不同的环境，如QA环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，以及产品在不同环境中的具体部署，都需要完善的工具支持。缺乏这些工具，生产流水线就不可能做到完全自动化和高效。
3.5.8 DevOps
DevOps（Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（Quality Assurance,QA）部门之间的沟通、协作与整合，如图3-17所示。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作，由持续交付演变出了DevOps，即开发端和运维端的全程敏捷思维。传统运维人员和开发者之间的目标是有差异的，开发和运营原本有着不同的目标，开发人员希望快速提交产品，运营人员希望产品的更合理化、高性能、高可靠等，减少维护成本，开发者和运维人员之间目的上的差异就叫作“混乱之墙”。
可以把DevOps看作开发、技术运营和质量保障（QA）三者的交集，传统的软件组织将开发、技术运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要技术支持或者QA深入的、跨部门的支持，而需要极其紧密的多部门协作。然而DevOps考虑的不仅是软件部署，还包括一套针对这几个部门间沟通与协作问题的流程和方法。
DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”——例如，运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。DevOps融合一系列基本原则和实践的方法论，将开发和运维端融合在一起，从而可以更有效地解决这类问题。
3.5.９ 其他敏捷模型简介
1.功能驱动开发
功能驱动开发（Feature Driven Development,FDD）的开发目的是满足大型软件开发项目的特定需求。小型商业价值功能重视能力。
2.动态系统开发方法
动态系统开发方法（Dynamic System Development Method,DSDM）是一种敏捷项目交付框架，最初的设计目的是提高20世纪90年代普及的迭代方法的严格程度。该框架开发为行业领导者之间的非商业性协作方式。DSDM因强调制约因素驱动交付而著称。该框架从一开始便可设置成本、质量和时间，然后利用正式的范围优先级来满足这些制约因素的要求。
3.SoS
SoS（Scrum of Scrums）也称为meta Scrum，是一种由两个或多个Scrum团队而不是一个大型Scrum团队所使用的技术，其中一个团队包含3～9名成员来协调其工作。每个团队的代表与其他团队的代表定期召开会议，可能是每日例会，但通常是一周两次或三次。每日例会的执行方式类似于Scrum的每日站会，与会代表将报告已完成的工作、下一步工作设置、任何当前障碍及可能会阻碍其他团队的潜在未来障碍。其目标是确保团队协调工作并清除障碍，以优化所有团队的效率。具有多个团队的大型团队可能要求执行SoS，其遵循的模式与SoS相同，每个SoS代表向更大组织的代表报告。
当然还有其他大规模项目的敏捷方法模型，如大规模敏捷框架SAFe、大规模敏捷开发（LeSS）等，限于篇幅，这里不再一一介绍，感兴趣的读者可以查阅相关资料以进一步了解。
3.6 混合型生存期模型
对于整个项目，没有必要使用单一的方法。为达到特定的目标，项目经常要结合不同的生命周期要素。预测、迭代、增量和敏捷方法的组合就是一种混合方法。
1.先敏捷后预测型综合方法
图3-１8描述了先敏捷后预测型综合方法，它们结合起来就形成一种混合模型。早期过程采用一个敏捷开发生命周期，之后往往是一个预测型的发布阶段。当项目可以从敏捷方法中受益并且项目的开发部分中存在不确定性、复杂性和风险时，可以使用这种方法，然后是一个明确的、可重复的发布阶段，该阶段适合采用预测方法进行，可能由不同的团队实施。例如，开发某种新的高科技产品，然后面向成千上万的用户推出，并对他们进行培训。
2.敏捷和预测综合方法
敏捷和预测综合方法是指同一项目在整个生命周期中结合使用敏捷方法和预测法，如图3-１9所示。也许团队正在逐渐地向敏捷过渡，并使用一些方法，如短迭代、每日站会和回顾，但在项目的其他方面，如前期评估、工作分配和进度跟踪等，仍然遵循了预测法。
同时使用预测法和敏捷方法是一个常见的情况。将这种方法称为敏捷方法是一种误导，因为它显然没有充分体现敏捷思维模式、价值观和原则。不过，由于这是一种混合方法，所以称其为预测法也是不准确的。
3.以预测法为主、敏捷方法为辅的方法
如图3-20所示，在一个以预测法为主的项目中增加敏捷要素，在这种情况下，以敏捷方法处理具有不确定性、复杂性或范围蔓延机会项目的一部分，而使用预测法管理项目的其余部分。
4.以敏捷方法为主、预测法为辅的方法
图3-２1描述了一个以敏捷方法为主、预测法为辅的方法。当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用这种方法。例如，集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方式合作。在组件交付之后，需要单独集成。
3.7 “医疗信息商务平台”生存期模型案例分析
本项目采用Scrum敏捷生存期模型，产品目录及优先级如表3-2所示，整个项目分4个迭代，即4个Sprint（冲刺迭代），表3-2也说明了每个Sprint包括的需求内容，第一个Sprint包括产品目录中前4优先级内容。每个冲刺订单（迭代）的周期大概是4周，每个冲刺订单完成之后提交一个可以运行的版本。因此，本项目的Scrum敏捷模式可以通过图3-22展示。具体生存期定义如图3-23所示。
生存期中的各阶段定义如下。
1.需求分析阶段
阶段目标：确定需求的功能和服务。
进入条件：用户提出初始需求。
输入：演示系统。
输出：关键特性表(Key Feature List，KFL)、业务过程定义(business process definition)、需求定义文档。
完成标志：输出通过用户确认。
2.系统设计阶段
阶段目标：根据已有的系统结构确定应用逻辑结构、数据库结构和页面结构。
进入条件：提交需求分析初步结果。
输入：关键特性表、商务过程定义文档、需求定义文档。
输出：系统设计报告、Data Medel和数据库、页面流(page flow)。
完成标志：设计通过专家的对等评审。
3.项目规划阶段
阶段目标：根据需求分析和系统设计结果确定本阶段的时间计划、资源需求和资金预算。
进入条件：提交需求分析初步结果。
输入：需求定义文档、系统设计文档。
输出：项目计划。
完成标志：项目计划经合同管理者审批。
4.迭代n设计
阶段目标：设计与迭代n相关的页面、应用逻辑。
进入条件：设计通过专家的对等评审。
输入：系统设计文件、数据库结构定义。
输出：详细设计报告。
完成标志：设计通过对等评审。
5.迭代n开发
阶段目标：实现迭代n。
进入条件：设计通过专家的对等评审。
输入：详细设计报告。
输出：程序包。
完成标志：迭代n与网站系统集成调试完毕。
6.集成测试
阶段目标：通过集成环境下的软件测试。
进入条件：迭代n与网站系统集成调试完毕。
输入：网站系统和迭代n功能包、QA数据库、测试案例。
输出：测试报告。
完成标志：测试报告通过审核。
7.确认测试
阶段目标：通过QA环境下的确认测试。
进入条件：集成测试完毕，WDB可以转入QA DB。
输入：网站系统软件包、QA数据库、测试案例。
输出：测试报告。
完成标志：测试报告通过审核。
8.产品提交
阶段目标：系统投入使用。
进入条件：测试报告通过审核。
输入：网站系统软件包。
输出：CD。
完成标志：用户完成产品接收。
3.8 小结
本章介绍了软件项目生存期模型的类型和特点，总体分预测型模型和适应型模型，适应型可以是迭代型、增量型、敏捷型，混合型生存期模型是预测型和适应模型的组合。瀑布模型、V模型属于预测型模型，快速原型模型属于迭代型模型，渐进式阶段模型属于增量型模型，特别展开介绍Ｓcｒｕｍ、ＸＰ、看板方法、精益模型、持续交付、DevOps等各敏捷模型。
3.9 练习题
一、填空题
1. 生存期模型要求项目所有的活动都严格按照顺序执行，一个阶段的输出是下一个阶段的输入。
2.总体上，项目生存期模型可以是预测型或 。
- DevOps是 和 的组合。
二、判断题
1.瀑布模型不适合短期项目。（ ）
2.增量型生存期模型可以避免一次性投资太多带来的风险。（ ）
3.V模型适合的项目类型是需求很明确、解决方案很明确，而且对系统的性能要求比较严格的项目。（ ）
4.瀑布模型和V模型都属于预测型生存期模型。（ ）
5.瀑布模型要求项目所有的活动都严格按照顺序执行，一个阶段的输出是下一个阶段的输入。（ ）
6.极限编程（eXtreme Programming，XP）从3个层面提供了13个敏捷实践。（ ）
7.敏捷包括《敏捷宣言》的价值观、12个原则，以及一些通用实践等。（ ）
三、选择题
1.对于某项目，甲方提供了详细、准确的需求文档，我们的解决方案也很明确，且安全性要求非常严格，此项目采用（ ）比较合适。
A.瀑布模型
B.增量型生存期模型
C.V模型
D.XP模型
2.下面属于预测型生存期模型的是（ ）。
A.瀑布模型
B.增量型生存期模型
C.Scrum模型
D.原型模型
3.下面关于敏捷模型描述不正确是（ ）。
A.与传统模型相比，敏捷模型属于自适应过程
B.可以应对需求的不断变化
C.Scrum模型、XP模型、DevOps模型等都属于敏捷模型
D.敏捷模型是预测型和迭代型的混合模型。
4.XP模型的实践原则不包括（ ）。
A.快速反馈
B.假设简单
C.包容变化
D.详细设计
5.在项目初期，一个项目需求不明确的情况下，应避免采用以下哪种生存期模型？（ ）
A.快速原型模型
B.增量型生存期模型
C.V模型
D.Scrum模型
6.关于迭代模型，下列说法不正确的是（ ）。
A.不断反馈原型
B.可以加快开发速度
C.项目需求变化大
D.不多次提交
四、问答题
1.写出3种你熟悉的生存期模型，并说明这些模型适用什么情况下的项目。
2.混合模型是什么模型？