丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
为了提交一个满意的项目，需要选择项目实施策略，选择生存期模型的过程就是选择策略的过程。下面进入路线图的“生存期模型”，如图3-1所示。
软件项目生存期模型的基本特征如下。1）描述开发的主要阶段。2）定义每一个阶段要完成的主要过程和活动。3）规范每一个阶段的输入和输出。在生存期模型中定义软件过程非常重要，人和过程是保证项目成功的两个关键因素。由合适的人按好的过程进行项目开发，才能最大限度地保证项目的成功。通过过程可以实现一种规范化、流水线化、工业化的软件开发。软件的生产过程不存在绝对正确的过程形式，不同的软件开发项目应当采用不同的或者有针对性的软件开发过程，而真正合适的软件开发过程是在软件项目开发完成后才能明了的。因此，项目开发之初只能根据项目的特点和开发经验进行选择，并在开发过程中不断地调整。软件生存期模型的选择对项目成功的影响非常重要。恰当的生存期模型可以使软件项目流程化，并帮助项目人员一步一步地接近目标。如果选择了适宜的生存期模型，就可以提高开发速度，提升质量，加强项目跟踪和控制，减少成本，降低风险，改善用户关系。
软件开发模型总体上经历了从传统到敏捷的变迁，从最初的作坊式的单打独斗，到诸如CMM等过程改进式的过程控制，再到敏捷模型，如图3-2所示。敏捷模型也发展出更多模型，如时下流行的DevOps。
项目有多种形式，也有多种实施方式。项目团队根据项目特征选择最可能使项目成功的生存期模型和方法。总体上，项目生存期模型可以是预测型或适应型。适应型模型可以是迭代型、增量型、敏捷型等，如图3-3所示从两个维度展示了这4类模型的关系。从项目变化角度看，预测型低，迭代型高；从提交的频繁度看，预测型低，增量型高。敏捷模型既有迭代型，也有增量型，便于完善工作，可以频繁交付。充分了解或有确定需求的项目要素遵循预测型开发模型，而仍在发展中的要素遵循适应型开发模型。
其中：
不同生存期模型的特征如表3-1所示。表3-1从项目需求、开发活动、产品交付及目标等角度展示了四大模型的项目特征。从项目需求上看：预测型的需求最稳定；其他3个类型需求有变化。从开发活动上看：预测型是每个开发活动只执行一次，瀑布模型就是这样；迭代型是不断重复一些活动，直到正确为止；增量型是每个增量活动只执行一次；敏捷型也是不断重复一些活动，直到正确为止。从产品交付上看：预测型、迭代型只提交一次；增量型、敏捷型多次提交小版本。从目标上看：预测型的目标是管理成本；迭代型的目标是获得正确的解决方案；增量型的目标是加快速度；敏捷型通过不断提交和反馈获得用户肯定。这些特征可以作为选择模型的参考。
需要注意的是，所有的项目都具有这些特征，没有一个项目能够完全不考虑需求、交付、变更和目标这些因素。项目的固有特征决定了其适合采用哪种生存期模型。另一种理解不同项目生存期的方法是使用一个连续区间，从图3-3一端的预测型模型到另一端的敏捷型模型，连续区间中间还有更多的迭代型周期或增量型周期。没有哪个生存期模型能够完美地适用于所有的项目。相反，每个项目都能在连续区间中找到一个点，根据其背景特征实现最佳平衡。实践中还有混合型生存期模型，这种模型是预测型和适应型的组合。
预测型生存期模型充分利用已知和已经证明的事物，不确定性和复杂性减少，允许项目团队将工作分解为一系列可预测的小组，是一种传统的模型，如瀑布模型。预测型生存期模型预计会从高确定性的明确需求、稳定的团队和低风险中获益。因此，项目活动通常以顺序方式执行，如图3-4所示。
为了实现这种方法，团队需要详细的计划，了解要交付什么及怎样交付。当其他潜在的变更受到限制时，这些项目就会成功。团队领导的目标是尽可能减少预测型项目的变更。团队在项目初始创建详细的需求和计划时，可以阐明各种制约因素,然后利用这些制约因素管理风险和成本。进而，在实施详细计划时，团队会监督并控制可能影响范围、进度计划或预算的变更。如果遇到变更或需求分歧，或者技术解决方案变得不再简单明了，则预测型项目将产生意想不到的成本。瀑布模型和V模型是最典型的预测型生存期模型。
（waterfallmodel）是一个经典的模型，也称为传统模型（conventionalmodel），它是一个理想化的生存期模型，如图3-5所示。它要求项目所有的活动都严格按照顺序自上而下执行，一个阶段的输出是下一阶段的输入，如同瀑布流水，逐级下落。瀑布模型没有反馈，一个阶段完成后，一般不返回——尽管实际的项目中要经常返回上一阶段。瀑布模型是一个比较“老”的模型，甚至有些过时，但在一些小的项目中还是经常用到的。
V模型是由PaulRook在1980年提出的，是瀑布模型的一种变种，同样需要一步一步进行，前一阶段任务完成之后才可以进行下一阶段的任务，如图3-6所示。
增量型生存期模型的策略是不同时开发项目需求，而是将需求分段，使其成为一系列增量产品，每一增量可以分别实施，每个增量都包括分析、设计、实施、测试、提交等过程。每个增量是一个交付成果。第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，不断重复这个过程，直到产生最终的完善产品。增量型生存期模型如图3-9所示。
敏捷生存期模型是符合《敏捷宣言》原则的模型，客户满意度将随着有价值产品的早期交付和持续交付不断提升。此外，功能性的、提供价值的增量可交付成果是衡量进展的主要尺度。为了适应更频繁的变更，更频繁地交付项目价值，敏捷生存期模型结合了迭代和增量方法。在敏捷环境中，团队预料需求会发生变更。迭代和增量方法能够提供反馈，以便改善项目下一部分的计划。不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。图3-11显示了实现增量交付的两种可能的方法（基于迭代和基于流程），这样便于项目与客户需求保持一致，并根据需要进行调整。
OpenUP方法最早源自IBM内部对RUP（RationalUnifiedProcess）的敏捷化改造，通过裁剪掉RUP中复杂和可选的部分，IBM于2005年推出了BUP（BasicUnifiedProcess）和EPF（EclipseProcessFramework）。此后为了进一步推动UP族方法的发展，IBM将BUP方法捐献给Eclipse开源社区，于2006年初将BUP改名为OpenUP。OpenUP虽然受到Scrum、XP、EclipseWay、DSDM、AMDD等各种敏捷方法的影响，但是主体仍然是RUP，即在一组被验证的结构化生命周期过程中应用增量迭代研发模式。OpenUP基于用例和场景、风险管理和以架构为中心的模式来驱动开发。图3-15显示了OpenUP的总体组织架构。OpenUP方法包含3个层次/领域的实践活动，分别针对利益干系人领域、项目团队领域和个人领域。
看板一词来自日本，源于精益生产实践，大野耐一开发了看板，并在1953年将其应用于丰田的主要制造厂。敏捷开发将其背后的可视化管理理念借鉴过来。看板使得项目管理实现最大的可视化，并且可以对研发的过程进行管理，记录下用户故事研发过程中的细节和历程。看板可以让研发过程最大限度地可视化，同时是解决团队沟通障碍（实践中发现也可以作为和上级沟通项目进展的重要信息）的主要方法之一。通过看板，项目团队可以清楚了解已经完成的情况，正在做的及后续将有可能需要做的用户故事，如图3-16所示。
Scrumban最初设计为Scrum到看板之间的过渡方法。它是通过其自身衍生演变而成的一种混合敏捷框架和方法。团队将Scrum作为框架，而将看板作为过程改进方法。在Scrumban中，工作被分解到许多小的“冲刺”，并利用看板面板来可视化和监督工作。将故事列在看板面板上，团队通过使用在制品限制（WIPlimit）来管理其工作;团队通过召开每日例会来维持团队之间的协作并消除阻碍；通过设置规划触发因素来了解何时规划下一步工作，通常发生于在制品级别低于预设限制时。
精益软件开发模式从一开始便侧重于提高过程的效率。它最初来自丰田公司的制造工业，其主要思想是分析所有的流程，以查明和消除浪费，不断提高效率。为了达到这个目的，精益模式提出了一些概念和实用的工具。大部分的工具在制造业使用而不能直接应用于软件开发。精益软件开发经常提及两个概念。一个是拉式系统（pullsystem）。在拉式系统中，一个流水线上的任何一个环节的任务完成后，都会从前一个环节自动提取下一个任务。该模式以客户的需求而不是市场预测来推动工作进程。另外，通过精益模式可以最小化未完成工作及半成品的数量，它们通常被认为是开发过程中的浪费。除了拉式系统，价值流图（valuestreammapping）也经常被应用于软件开发过程中。价值流图能够有效地识别过程中的浪费。对于软件开发而言，在开发者或者最终用户的视角上观察软件开发过程，并发现和消除无益于快速交付的行为，即为精益的软件开发。
DevOps（Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QualityAssurance,QA）部门之间的沟通、协作与整合，如图3-17所示。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作，由持续交付演变出了DevOps，即开发端和运维端的全程敏捷思维。传统运维人员和开发者之间的目标是有差异的，开发和运营原本有着不同的目标，开发人员希望快速提交产品，运营人员希望产品的更合理化、高性能、高可靠等，减少维护成本，开发者和运维人员之间目的上的差异就叫作“混乱之墙”。
可以把DevOps看作开发、技术运营和质量保障（QA）三者的交集，传统的软件组织将开发、技术运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要技术支持或者QA深入的、跨部门的支持，而需要极其紧密的多部门协作。然而DevOps考虑的不仅是软件部署，还包括一套针对这几个部门间沟通与协作问题的流程和方法。DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”——例如，运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。DevOps融合一系列基本原则和实践的方法论，将开发和运维端融合在一起，从而可以更有效地解决这类问题。
对于整个项目，没有必要使用单一的方法。为达到特定的目标，项目经常要结合不同的生命周期要素。预测、迭代、增量和敏捷方法的组合就是一种混合方法。1.先敏捷后预测型综合方法图3-１8描述了先敏捷后预测型综合方法，它们结合起来就形成一种混合模型。早期过程采用一个敏捷开发生命周期，之后往往是一个预测型的发布阶段。当项目可以从敏捷方法中受益并且项目的开发部分中存在不确定性、复杂性和风险时，可以使用这种方法，然后是一个明确的、可重复的发布阶段，该阶段适合采用预测方法进行，可能由不同的团队实施。例如，开发某种新的高科技产品，然后面向成千上万的用户推出，并对他们进行培训。2.敏捷和预测综合方法敏捷和预测综合方法是指同一项目在整个生命周期中结合使用敏捷方法和预测法，如图3-１9所示。也许团队正在逐渐地向敏捷过渡，并使用一些方法，如短迭代、每日站会和回顾，但在项目的其他方面，如前期评估、工作分配和进度跟踪等，仍然遵循了预测法。
同时使用预测法和敏捷方法是一个常见的情况。将这种方法称为敏捷方法是一种误导，因为它显然没有充分体现敏捷思维模式、价值观和原则。不过，由于这是一种混合方法，所以称其为预测法也是不准确的。3.以预测法为主、敏捷方法为辅的方法如图3-20所示，在一个以预测法为主的项目中增加敏捷要素，在这种情况下，以敏捷方法处理具有不确定性、复杂性或范围蔓延机会项目的一部分，而使用预测法管理项目的其余部分。4.以敏捷方法为主、预测法为辅的方法图3-２1描述了一个以敏捷方法为主、预测法为辅的方法。当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用这种方法。例如，集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方式合作。在组件交付之后，需要单独集成。
本项目采用Scrum敏捷生存期模型，产品目录及优先级如表3-2所示，整个项目分4个迭代，即4个Sprint（冲刺迭代），表3-2也说明了每个Sprint包括的需求内容，第一个Sprint包括产品目录中前4优先级内容。每个冲刺订单（迭代）的周期大概是4周，每个冲刺订单完成之后提交一个可以运行的版本。因此，本项目的Scrum敏捷模式可以通过图3-22展示。具体生存期定义如图3-23所示。
本章介绍了软件项目生存期模型的类型和特点，总体分预测型模型和适应型模型，适应型可以是迭代型、增量型、敏捷型，混合型生存期模型是预测型和适应模型的组合。瀑布模型、V模型属于预测型模型，快速原型模型属于迭代型模型，渐进式阶段模型属于增量型模型，特别展开介绍Ｓcｒｕｍ、ＸＰ、看板方法、精益模型、持续交付、DevOps等各敏捷模型。
一、填空题
1.生存期模型要求项目所有的活动都严格按照顺序执行，一个阶段的输出是下一个阶段的输入。
2.总体上，项目生存期模型可以是预测型或。
二、判断题
1.瀑布模型不适合短期项目。（）
2.增量型生存期模型可以避免一次性投资太多带来的风险。（）
3.V模型适合的项目类型是需求很明确、解决方案很明确，而且对系统的性能要求比较严格的项目。（）
4.瀑布模型和V模型都属于预测型生存期模型。（）
5.瀑布模型要求项目所有的活动都严格按照顺序执行，一个阶段的输出是下一个阶段的输入。（）
6.极限编程（eXtremeProgramming，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种你熟悉的生存期模型，并说明这些模型适用什么情况下的项目。