下载掌阅APP，畅读海量书库
立即打开
为了软件项目的顺利实施，需要选择合适的实施策略，选择生存期模型的过程就是选择策略的过程。本章进入路线图的“生存期模型”，如图3-1所示。
图3-1 项目初始—生存期模型
软件项目生存期模型具有如下基本特征。
· 描述开发的主要阶段。
· 定义每一个阶段要完成的主要过程和活动。
· 规范每一个阶段的输入和输出。
在生存期模型中定义软件过程非常重要，人和过程是保证项目成功的两个关键因素。由好的人按好的过程进行项目开发，才能最大限度地保证项目的成功。通过过程可以实现一种规范化、流水线化、工业化的软件开发方法。软件的生产过程不存在绝对正确的过程形式，不同的软件开发项目应当采用不同的或者有针对性的软件开发过程，而真正合适的软件开发过程在软件项目的开发完成后才能明了。因此项目开发之初，只能根据项目的特点和开发经验进行选择，并在开发过程中不断地调整。
软件生存期模型的选择对项目的影响非常大。恰当的生存期模型可以使软件项目流程化，并帮助项目人员一步一步接近目标。如果选择了适宜的生存期模型，就可以提高开发速度、提升软件质量、加强项目跟踪和控制、减少成本、降低风险、改善用户关系。
软件生存期模型总体上经历了从传统到敏捷的变迁，从最初作坊式的个人单打独斗模式到传统瀑布模型，再到敏捷模型、DevOps模型，随着AI技术的发展，基于AI驱动的开发模型也将逐步形成，如图3-2所示。
图3-2 软件生存期模型的变迁
项目有多种形式，也有多种实施方式。项目团队根据项目特征选择最可能使项目成功的生存期模型和方法。总体上，项目生存期模型可以是预测型或适应型。适应型可以是迭代型、增量型、敏捷型等，图3-3从两个纬度展示了这4类模型的关系。从项目变化角度看，预测型低，迭代型高：从提交的频率看，预测型低，增量型高。被充分了解或有确定需求的项目要素遵循预测型开发模型，而仍在发展中的要素遵循适应型开发模型。
其中：
· 预测型生存期模型是一种更为传统的方法，需要提前进行大量的计划工作，然后一次性执行，执行是一个连续的过程。
· 迭代型生存期模型允许对未完成的工作进行反馈，从而改进和修改该工作。允许对部分完成或未完成的工作进行反馈，从而对该工作进行改进和修改。
图3-3 生存期模型分类
· 增量型生存期模型向客户提供已完成的、可以立即使用的可交付成果。
· 敏捷型生存期模型同时利用迭代属性和增量特征，便于完善工作，频繁交付。团队使用敏捷方法时，他们会对产品进行迭代，创建可交付成果。团队将获得早期的反馈，并能提供客户可见性、信心和对产品的控制。由于团队可以提前发布产品，而团队将率先交付价值最高的工作，所以项目可以更早产生投资回报。
表3-1展示了不同生存期模型的特征。该表从项目需求、开发活动、产品交付和目标等角度看四大模型的项目特征。从项目需求上看：预测型的需求最稳定，其他三个模型的需求有变化。从开发活动上看：预测型项目是每个开发活动只执行一次，例如瀑布模型就是这样；迭代型是不断重复一些活动，直到正确为止；增量型是每个增量的活动只执行一次；敏捷型也是不断重复一些活动，直到正确为止。从产品交付上看：预测型、迭代型只提交一次，增量型、敏捷模型多次提交小版本。从目标上看：预测型的目标是管理成本，迭代型的目标是获得正确的解决方案，增量型的目标是加快速度，敏捷型通过不断提交和反馈获得用户肯定。这些特征可以作为选择模型的参考。
表3-1 生存期模型的特征
（续）
需要注意的是，所有的项目都具有这些特征，没有一个项目能够完全不考虑项目需求、开发活动、产品交付和目标这些因素。项目的固有特征决定了其适合采用哪种生存期模型。
另一种理解不同项目生存期模型的方法是，使用一个连续区间。从图3-3一端的预测型模型到另一端的敏捷型模型，连续区间中还有更多的迭代型周期或增量型周期。没有哪个生存期模型能够完美地适用于所有的项目，相反，每个项目都能在连续区间中找到一个点，根据其背景特征，实现最佳平衡。
预测型生存期模型充分利用已知和已经证明的事物减少不确定性和复杂性，允许项目团队将工作分解为一系列可预测的小组，是一种传统的生存期模型，例如瀑布模型。预测型模型预计会从高确定性的明确需求、稳定的团队和低风险中获益。因此，项目活动通常以顺序方式执行，如图3-4所示。
图3-4 预测型生存期模型
为了实现这种方法，团队需要制订详细的计划，了解要交付什么以及怎样交付。当其他潜在变更受到限制时，这些项目就会成功。团队领导的目标是尽可能减少预测型项目的变更。
团队在项目开始阶段创建详细的需求和计划时，可以阐明各种制约因素，然后可以利用这些制约因素管理风险和成本，进而在实施详细计划时，监督并控制可能影响范围、进度计划或预算的变更。
预测型项目如果遇到变更或需求分歧，或者技术解决方案变得不再简单明了，预测型项目就将产生意想不到的成本。瀑布模型和V模型是最典型的预测型模型。
瀑布模型（waterfall model）是一个经典的模型，也称为传统模型（conventional model），它是一个理想化的生存期模型，如图3-5所示。它要求项目所有的活动都严格按照顺序自上而下执行，一个阶段的输出是下一个阶段的输入，如同瀑布逐级下落。瀑布模型没有反馈，一个阶段完成后，一般不返回—尽管实际的项目中要经常返回上一个阶段。瀑布模型是一个比较“老”的模型，甚至有些过时，但在一些小的项目中经常用到。
图3-5 瀑布模型
瀑布模型的优点如下。
· 简单、易用、直观。
· 开发进程比较严格，一个进程接着一个进程进行。
· 模型执行过程中需要严密控制。
· 允许基线和配置早期接受控制。
· 为项目提供了按阶段划分的检查点，当前一个阶段完成后，只需要关注后续阶段。
瀑布模型的缺点如下。
· 在软件开发的初期阶段就做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。
· 由于开发模型是线性的，模型中没有反馈过程，用户只有等到整个过程的末期才能见到开发成果，增加了开发风险。
· 新的项目不适合瀑布模型。
· 用户直到项目结束才能看到产品的质量，用户不能循序渐进地熟悉系统。
· 不允许变更或者限制变更。
· 早期的错误可能要等到开发后期才能发现，进而带来严重后果。
瀑布模型适合软件需求很明确的软件项目，即一般适用于功能明确、完整、无重大变化的软件系统的开发。
· 在项目开始前，项目的需求已经被很好地理解，也很明确，而且项目经理很熟悉为实现这一模型所需要的过程。
· 解决方案在项目开始前也很明确。
· 短期项目可以采用瀑布模型。
下面是瀑布模型的使用说明。
· 开发前，要进行概念开发和系统配置开发，概念开发主要是确定系统级的需求，提交一份任务陈述。系统配置开发需要确定软件和硬件的情况。
· 开发中，需要完成需求过程、设计过程、实施过程。
· 开发后，需要完成安装过程、支持过程、维护过程等。
瀑布模型因为缺乏灵活性、适应性不佳而渐渐受到质疑。Royce在1970年发表的《管理大型软件系统的开发》中提到：建议在关键的原型阶段之后应用瀑布模型，在原型阶段要充分地理解所要应用的关键技术及客户的实际需求。
V模型是由Paul Rook在1980年提出的，是瀑布模型的一个变种，同样需要一步一步地进行，上一阶段任务完成之后才可以进行下一阶段的任务，如图3-6所示。
该模型强调测试的重要性，将开发活动与测试活动紧密地联系在一起。每一步都将进行比上一阶段更加完善的测试。一般，大家对测试存在一种误解，认为测试是开发周期的最后一个阶段。其实，早期的测试工作对提高产品的质量、缩短开发周期起着重要作用。V模型正好说明了测试的重要性，它是与开发并行的，例如，单元测试对应详细设计，集成测试对应概要设计，系统测试对应需求分析。V模型体现了全过程的质量意识。
图3-6 V模型
V模型的优点如下。
· 简单易用，只要按照规定的步骤一步一步执行即可。
· 强调测试过程与开发过程的对应性和并行性。
· 开发进程比较严格，执行过程需要严密控制。
· 允许基线和配置早期接受控制。
· 为项目提供了按阶段划分的检查点，当上一个阶段完成后，只需要关注后续阶段。
V模型的缺点如下。
· 软件开发的初期阶段就要求做出正确、全面、完整的需求分析。
· 软件项目的实现方案需要很明确。
· 不能存在变更。
V模型的适用范围如下。
· 项目的需求在项目开始前很明确。
· 解决方案在项目开始前也很明确。
· 项目对系统的性能安全要求很严格，如航天飞机控制系统、公司的财务系统等。
使用V模型时，要求开发的全过程是严格按照顺序进行的，一个阶段的输出是下一个阶段的输入。同时，注意图3-6中虚线对应过程的并行考虑，例如：在需求分析阶段，应该有系统测试的准备；在概要设计阶段，应该有集成测试的准备；在详细设计阶段，应该有单元测试的准备等。
迭代型生存期模型通过连续的原型或概念验证来改进产品或成果，对部分完成或未完成的工作进行反馈，从而对该工作进行改进和修改。每一个新的原型都能带来相关方新的反馈和团队见解。然后，团队在下一个周期重复一个或多个项目活动，在其中纳入新的信息。这样，迭代有利于识别和减少项目的不确定性。
当项目复杂性高、变更频繁或项目范围受到相关方对所需最终产品的不同观点的支配时，采用迭代型生存期模型会有优势。迭代型生存期模型可能需要更长的时间，因为它是为学习而优化，而不是为交付速度而优化的。迭代型生存期模型如图3-7所示。
图3-7 迭代型生存期模型
增量型生存期模型的策略是不同时开发项目需求，而是将需求分段，使其成为一系列增量产品，每个增量可以分别实施，每个增量都包括需求分析、设计、实施、测试、交付等过程。每个增量是一个交付成果。第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，不断重复这个过程，直到产生最终的完善产品。增量型生存期模型如图3-8所示。
图3-8 增量型生存期模型
增量型生存期模型在各个阶段并不交付可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品。所以，增量型生存期模型向客户提供完成的可交付成果，让客户能够立即使用。如果有些项目是为了加快交付速度，或者无法等待所有的事情全部完成，可以采用频繁交付少量可交付成果的方式，即增量型生存期模型。这种情况下，客户是先接受整个解决方案中的一部分。
与一次交付一个最终产品相比，增量型生存期模型将经常优化为项目发起人或客户交付价值的工作。在开始工作之前，团队就计划了最初的可交付成果，他们还会尽快开始第一次交付的工作。某些敏捷项目在项目启动后几天内就开始交付价值，有的项目可能需要更长的时间，从一周到几周的时间不等。
增量模型的优点如下。
· 软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。
· 可以避免一次性投资太多带来的风险，首先实现主要的功能或者风险高的功能，然后逐步完善，保证投入的有效性。
· 可以更快地开发出可以操作的系统。
· 可以减少开发过程中用户需求的变更。
增量模型的缺点如下。
· 由于各个构件是逐渐并入已有软件体系结构中的，因此加入构件时不能破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
· 在开发过程中，需求的变化是不可避免的。增量模型的灵活性使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但一些增量可能需要重新开发，从而使软件过程的控制失去整体性（如果早期开发的需求不稳定或者不完整）。
增量模型的适用范围如下。
· 进行已有产品升级或新版本开发，增量模型是非常适合的。
· 对于完成期限要求严格的产品，可以使用增量模型。
· 对于所开发的领域比较熟悉而且已有原型系统，增量模型是非常适合的。
· 对于市场和用户把握不是很准、需要逐步了解的项目，可采用增量模型。
使用增量模型时，首先构建整个系统的核心部分，或者具有高风险的部分功能，这部分功能对项目的成功起到重要作用。通过测试这些功能决定它们是否是项目所需要的，这样可以排除后顾之忧，然后循序渐进地增加功能和性能，增加功能的时候应该高效而且符合用户的需要。
迭代模型用于应对产品内部因素的不确定性，尝试通过不同的想法澄清需求、范围、方法等，而且每个迭代结束后可以没有交付。增量模型用于应对外部因素的不确定性，基本掌握系统的需求和实现，采取逐步开发特性和功能的方式实现多次交付，如图3-9所示。
图3-9 迭代模型与增量模型的比较
敏捷型生存期模型通常指的是敏捷软件开发方法或框架，它是一种在软件开发中广泛使用的迭代和增量的开发方法。在敏捷模型中，软件开发被分解成小的、可管理的部分，每个部分都经过迭代开发，并在整个过程中灵活地应对变化。
敏捷型生存期模型是符合“敏捷宣言”原则的模型，客户满意度将随着有价值产品的早期交付和持续交付不断提升。此外，功能性的、提供价值的增量可交付成果是衡量进展的主要尺度。为了适应更频繁的变更、更频繁地交付项目价值，敏捷型生存期模型结合了迭代和增量方法。
在敏捷环境中，团队预料需求会发生变更。迭代和增量方法能够提供反馈，以便改善项目下一部分的计划。不过，在敏捷项目中，增量交付会发现隐藏或误解的需求。图3-10显示了实现增量交付的两种可能的方法（基于迭代和基于流程），这样将便于项目与客户需求保持一致，并根据需要进行调整。
基于迭代的敏捷方法，团队以迭代（相等持续时间的时间盒）形式交付完整的功能。团队集中于最重要的功能，作为一个团队合作完成其工作。然后，团队再集中于下一项最重要的功能，并合作完成其工作。团队可决定一次进行若干功能的开发工作，但团队不会同时完成所有的迭代工作。
基于流程的敏捷方法，团队将根据自身能力从待办事项列表中提取若干功能开始工作，而不是按照基于迭代的进度计划开始工作。团队定义任务板各列的工作流，并管理各列的进行中的工作（Work In Progress，WIP）。完成不同功能所花费的时间可能有所不同。团队让进行中的工作（WIP）的规模尽量小，以便尽早发现问题，并在需要变更时减少返工。无须利用迭代定义计划和审核点，而由团队和业务相关方决定规划、产品评审与回顾的最适当的进度计划。
图3-10 基于迭代和基于流程的敏捷型生存期模型
敏捷是许多方法的总称，其中包括很多敏捷开发管理实践，例如Scrum、XP（eXtreme Programming）、精益（lean）、FDD、持续交付、DevOps等。
Scrum是一个敏捷框架，由Scrum团队及其相关的角色、活动、工件和规则组成，如图3-11所示。在该框架中，可以应用各种流程和技术。Scrum基于经验主义，经验主义主张知识源于经验，而决策基于已知的事物。Scrum采用迭代增量式的方法优化可预测性和管理风险。一个迭代就是一个Sprint（冲刺），Sprint的周期被限制在一个月左右。Sprint是Scrum的核心，其产出是可用的潜在可发布的产品增量。Sprint的长度在整个开发过程中保持一致。新的Sprint在上一个Sprint完成之后立即开始。
如果Sprint周期过长，对“要构建什么东西”的定义就有可能会改变，复杂度和风险有可能也会增加。Sprint通过确保至少每月一次对达成目标的进度进行检视和调整来实现可预见性。Sprint也把风险限制在一个月的成本上。
Scrum有明确的更高目标，具有高度自主权，它的核心是迭代和增量，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝着目标明确地推进。
Scrum模型包括3-3-5-5的核心要素。
1.3个角色
Scrum团队由产品负责人、Scrum主管和开发团队组成。Scrum团队是跨职能的自组织团队。Scrum团队迭代增量式地交付产品，最大化获得反馈的机会。增量式地交付“完成”的产品保证了可工作产品的潜在可用版本总是存在。
· 产品负责人（PO）： 代表客户的意愿，从业务角度来说保证Scrum团队在做正确的事情。同时产品负责人代表项目的全体利益干系人，负责编写用户需求（用户故事），排出优先级，并放入产品订单（product backlog），从而使项目价值最大化。产品负责人利用产品订单，督促团队优先开发最具价值的功能，并在其基础上继续开发，将最具价值的开发需求安排在下一个Sprint迭代中完成。产品负责人对项目产出的软件系统负责，规划项目初始总体要求、ROI目标和发布计划，并为项目赢得驱动及后续资金。
图3-11 Scrum框架
· Scrum主管： 负责Scrum过程正确实施和利益最大化的人，确保它既符合企业文化，又能交付预期利益。Scrum主管的职责是向所有项目参与者讲授Scrum方法和正确的执行规则，确保所有项目相关人员遵守Scrum规则，这些规则形成了Scrum过程。
· 开发团队： 负责找出可在一个迭代中将冲刺订单（Sprint backlog）转化为功能增量的方法。他们对每一次迭代和整个项目共同负责，在每个Sprint中通过实行自管理、自组织和跨职能的开发协作，实现Sprint目标和最终交付产品，一般由5～9名具有跨职能技能的人（设计者、开发者等）组成。
2.3个工件
Scrum模型的工件以不同的方式表现工作的任务和价值。Scrum的工件用于最大化关键信息的透明度，因此每个人都需要有相同的理解。
（1）增量
增量是一个Sprint完成的所有产品待办列表项以及之前所有Sprint产生的增量价值的总和，它是在每个Sprint周期内完成的、可交付的产品功能增量。在Sprint的结尾，新的增量必须是“完成”的，这意味着它必须可用并且达到了Scrum团队“完成”的定义的标准。无论产品负责人是否决定真正发布它，增量必须可用。
（2）产品待办事项列表
产品待办事项列表也称产品订单（product backlog），是Scrum中的一个核心工件。产品待办事项列表是包含产品想法的一个有序列表，所有想法按照期待实现的顺序来排序。它是所有需求的唯一来源，这意味着开发团队的所有工作都来自产品待办事项列表。
最初，产品待办事项列表是一个长短不定的列表，可以是模糊的或是不具体的。通常情况下，在开始阶段，产品待办事项列表比较短小而模糊，随着时间的推移，它会逐渐变长且越来越明确。通过产品待办事项列表梳理活动，即将被实现的产品待办事项得到澄清，变得明确，粒度也拆得更小。产品负责人负责产品待办事项列表的维护，并保证其状态更新。产品待办事项可能来自产品负责人、团队成员或者其他利益干系人。
产品待办事项列表包含已划分优先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性需求及其他假设和约束条件。产品负责人和团队主要按业务和依赖性的重要程度划分优先等级，并做出估算。估算值的精确度取决于产品订单中条目的优先级和细致程度，入选下一个Sprint的最高优先等级条目的估算会非常精确。产品的需求清单是动态的，随着产品及其使用环境的变化而变化，并且只要产品存在，它就随之存在。而且，在整个产品生命周期中，管理层不断确定产品需求或对之做出改变，以保证产品的适用性、实用性和竞争性。
（3）Sprint待办事项列表
Sprint待办事项列表也称Sprint订单（Sprint backlog），是一个需要在当前Sprint完成的且梳理过的产品待办事项，包括产品订单中最高优先等级的条目。该列表反映团队对当前Sprint里需要完成工作的预测，定义团队在Sprint中的任务清单，这些任务会将当前Sprint选定的产品订单转化为完整的产品功能增量。Sprint订单在Sprint规划会议中形成，任务被分解为以h（小时）为单位。如果一个任务超过16h，那么它应该被进一步分解。每项任务信息包括其负责人及其在Sprint中任一天时的剩余工作量，且仅团队有权改变其内容。在每个Sprint迭代中，团队强调应用“整体团队协作”的最佳实践，保持可持续发展的工作节奏和每日站立会议。
有了Sprint待办事项列表后，Sprint即开始，开发团队成员按照Sprint待办事项列表来开发新的产品增量。
3.5个事件
Scrum的5个事件由Sprint计划会议、Sprint迭代开发、每日站立会议、Sprint评审会议和Sprint回顾会议组成。
（1）Sprint计划会议
Sprint计划会议的目的是为这个Sprint的工作制订计划。这份计划是由整个Scrum团队共同协作完成的。Sprint开始时均需召开Sprint计划会议，产品负责人和团队共同探讨该Sprint的工作内容。产品负责人从最优先的产品待办事项列表中进行筛选，告知团队其预期目标，团队则评估在接下来的Sprint内预期目标可实现的程度。Sprint计划会议一般不超过8h。在前4h中，产品负责人向团队展示最高优先级的产品，团队则向他询问产品订单的内容、目的、含义及意图，而在后4h进行本Sprint的具体安排。
Sprint计划会议最终产生Sprint待办事项列表，它为开发团队提供指引，使团队明确构建增量的目的。
（2）Sprint迭代开发
Scrum通过将整个软件交付过程分成多个迭代周期，帮助团队更好地应对变更，应对风险，实现增量交付、快速反馈。每个迭代开发过程中，通过关注保持整个团队可持续发展的工作节奏、每日站立会议和组织的工作分配，实现团队的高效协作，从而提高整个团队的生产力。
开发团队在每个Sprint都交付产品功能增量。这个增量是可用的，所以产品负责人可以选择立即发布它。每个增量都被添加到之前的所有增量上，并经过充分测试，以此保证所有的增量都能工作。通过进行更频繁的软件集成，实现更早地发现和反馈错误，降低风险，并使整个软件的交付过程变得更加可预测和可控，以交付更高质量的软件。
（3）每日站立会议
在Sprint开发中，每天举行的项目状况会议，称为每日站立会议。每日站立会议有如下指导原则。
· 会议准时开始：对于迟到者，团队常常会制定惩罚措施。
· 允许所有人参加。
· 不论团队规模大小，会议都被限制在15min内。
· 所有出席者都应站立（有助于保持会议简短）。
· 会议应在固定地点和每天的同一时间举行。
· 在会议上，每个团队成员需要回答3个问题：
〇 今天完成了哪些工作？
〇 明天打算做什么？
〇 完成目标是否存在障碍？
（4）Sprint评审会议
每个Sprint结束时，团队都会召开Sprint评审会议，团队成员会在会议上分别展示他们开发出的软件，得到反馈信息，并决定下一次Sprint的内容。
（5）Sprint回顾会议
每一个Sprint完成后，都会举行一次Sprint回顾会议，在会议上所有团队成员都要反思这个Sprint。举行Sprint回顾会议是为了进行持续过程改进。会议的时间限制在4h内。
产品待办事项通常会很大，也很宽泛，而且想法会变来变去，优先级也会变化，所以产品待办事项列表梳理是一个贯穿整个Scrum项目始终的活动。该活动包含但不限于以下内容。
· 保持产品待办事项列表有序。
· 把看起来不再重要的事项移除或者降级。
· 增加或提升涌现出来的或变得更重要的事项。
· 将事项分解成更小的事项。
· 将事项归并为更大的事项。
· 对事项进行估算。
产品待办事项列表梳理的最大好处是为即将到来的Sprint做准备，为此梳理时会特别关注那些即将被实现的事项。
4.5个价值观
5个价值观是勇气（courage）、开放（openness）、专注（focus）、承诺（commitment）、尊重（respect）。
· 勇气：我们不是单打独斗，我们能够感受到支持，而且掌握更多的资源。这一切赋予我们勇气去做正确的事情和迎接更大的挑战。
· 开放：在团队合作中，大家都会表达我们做得如何，以及遇到的障碍。大家与利益干系人一起将担忧的问题说出来是一件好事，因为只有这样才能及时解决这些问题。
· 专注：由于我们在一段时间内只专注于少数几件事，所以我们可以很好地合作并获得优质的产出。专注于Scrum团队的目标，我们能够更快地交付有价值的事项。
· 承诺：由于对自己的命运有更大的掌控，我们有更坚定的信念去获得成功。每个人都会全身心投入地去完成Scrum团队的目标。
· 尊重：大家在一起工作，分享成功和失败，这有助于培养并加深互相之间的尊重，并帮助彼此成为值得尊重的人，相信每个人都是独立的有能力的个体。
XP（极限编程）是由Kent Beck提出的一套针对业务需求和软件开发实践的规则，它的作用在于将二者的力量集中在共同的目标上，高效并稳妥地推进开发。XP力图在不断变化的客户需求的前提下，以持续的步调，提供高响应性的软件开发过程及高质量的软件产品，保持需求和开发的一致性。XP是一种注重软件工程实践和团队协作的敏捷方法。XP强调团队的沟通、简单设计、测试驱动开发（TDD）、重构和持续集成。XP还提倡在整个开发周期中频繁地进行小规模的发布。
XP提出的一系列实践旨在满足程序员高效的短期开发行为和项目长期利益的共同实现，这一系列实践长期以来被业界广泛认可，实施敏捷方法的公司通常会全面或者部分采用。
这些实践如图3-12所示，按照整体实践（entire practice）、开发团队实践（development team practice）、开发者实践（developer practice）3个层面，XP提供如下13个核心实践：整体实践包括统一团队（whole team）、策划游戏（planning game）、小型发布（small release）及客户验收（customer test）；开发团队实践包括代码集体所有（team code ownership）、编码标准（codingstandard）、恒定速率（sustainable pace，又名40h工作）、系统隐喻（system metaphor）、持续集成（continuous integration）；开发者实践包括简单设计（simple design）、结对编程（pair programming）、测试驱动开发（test driven development）、重构（refactoring）。具体介绍如下。
图3-12 XP最佳实践
1.统一团队
XP项目的所有贡献者坐在一起。这个团队必须包括一个业务代表—客户，他提供要求，设置优先事项。如果客户或他的助手之一是一个真正的最终用户，这样是最好的；该团队也包括程序员；可能包括测试人员，帮助客户定义客户验收测试；分析师可帮助客户确定要求；通常还有一个教练，帮助团队保持在正确的轨道上；可能有一个上层经理，提供资源，处理对外沟通，协调活动。一个XP团队中的每个人都可以以任何方式做出贡献。最好的团队，没有所谓的特殊人物。
2.策划游戏
在交付日期前可以完成多少工作？现在和下一步该做些什么？不断回答这两个问题，就是直接服务于如何实施及调整开发过程。与此相比，一开始就精确定义整个开发过程要做什么事情及每件事情要花多少时间，则事倍功半。针对这两个问题，XP中有两个主要的相应过程：发布计划（release planning）和迭代计划（iteration planning）。
3.小型发布
每个周期开发达成的需求是用户最需要的东西。在XP中，对于每个周期完成时发布的系统，用户都可以很容易地评估，或者已能够投入实际使用。这样，软件开发不再是看不见摸不着的东西，而具有实实在在的价值。XP要求频繁地发布软件，如果可能，应每天都发布新版本，而且在完成任何一个改动、整合或者新需求后，应该立即发布一个新版本。这些版本的一致性和可靠性靠验收测试和测试驱动开发来保证。
4.客户验收
客户对每个需求都定义了一些验收测试。通过运行验收测试，开发人员和客户可以知道开发出来的软件是否符合要求。XP开发人员把这些验收测试看得和单元测试一样重要。为了不浪费时间，最好能将这些测试过程自动化。
5.代码集体所有
在很多项目中，开发人员只维护自己的代码，而且不喜欢其他人修改自己的代码，因此即使有相应的比较详细的开发文档，但一个程序员很少甚至不太愿意去读其他程序员的代码；而且因为不清楚其他人的程序到底实现了什么功能，程序员一般也不敢随便改动其他人的代码。同时，程序员自己维护自己的代码，可能因为时间紧张或技术水平所限，某些问题一直不能被发现或得到解决。针对这一点，XP提倡大家共同拥有代码，每个人都有权利和义务阅读其他人编写的代码，发现和纠正错误，重整和优化代码。这样，这些代码不仅仅是由一两个人写的，而是由整个项目开发队伍共同完成的，代码中的错误会减少很多，重用性会最大限度地得到提高，代码质量会非常好。
6.编码标准
XP开发小组中的所有人都遵循一个统一的编程标准，因此，所有的代码看起来好像是一个人写的。有了统一的编程规范，每个程序员更加容易读懂其他人写的代码，这是实现集体代码所有的重要前提之一。
7.恒定速率
XP团队处于高效工作状态，并保持一个可以无限期持续下去的状态。大量的加班意味着原来的计划是不准确的，或者程序员不清楚自己到底什么时候能完成什么工作，而且开发管理人员和客户无法准确掌握开发速度，开发人员也因此非常疲劳，从而可能降低效率及质量。XP认为，如果出现大量的加班现象，开发管理人员应该和客户一起确定加班的原因，并及时调整项目计划、进度和资源。
8.系统隐喻
为了帮助每个人一致、清楚地理解要完成的客户需求、要开发的系统功能，XP开发小组用很多形象的比喻来描述系统或功能模块是怎样工作的。
9.持续集成
在很多项目中，往往很迟才能把各个模块整合在一起，在整合过程中，开发人员经常发现很多问题，但不能确定到底是谁的程序出了问题，而且只有整合完成后，开发人员才开始使用整个系统，然后马上交付给客户验收。即使这些系统能够通过最终验收测试，因为使用时间短，客户心里也没有多少把握。为了解决这些问题，XP提出，在整个项目过程中，应该频繁地、尽可能早地整合已经开发完的用户故事。每次整合，都要运行相应的单元测试和验收测试，保证软件符合客户和开发的要求。整合后，发布一个新的应用系统。这样，在整个项目开发过程中，几乎每隔一两天都会发布一个新系统，有时甚至会一天发布若干个版本。通过这个过程，客户能非常清楚地掌握已经完成的功能和开发进度，并基于这些情况与开发人员进行有效、及时的交流，以确保项目顺利完成。
10.简单设计
XP要求用最简单的方法实现每个小需求，前提是按照简单设计开发的软件必须通过测试。这些设计只要能满足系统和客户当下的需求即可，不需要任何多余的设计，而且所有这些设计都将在后续的开发过程中被不断地重整和优化。在XP中，没有传统开发模式中一次性的、针对所有需求的总体设计。在XP中，设计过程几乎一直贯穿整个项目开发：从制订项目的计划到制订每个开发周期的计划，到针对每个需求模块的简捷设计，再到设计的复核，以及不间断的设计重整和优化。整个设计过程是一个螺旋式的不断前进和发展的过程。从这个角度看，XP把设计做到了极致。
11.结对编程
在XP中，所有的代码都是由两个程序员在同一台机器上一起编写的，这保证了所有的代码、设计和单元测试至少被另一个人复核过，代码、设计和测试的质量因此得到提高。这样看起来是在浪费人力资源，但是各种研究表明这种工作方式极大地提高了工作效率。在项目开发中，每个人会不断地更换合作编程的伙伴，结对编程不但提高了软件质量，而且增强了程序员相互之间的知识交流和更新以及沟通和理解，这不但有利于个人，也有利于整个项目、开发团队和公司。从这一点看，结对编程不仅适用于XP，也适用于其他的软件开发方法。
12.测试驱动开发
在软件开发中，只有通过充分的测试才能获得充分的反馈。XP中提出的测试在其他软件开发方法中都可以见到，如功能测试、单元测试、系统测试和负荷测试等。与众不同的是，XP将测试结合到它独特的螺旋式增量型开发过程中，测试随着项目的进展而不断积累。另外，由于强调整个开发小组拥有代码，所以测试也是由大家共同维护的，即：任何人在往代码库中放入程序前，都应该运行一遍所有的测试；任何人如果发现了一个bug，都应该立即为这个bug增加一个测试，而不是等待编写那个程序的人来完成；任何人接手其他人的任务或者修改其他人的代码和设计，如果改动完以后能通过所有测试，就证明他的工作没有破坏原系统，这样测试才能真正起到帮助获得反馈的作用。而且，通过不断地优先编写和累积，测试应该可以覆盖全部的客户和开发需求，因此开发人员和客户可以得到尽可能充分的反馈。
13.重构
XP强调简单的设计，但简单的设计并不是没有设计的流水账式的程序，也不是没有结构、缺乏重用性的程序。开发人员虽然对每个用户故事都进行简单设计，但同时也在不断地对设计进行改进，这个过程叫作设计的重构。重构主要是努力减少程序和设计中重复出现的部分，提高程序和设计的可重用性。重构的概念并不是XP首创的，它已被提出了近30年，一直被认为是高质量代码的特点之一。但XP强调把重构做到极致，应随时随地、尽可能地进行重构，程序员需要不断地改进程序。每次改动后，都应运行测试程序，保证新系统仍然符合预定的要求。
总之，XP实施原则是：快速反馈，假设简单，包容变化。
OpenUP（Open Unified Process）是一种轻量级的、迭代的软件开发过程，它是一种开放的、灵活的、可扩展的过程框架。OpenUP是基于统一过程（Unified Process，UP）的一个变体，旨在提供一种更加灵活、可定制的软件开发方法，以适应不同项目的需求。以下是OpenUP的一些关键特征和原则。
· 轻量级：OpenUP强调简化过程，专注于最重要的任务和文档，以减少不必要的开销。这使得OpenUP适用于中小型项目，也使得它在大型企业环境中更容易实施。
· 迭代和增量：OpenUP采用迭代和增量的开发方法。每个迭代都产生一个可执行的、部分完整的系统，并在后续迭代中逐步添加新的功能和改进。
· 灵活性：OpenUP是一个可定制的过程框架，可以根据项目的特定需求进行调整。它提供了一个基本的框架，但允许团队选择和适应适合其特定情境的实践。
· 适应性：OpenUP鼓励团队根据实际项目需求进行自适应。它提供了一组最佳实践和指导原则，但允许团队根据项目的特定要求进行灵活调整。
· 协作和沟通：OpenUP强调团队成员之间的协作和沟通，包括开发人员、测试人员、项目经理和业务代表。持续的沟通有助于确保团队对项目目标的一致理解。
· 用例驱动：OpenUP使用用例来捕获系统的功能需求，并将其作为开发过程的中心。用例是对系统如何与外部实体（包括用户）进行交互的场景的描述。
· 风险导向：OpenUP强调在早期和持续的过程中关注项目风险，并采取相应的措施来管理和减轻这些风险。
OpenUP是一个面向敏捷团队的灵活框架，可以根据项目需求进行调整。它提供了一种平衡的方法，结合了统一过程的思想和敏捷开发的灵活性，以支持不同规模和性质的软件项目。
看板方法是一种基于视觉化的敏捷方法，强调在工作流程中使用看板来跟踪工作项的状态。看板方法不规定迭代的长度，而是强调持续交付，通过限制在工作流程中的工作项数量，确保高质量和高效率。
看板（kanban）一词来自日本，源于精益生产实践，大野耐一开发了看板并在1953年将其应用于丰田的主要制造厂。敏捷开发将其背后的可视化管理理念借鉴过来。看板可以让研发过程最大限度地可视化，同时解决团队沟通障碍（实践中发现也可以作为和上级沟通项目进展的重要信息）。通过看板，项目团队可以清楚地了解已经完成的、正在做的以及后续将要做的用户故事，如图3-13所示。
看板可以作为敏捷团队每天站会的讨论的核心，及时变更看板中各个用户故事的状态，通过看板，敏捷团队可以清楚地了解其他成员的工作状况及和自己相关工作的进展。在状态墙上，除了用户故事、bug之外，还会有一些诸如重构、搭建测试环境等不直接产生业务价值的任务，用不同颜色的卡片将这三类任务放到状态墙上统一管理。
图3-13 看板
Scrumban方法最初被设计为Scrum到看板之间的过渡方法。它是通过其自身衍生演变而成的另一种混合敏捷框架和方法，其中团队将Scrum作为框架，而将看板作为过程改进方法。
在Scrumban方法中，工作被分解到许多小的“冲刺”，并利用看板面板来可视化和监督工作。将故事列在看板面板上，团队通过使用在制品限制（WIP limit）来管理其工作。通过召开每日例会来维持团队之间的协作并消除阻碍。团队通过设置规划触发因素来了解何时规划下一步的工作，通常发生于在制品级别低于预设限制时。
精益（lean）软件开发借鉴了制造业中的精益生产原则，强调减少浪费、快速响应变化和持续学习。在软件开发中，精益强调通过最小化流程浪费，实现更高的价值交付。
精益软件开发模式从一开始便侧重于提高过程中的效率。它最初来自丰田公司的制造工业，其主要思想是分析所有的流程，以查明和消除浪费，不断提高效率。为了达到这个目的，精益模式提出了一些概念和实用的工具，其中大部分工具都在制造业中使用而不能直接应用于软件开发。但是精益软件开发会经常提及其中的两个概念，即拉式系统（pull system）和价值流图（value stream mapping）。在拉式系统中，一个流水线上任何一个环节的任务完成后，都会从前一个环节自动提取下一个任务。该模式以客户的需求而不是市场预测来推动工作进程。另外，通过精益模式可以最小化未完成工作以及半成品的数量，它们通常被认为是开发过程中的浪费。价值流图也经常被应用于软件开发过程，价值流图能够有效识别过程中的浪费。
对于软件开发而言，从开发者或者最终用户的视角观察软件开发过程，并发现和消除不利于快速交付的行为，即为精益的软件开发。
持续交付是经典的敏捷软件开发方法（例如XP、Scrum）的自然延伸，以往的敏捷方法并没有过多关注开发测试前后的活动，例如前期的需求分析、产品的用户体验设计、产品的部署、运行和维护等。伴随着敏捷思想和原则在前后端领域的运用和升华，我们在持续交付这个新的大概念下看到了敏捷方法与更多实践活动的结合和更大范围的应用。
持续交付所描述的软件开发，是从原始需求识别到将最终产品部署到生产环境的过程中，需求以小批量形式在团队的各个角色间顺畅流动，能够以较短的周期完成需求的小粒度频繁交付。频繁的交付周期带来了对软件更迅速的反馈，并且在这个过程中，需求分析、产品的用户体验和交互设计、开发、测试、运维等角色密切协作。持续交付也需要持续集成、持续部署的支持。持续集成是指个人代码向软件整体部分交付，以便尽早发现个人开发部分的问题；持续部署是指集成的代码尽快向可运行环境交付，以便尽早测试；持续交付是指尽快向客户交付，以便尽早发现生产环境中存在的问题。
持续交付的前提是持续部署，持续部署和持续交付之间的区别在于：很多时候我们可以选择将有些功能部署到生产环境中，接受大量真实用户的非直接测试，或者有时候希望把一些小的功能组合起来一起展现给用户，因此，部署可以很频繁；然而可能根据计划实际交付给用户使用，交付的频率比部署的频率低。要实现产品的持续部署，还需要有自动化构建流水线（build pipeline）。以自动化生产线为例，自动化测试只是其中一道质量保证工序，而要将产品从原料（需求）转变为最终交付给客户的产品，自动化的生产线是中枢一般的存在。特别对于软件产品，多个产品往往要集成在一起才能为客户提供服务。多个产品的自动化构建流水线的设计也就成为一个很重要的问题。
产品在从需求到部署的过程中，会经历若干种不同的环境，例如QA环境、各种自动化测试运行环境、生产环境等。这些环境的搭建、配置、管理，以及产品在不同环境中的具体部署，都需要完善的工具支持。缺乏这些工具，生产流水线就不可能做到完全自动化和高效。
DevOps（Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合，如图3-14所示。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作，由持续交付演变出了DevOps，即开发端和运营端的全程敏捷思维。传统运营人员和开发者之间的目标是有差异的，开发和运营原本有着不同的目标，开发人员希望快速提交产品，运营人员希望产品的更合理化、高性能、高可靠等，减少维护成本，开发者和运营人员之间目的上的差异就叫作混乱之墙。
图3-14 DevOps模型
可以把DevOps看作开发、技术运营和质量保障三者的交集，传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。如何在这种环境下采用新的开发方法（例如敏捷软件开发）是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而需要极其紧密的多部门协作。然而DevOps考虑的还不只是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。
DevOps的引入能对产品交付、测试、功能开发和维护起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息鸿沟，例如，运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。DevOps融合了一系列基本原则和实践的方法论，将开发端和运营端融合在一起。
1.Scrum of Scrums
Scrum of Scrums（SoS）也称为meta Scrum，是由两个或多个Scrum团队而不是一个大型Scrum团队所使用的一种技术（如图3-15所示），其中一个团队包含3～9名成员来协调其工作。每个团队的代表会与其他团队代表定期召开会议，可能是每日例会，但通常是一周两次或三次。每日例会的执行方式类似于Scrum的每日站会，其中代表将报告已完成的工作、下一步工作设置、任何当前障碍以及可能会阻碍其他团队的潜在未来障碍。其目标是确保团队协调工作并清除障碍，以优化所有团队的效率。具有多个团队的大型团队可能要求执行Scrum of Scrum of Scrums，其遵循的模式与SoS相同，每个SoS代表向更大组织的代表报告。
图3-15 Scrum of Scrums模型
2.SAFe
SAFe（Scaled Agile Framework）是一种用于规模化敏捷开发的框架，可以帮助组织在大型项目或企业级环境中实现敏捷方法，并有效地管理复杂性。SAFe的核心理念是将敏捷原则和实践扩展到组织的整个规模，从而实现高效、协调和可持续的软件交付。它结合了敏捷开发、系统思维、精益方法和产品开发流程，以建立一个能够适应需求的不断变化的灵活组织。SAFe提供了一套明确的原则和实践，帮助组织管理规模化敏捷开发。
3.LeSS
LeSS（Large-Scale Scrum）是一种规模化的敏捷开发框架，可以帮助大型组织更好地应对复杂的产品开发。LeSS是Scrum的变体，专注于多个团队合作，以交付一个共同的产品。LeSS建立在Scrum的基础上，保留了Scrum的核心框架，包括角色（Product Owner、Scrum master、团队成员）、事件（Sprint、Review、Retrospective等）和工件（Product Backlog、Sprint Backlog等）。LeSS提供了一种灵活的方法，使大型组织能够更好地在敏捷的框架下工作。它强调的原则包括透明度、检查和适应，以确保组织能够快速、灵活地适应变化。LeSS的目标是帮助组织实现更高效、更灵活的产品开发。
对于整个项目，可能采用多个模型。为达到特定的目标，项目经常要结合不同的生存期模型。预测、迭代、增量和/或敏捷方法的组合就是一种混合方法。
图3-16描述了先敏捷后预测型结合方法，两者结合起来就形成一种混合模型。早期过程采用了敏捷开发生命周期，之后是预测型的发布阶段。当项目可以从敏捷方法中受益并且项目的开发部分存在不确定性、复杂性和风险时，可以使用这种方法，然后是一个明确的、可重复的发布阶段，该阶段适合采用预测方法进行，可能由不同的团队实施。例如，开发某种新的高科技产品，然后面向成千上万的用户推出，并对他们进行培训。
图3-16 先敏捷后预测型结合方法
在同一项目整个生命周期中结合使用敏捷方法和预测法，图3-17描述了同时使用敏捷和预测的方法。也许团队正在逐渐向敏捷过渡，并使用一些方法，如短迭代、每日站会和回顾，但在项目的其他方面，如前期评估、工作分配和进度跟踪等，仍然遵循了预测法。
图3-17 敏捷和预测综合的方法
同时使用预测方法和敏捷方法是一个常见的情况。将这种方法称为敏捷方法是一种误导，因为它显然没有充分体现敏捷的思维模式、价值观和原则。不过，由于这是一种混合方法，所以称其为预测方法也是不准确的。
如图3-18所示，在一个以预测方法为主的项目中增加敏捷要素。在这种情况下，用敏捷方法处理具有不确定性或者复杂性或者可能存在范围蔓延的部分，而使用预测方法管理项目的其余部分。
图3-18 以预测方法为主、敏捷方法为辅的方法
图3-19描述了一个以敏捷方法为主、预测方法为辅的方法。当某个特定要素不可协商，或者使用敏捷方法不可执行时，可能会使用这种方法。例如，集成由不同供应商开发的外部组件，这些外部组件不能或不会以协作或增量方式合作。在组件交付之后，需要单独集成。
图3-19 以敏捷方法为主、预测方法为辅的方法
AI在软件项目中的应用带来了许多新的挑战和机会，软件项目模型和开发流程需要适应这些变化，例如，在需求分析阶段，可以利用自然语言处理技术从大量文档中提取和理解用户需求，帮助项目团队更准确地把握项目目标。在编码和测试阶段，智能编码助手和自动化测试工具可以大幅度提高开发效率和代码质量。
由于软件有着天生的数字化特性，软件工程尤其适合借助AIGC的力量。具体的工程任务在某种程度上可能是重复性的，因此，非常适合由训练有素的AI模型提供帮助。其次，复杂的算法代码结构适合由AI助手生成。因此，对于训练有素的AI模型来说，如果代码模块可用，生成整个函数或类也就变得可行了。AIGC是增强人类能力和加速软件开发的有力工具。因此，AI驱动下的软件项目流程可被大大简化，项目模型也会随之发生变化。
在瀑布模型的基础上，结合AI驱动的软件开发，可以采用以下方法来优化软件项目管理过程。
1）需求管理的自动化。
· 使用自然语言处理（NLP）技术来自动分析和提取项目需求，这可以提高需求收集的效率，减少人为错误。
· AI可以辅助生成需求规约说明书，通过分析用户故事和业务场景来生成更精确的需求描述。
2）设计阶段的智能化。
· AI可以辅助系统设计，通过分析历史项目数据和设计模式来推荐最佳的架构和组件选择。
· 使用机器学习算法来预测系统性能，帮助设计更优化的系统架构。
3）编码阶段的自动化。
· AI可以辅助代码生成，通过理解设计文档和需求规约来自动生成代码片段或整个模块。
· 使用代码生成工具来提高编码效率，减少手动编写代码的时间。
4）测试阶段的智能化。
· AI驱动的测试工具可以自动生成测试用例，基于代码和需求文档来预测可能的测试场景。
· 使用机器学习来分析测试结果，快速识别和定位软件缺陷。
5）部署和维护的自动化。
· AI可以监控系统性能，预测潜在问题，并在问题发生前自动采取措施进行修复。
· 自动化部署流程，减少人为错误，确保系统部署的一致性和可靠性。
6）持续学习和优化。
· 在项目生命周期的每个阶段，AI都可以从数据中学习，不断优化开发流程和产品质量。
· 利用AI分析用户反馈和系统日志，以指导未来的迭代和改进。
7）风险管理的增强。
· AI可以帮助识别项目风险，通过分析历史数据和当前项目状态来预测潜在的障碍和挑战。
· 提供实时的风险评估和缓解策略，帮助项目团队做出更明智的决策。
8）文档和知识管理。
· AI可以自动整理和更新项目文档，确保所有团队成员都能访问到最新的信息。
· 使用知识图谱来管理项目知识，帮助团队成员快速找到相关信息。
在AI驱动的瀑布模型中，虽然项目仍然遵循瀑布模型的顺序性，但AI技术的应用使得每个阶段更加高效和智能。这种结合可以提高项目的整体质量和交付速度，同时降低风险和成本。
经典的敏捷软件开发生命周期（SDLC）以较小的、可操作的、迭代的和增量的周期启动并进行演化，直到代码被完全开发、测试并部署到生产环境中。同样，分析、设计、编码和测试也被分成较小的块来执行，而DevOps则在整个过程中持续进行。敏捷分析阶段一般会包括用户故事和史诗（Epic）的编写，而设计阶段则会引入架构图的创建和数据结构的设计。编码和测试阶段通常包括用不同的语言编写软件和制作测试用例，以确保它们按照特定要求运行。测试和QA还可能包括独立测试，以确保一切按预期运行。同样，DevOps也采用不同的方法，如环境配置、基础设施即代码和CI/CD流水线，如图3-20所示。
图3-20 经典的敏捷SDLC
AI可以协助敏捷SDLC的每个阶段，缩短整个敏捷SDLC的反馈环路（如图3-21所示），使企业能够更快地推出产品。企业通过在敏捷SDLC中使用人工智能驱动的工具来提高竞争优势。OpenAI开发的ChatGPT等工具可以帮助进行市场调研和趋势分析。AI可以分析客户偏好，并通过简单的文本提示帮助编写用户故事。从技术角度来看，它们还可以在产品发布前自动执行CI/CD流程、环境脚本、安全测试和性能测试。GPT-4还能帮助开发人员生成功能代码、进行自动化测试。此外，还可以创建数据模型、DDL和序列图。因此，人工智能在整个SDLC中的累积效应可使综合效率提高30%～50%。
图3-21 AI的敏捷SDLC
GitHub Copilot、AWS CodeWhisperer、华为CodeArts Snap等AI工具可在集成开发环境中自动完成大型代码块并检查代码质量，从而提高开发人员的工作效率。GitHub和微软的一项研究表明，当开发人员使用Copilot提供代码帮助时，开发人员的效率提升超过55%。从历史的角度来看，这是生产率的显著提高，超过了19世纪中期蒸汽机的引入，当时蒸汽机“仅”将大型工厂的生产率提高了15%。
同时，AI驱动下项目模型的管理也可以发生变化，例如对于AI驱动的Scrum模型，可以在产品Backlog管理、迭代计划会议、迭代开发进度、迭代开发工作质量评估、迭代过程数据分析方面，提高模型的效率，如图3-22所示。
图3-22 AI驱动的Scrum模型
以下是在AI驱动下的软件项目模型或开发流程的一些关键考虑因素。
· 数据驱动的开发：AI项目通常依赖于大量的数据进行训练和学习。因此，开发流程需要着重考虑数据的收集、清理和预处理。数据质量对于AI模型的性能至关重要。
· 迭代开发和快速实验：由于AI模型的特性，采用迭代和快速实验的方法对模型进行不断调优是关键。这要求开发流程具有灵活性，能够快速适应新的数据和反馈。
· 模型选择和集成：在AI项目中，需要仔细选择合适的算法和模型架构。同时，将这些模型集成到整个软件系统中也是一项复杂的任务，因为AI模型的输出可能会影响整个系统的行为。
· 自动化和持续集成：由于AI项目的复杂性，自动化测试、部署和持续集成是至关重要的。这可以确保在不断变化的代码和模型中保持系统的稳定性。
· 可解释性和透明度：AI模型的决策过程通常是黑盒的，这就需要考虑模型的可解释性和透明度。在一些领域，如医疗和金融领域，解释模型的决策过程是法规要求的。
· 安全性和隐私保护：AI项目需要特别关注安全性和隐私保护。开发流程应该包括对敏感信息的处理、模型的防御性设计以及对抗性攻击的考虑。
· 监控和维护：AI模型的性能可能随时间变化，因此需要建立监控机制来检测模型退化或失效的迹象。维护AI模型也是一个重要的方面，包括模型的更新和迁移学习等。
· 跨学科团队协作：AI项目通常需要跨学科团队的合作，包括数据科学家、开发人员、领域专家等。项目流程应该鼓励这些团队成员之间的有效沟通和协作。
本项目采用Scrum敏捷生存期模型，产品目录及优先级如表3-2所示，整个项目分4个迭代，即4个Sprint（冲刺迭代），表3-2也说明了每个Sprint包括的需求内容，第一个Sprint包括产品目录中前4优先级内容。每个冲刺订单（迭代）的周期大概是4周，每个冲刺订单完成之后提交一个可以运行的版本。因此，本项目的Scrum敏捷模式可以通过图3-23展示。具体生存期定义如图3-24所示。
表3-2 产品目录及优先级
图3-23 Scrum生存期模型
图3-24 项目生存期示意图
生存期中的各阶段定义如下。
1.需求分析阶段
阶段目标：确定需求的功能和服务。
进入条件：用户提出初始需求。
输入：演示系统。
输出：关键特性表（Key Feature List，KFL）、业务过程定义（business process definition）、需求定义文档。
完成标志：输出通过用户确认。
2.系统设计阶段
阶段目标：根据已有的系统结构确定应用逻辑结构、数据库结构和页面结构。
进入条件：提交需求分析初步结果。
输入：关键特性表、商务过程定义文档、需求定义文档。
输出：系统设计报告、Data Model和数据库、页面流（page flow）。
完成标志：设计通过专家的对等评审。
3.项目规划阶段
阶段目标：根据需求分析和系统设计结果确定本阶段的时间计划、资源需求和资金预算。
进入条件：提交需求分析初步结果。
输入：需求定义文档、系统设计文档。
输出：项目计划。
完成标志：项目计划经合同管理者审批。
4.迭代 n 设计
阶段目标：设计与迭代 n 相关的页面、应用逻辑。
进入条件：设计通过专家的对等评审。
输入：系统设计文件、数据库结构定义。
输出：详细设计报告。
完成标志：设计通过对等评审。
5.迭代 n 开发
阶段目标：实现迭代 n 。
进入条件：设计通过专家的对等评审。
输入：详细设计报告。
输出：程序包。
完成标志：迭代 n 与网站系统集成调试完毕。
6.集成测试
阶段目标：通过集成环境下的软件测试。
进入条件：迭代 n 与网站系统集成调试完毕。
输入：网站系统和迭代 n 功能包、QA数据库、测试案例。
输出：测试报告。
完成标志：测试报告通过审核。
7.确认测试
阶段目标：通过QA环境下的确认测试。
进入条件：集成测试完毕，WDB可以转入QA DB。
输入：网站系统软件包、QA数据库、测试案例。
输出：测试报告。
完成标志：测试报告通过审核。
8.产品提交
阶段目标：系统投入使用。
进入条件：测试报告通过审核。
输入：网站系统软件包。
输出：CD。
完成标志：用户完成产品接收。
根据项目的特点，团队选择了图3-25所示的多迭代增量开发模型作为项目的生存期模型，理由如下。
· 需求不够清晰：项目初期对需求的理解不够透彻，需要逐步了解。因为涉及众多异源异质异构的数据请求，采用迭代模型可以在每个迭代中逐步引入新的数据来源，以确保系统适应性强。而且在多源数据管理系统中，需求可能随时间变化，采用迭代模型能够更灵活地应对这些变化。
· 快速响应变化：在增量开发过程中，每个增量迭代都提供了评估和调整方向的机会，使团队能够及时响应客户需求和市场变化。每个迭代可以根据新需求进行调整。
· 持续交付价值：每个增量结束时，都会产出可工作的软件，而且是按照用户需求价值优先级交付，这有助于确保项目的早期交付，并在每次迭代中不断完善系统。每个迭代都能够实现一个可用的部分系统，这样在项目早期就能够交付一些功能完备的模块，有助于及早验证系统的可行性。
图3-25的模型说明可以在开发过程中逐步完善功能，将用户需求按照优先级形成多个开发增量，每个增量可以有多个迭代，每个增量完成后有用户参与的阶段评价，根据反馈做必要的调整完善，形成交付的可运行系统。
图3-25 MSHD项目生存期模型
本章介绍了软件项目生存期模型的类型和特点，总体分为预测型模型和适应型模型，适应型可以是迭代型、增量型、敏捷型，混合型生存期模型是预测型和适应型的组合。瀑布模型、V模型属于预测型模型，快速原型模型属于迭代型模型，渐进式阶段模型也属于增量模型，特别展开介绍了Scrum、XP、看板方法、精益模型、持续交付、DevOps等敏捷模型以及规模化敏捷模型。另外也探讨了AI驱动项目的生存期模型。
一、填空题
1. __________生存期模型中，要求项目所有的活动都严格按照顺序执行，一个阶段的输出是下一个阶段的输入。
2. 总体上，项目生命周期可以是预测型或__________。
3. DevOps是__________和__________的组合。
二、判断题
1. 瀑布模型不适合短期项目。（ ）
2. 增量式模型可以避免一次性投资太多带来的风险。（ ）
3. V模型适合的项目类型是需求很明确、解决方案很明确而且对系统的性能要求比较严格的项目。（ ）
4. 瀑布模型和V模型都属于预测模型。（ ）
5. 在瀑布生存期模型中，要求项目所有的活动都严格按照顺序执行，一个阶段的输出是下一个阶段的输入。（ ）
6. 极限编程（eXtreme Programming）从三个层面提供了13个敏捷实践。（ ）
7. 敏捷包括了《敏捷宣言》中的4个核心价值、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.SAFe
B.Scrum
C.Scrum of Scrums（SOS）
D.LeSS
四、问答题
1. 写出三种你熟悉的生存期模型，并说明这些模型适用什么情况下的项目。
2. 举例说明什么是混合模型？