2022年5月29日

软件过程与管理

一、概论

软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据

软件工程

①将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即工程化应用到软件上；

②对①中所述方法的研究

1. 软件工程的三要素

• 过程：支持软件生命周期的所有活动

• 方法：为软件开发过程提供“如何做”的技术

• 工具：为软件开发方法提供自动的或半自动的软件支撑环境

2. 软件过程的定义

软件过程是用于软件开发及维护的一系列活动、方法及实践。

3. 常见的软件过程分类

• 客户-供应商过程

• 工程过程：软件系统、产品的定义、设计、实现以及维护的过程。

• 支持过程

• 组织过程

• 管理过程：在整个软件生命周期中为工程过程、支持过程和客户-供应商过程的实践活动提供指导、跟踪和监控的过程。

  项目管理过程是计划、跟踪和协调项目执行及生产所需资源的管理过程。

  质量管理过程是对项目产品和服务的质量加以管理，从而获得最大的客户满意度。

  风险管理过程，在整个项目的生命周期中对风险不断的识别、诊断和分析，回避风险、降低风险或消除风险，并在项目以及组织层次上建立有效的风险管理机制。

  子合同商管理过程，选择合格的子合同商并对其进行管理的过程。

二、软件质量管理

1. 软件质量的定义

软件质量是软件产品满足明确或隐含需要能力的性能和特性的总体。

（用户需求是衡量软件质量的基础。 除满足明确定义的需求外，还要满足隐含的需求。）

2. ISO/IEC 25010:2023 软件质量模型

该标准定义了九个一级质量特性，用于全面评估软件产品的内在质量和外部质量。每个一级特性下包含若干二级特性，要求理解一级特性的含义及其细分。

一级质量特性及含义：

1. 功能适用性（Functional Suitability）

   • 产品在规定条件下使用时，提供满足预定用户明示和暗示需求功能的能力。

   • 二级特性：功能完整性、功能正确性、功能适合性。

2. 性能效率（Performance Efficiency）

   • 产品在规定的时间和吞吐量参数内执行其功能的能力，以及在规定条件下有效利用资源的能力。

   • 二级特性：时间特性、资源利用率、容量。

3. 兼容性（Compatibility）

   • 产品与其他产品交换信息、在共享相同环境和资源的情况下，执行其所需功能的兼容性。

   • 二级特性：共存性、互操作性。

4. 交互能力（Usability）

   • 用户与系统之间通过用户界面交换信息以完成预定任务的能力。

   • 二级特性：可辨识性、易学性、易操作性、用户差错防御性、用户粘性、包容性、用户支持、自描述性。

5. 可靠性（Reliability）

   • 产品在规定的条件下，在规定的时间内执行规定功能而不发生中断和故障的能力。

   • 二级特性：无故障、可用性、容错性、易恢复性。

6. 安全性（Security）

   • 产品保护信息和数据的能力，使个人或其他产品拥有与其授权类型和级别相适应的数据访问权限，并抵御恶意行为者的攻击模式，强调信息安全。

   • 二级特性：保密性、完整性、抗抵赖性、可核查性、真实性、耐受性。

7. 可维护性（Maintainability）

   • 产品由预定维护者进行有效和高效修改的能力，即变通性。

   • 二级特性：模块化、可重复使用性、可分析性、可修改性、可测试性。

8. 灵活性（Portability）

   • 产品适应需求、使用环境或系统环境变化的能力。

   • 二级特性：适应性、可拓展性、可安装性、可替换性。

9. 安全（Safety）

   • 产品在规定条件下避免危及人的生命、健康、财产或环境的能力，强调系统安全。

   • 二级特性：运行限制、风险识别、故障安全、危险警告、安全集成。

3. 朱兰质量管理三部曲

• 质量计划：确定项目应达到的质量标准，以及如何满足质量标准的计划安排和方法。

• 质量保证：确保项目达到有关标准，而开展的有计划、有组织的工作活动。（方法：质量审计/质量改进）

• 质量控制：确定项目结果与质量标准是否相符，并及时纠正产品缺陷的过程。（静态方法：评审，动态方法：测试）

三、软件项目管理

1. 基本概念

• 项目：为完成某一独特的产品、服务或成果所做的一次性努力

• 项目管理：在项目活动中运用相关知识、技能、工具和技术满足项目的要求

• 五大过程组：启动、计划、执行、控制、收尾

• 十大知识领域：项目 集成/范围/时间/成本/质量/人力资源/沟通/风险/采购/利益相关者）管理

2. 可行性分析：净现值（NPV）的优点

使得净现值为0的贴现率称之为内部回报率。

（传统评价指标的局限性：

• 净利润、回收期、投资回报率等指标存在以下不足：

  • 忽视了资金时间价值

  • 忽略了成本与收益规模

  • 未充分考虑现金流入与流出的时间分布及利率影响

  • 没考虑现金的时限；没考虑利率和利息。）

净现值（NPV）的定义： （NPV = 未来现金流入现值总和 − 未来现金流出现值总和）

利用贴现率（r）将未来第 t 年的现金流折算为现值

净现值=第t年的值/（1+r）t

当第t年的值为1.0时，净现值=贴现因子

NPV 的优点：

贴现现金流考虑到了现金的支出和收益的时间；同时也考虑到了在不同时刻同一数额的现金的实际价值不一样，将各个时间的现金都折合到同一时间点的净现值来处理。

1. 考虑了资金的时间价值

   • 提高了投资方案评价的科学性与经济性。

2. 考虑了全过程的净现金流量

   • 兼顾流动性与长期收益，体现整体投资效果。

3. 引入风险调整机制

   • 风险大则采用高贴现率，风险小则采用低贴现率。

3. 识别软件项目的活动：WBS（工作分解结构）(Work Breakdown Structure)

WBS是面向可交付成果的对项目任务的分组,它组织并定义了整个项目范围。它是一个分级的树型结构，是对项目由粗到细的分解过程。

结构特点：

• 中间节点（功能/子系统）：表示较高层次的任务或功能模块

• 叶子节点（子功能/具体任务）：代表最小的、不可再分的工作单元，构成项目的活动集合

• WBS可以随着项目的进展而细化

• 层次的深度（一般3-5层）

只有最底层的叶子节点才作为可执行的具体活动，用于后续的进度安排、资源分配与成本估算。

4. 软件工作量估计方法：常见的软件工作量估计方法

• 专家判断：（依赖具有丰富经验的专家来估计工作量，尤其适用于对已有软件进行变更时。专家判断通常结合了已标识的过去类似项目的经验，可能结合类比法和自底向上估计法。）

• 类比估计：（描述实例特征，选取合适的相似度、相异度的表达式，评价相似程度，用相似的项目数据得到最终估算值。不能使用于早期规模不确定的情况，一般在已经有经验的狭窄领域，难于适应新项目中约束条件、技术、人员等发生重大变化的情况）

• 自底向上估计：（从项目的最小工作单元开始逐步累积，估算每个任务或子任务的工作量，最后汇总得出整体估计。）

• 自顶向下估计：（从整体项目范围开始，逐渐向下细化，依据项目的整体目标和框架做出工作量估算。）

• Albrecht功能点：（基于用户视角，通过计数系统五大功能类型（EI、EO、EQ、ILF、EIF）量化软件规模，适用于传统事务型系统。）

• Mark 功能点：（改进版功能点方法，以逻辑事务和数据实体为核心，更灵活适应复杂业务逻辑，尤其适合实时和嵌入式系统。）

• COSMIC全功能点：（面向现代软件架构，以数据移动为基本单位，支持功能规模标准化跨领域度量。

• COCOMO II:参数化的生产率模型：（基于历史项目数据和参数，通过数学公式估算开发成本与工期，适用于预测型项目管理。）

IFPUG 功能点方法：五大类功能

在 IFPUG功能点方法 中，信息系统的工作量估算基于五大类功能点：

• 外部输入（EI）：用于更新系统内部文件的输入事件。

• 外部输出（EO）：从系统内部文件中提取并加工数据的输出事务，通常需要计算、汇总或格式化后展示。

• 外部查询（EQ）：用户发起的查询事务，仅检索信息且不修改任何内部数据。用户输入条件后，系统返回匹配结果。

• 内部逻辑文件（ILF）：系统内部维护的逻辑数据组，等同于系统分析中的“数据存储”。由目标系统创建和管理。

• 外部接口文件（EIF）：从其他系统维护的数据存储中检索的数据组，目标系统仅读取但无权修改。

5. 软件项目的进度安排

软件项目的进度安排涉及多个方法，包括甘特图、关键路径法（CPM）、关键链法（CCM）和 PERT 技术。掌握这些方法有助于合理规划项目进度与资源，提高项目管理效率。

1. 甘特图（Gantt Chart）

   • 图形化表示项目各任务的时间安排。

   • 优点：直观展示任务的开始和结束时间。

   • 缺点：无法表示任务之间的逻辑依赖关系。

2. 关键路径法（Critical Path Method，CPM）

   • 用于确定完成项目所需的最短时间路径，即关键路径。

   • 关键路径：由项目中耗时最长的活动组成，决定了项目的总工期。

   • 关键活动：关键路径上的各个活动，一旦延误将直接影响项目完成时间。

   • 空闲缓冲期：一个活动最早的完成日期与后续活动最早的开始日期之间的差。

     干预缓冲期：总缓冲期与空闲缓冲期的差。

3. 关键链法（Critical Chain Method，CCM）

   • 关键链：既考虑项目活动的紧前关系，又考虑资源冲突，构建网络图，得到的最长路径。

   • 缓冲区设置：

     • 项目缓冲：添加在关键链尾部，用于防止整个项目延期。

     • 汇入缓冲：添加在非关键链与关键链交汇处，避免关键链被前置任务拖延。

   • 步骤：

     1. 确定紧前关系，找出关键路径。

     2. 加入资源限制，得到关键链。

     3. 设置项目缓冲和汇入缓冲。

     4. 按任务时长砍掉一半计算缓冲大小。

         

4. PERT 技术（Program Evaluation and Review Technique）

   • 考虑到了进度管理中的风险，将不确定性引入到了进度管理中。

   • 优点： 活动的标准差是风险的一种度量 可以估计项目事件完成日期的概率

   • 通过三种估计时间计算任务的期望时间和标准偏差：

     • 最可能的时间（Most Likely Time, m）

     • 乐观的时间（Optimistic Time, a）

     • 悲观的时间（Pessimistic Time, b）

   • 期望周期：t= (a + 4m + b) / 6

   • 标准偏差：s = (b - a) / 6

   •  

   • 步骤：

     1. 为每个任务估算三种时间并计算期望时间与标准差。

     2. 正向遍历得到期望达到事件的日期。

     3. 评估满足目标的可能性。

        计算每个项目事件的标准偏差

        计算有目标日期的每个事件的z值

        转化z值为概率（超过目标日期的概率）

        每条路径的标准偏差为路径上所有活动的标准偏差的平方和的开根号，事件的标准偏差为到达其路径的标准偏差中的最大值

        z=（T（目标日期）-t（期望周期））/s

6. 软件项目的资源管理

• 资源定义：资源是执行项目所需要的任何项和人。

• 资源直方图：通过延迟某些活动的开始日期，实现资源的负载均衡，确保在整个项目期间资源的合理分配，来平衡化资源直方图。

7. 软件项目的风险管理：

风险的定义，风险管理的框架，风险处理的方法

• 风险的定义：一个不确定的事件或者情况，若其一旦发生，会对项目的目标，例如，范围、进度、成本和质量，产生积极或消极的影响。

• 风险的三要素：事件、事件发生的概率、事件的影响

• 风险管理的框架：

  1. 风险识别

  2. 风险分析与优先级排序

  3. 风险策划

  4. 风险监督

• 风险处理的方法：

  1. 接受风险

  2. 规避风险

  3. 降低风险

  4. 转移风险

• 风险的分类：

  1. 参与者风险

  2. 技术风险

  3. 结构风险

  4. 任务风险

     （风险的基本性质：

     1. 风险的客观性

     2. 风险的不确定性

     3. 风险的不利性

     4. 风险的可变性

     5. 风险的相对性

     6. 风险同利益的对称性）

8. 软件项目的监督与控制：挣值分析

挣值分析赋予每个任务“挣值”(钱或时间)，将任务与成本捆绑在一起

三个数值，两个偏差，两个性能比，两个预测

指标	解释	公式	示例值
计划价值 (PV)	已计划工作的预测成本	计划进度*活动挣值	200 × 5 = 1000
挣值 (EV)	已执行工作的预测成本	以完成进度*活动挣值	200 × 3.5 = 700
实际成本 (AC)	已执行工作的实际成本	当前实际支出	1000
进度偏差 (SV)	已完成工作值与计划的工作值的差	EV - PV	700 - 1000 = -300
成本偏差 (CV)	已完成工作的预算成本和实际成本的偏差	EV - AC	700 - 1000 = -300
进度性能指标 (SPI)	进度性能的指标，反映项目是否按计划进度进行	EV / PV	700 / 1000 = 0.7
成本性能指标 (CPI)	成本性能的指标，反映项目是否按预算支出	EV / AC	700 / 1000 = 0.7
完成时间的估计值 (TEAC)	按照当前进度项目的完成时间估计	SAC（项目计划周期） / SPI	10 / 0.7 = 14.29
项目的成本预算 (EAC)	按照当前进度，项目的总支出的估计	BAC （项目计划预算）/ CPI	2000 / 0.7 = 2857.14

9. 软件项目的配置管理：

软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则。

配置管理的任务：

• 标志变更

• 控制变更

• 确保变更正确实现

• 向受变更影响的组织和个人报告变更

配置项： 软件配置管理的对象。一个软件配置项是项目中一个特定的、可文档化的工作产品集。例如，程序、文档等。

基线： 已经正式通过复审和批准的某规约和产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程来改变。

常见的软件配置管理工具：

• GitHub

• Bitbucket

• CVS

• Subversion (SVN)

• Google Code

• Harvest

四、经典软件过程管理

1. CMM/CMMI

(1) CMM

出发点：CMM的核心理念是改善现有的软件开发过程，也适用于其他类型的过程。

体系结构： CMM由五个成熟度级别组成，每个成熟度级别（除了级别1）包含若干个关键过程域（KPA）。这些级别的逐步提升帮助组织逐渐完善其过程管理。 每个KPA进一步细分为五个公共特征（包括执行约定、执行能力、执行活动、测量与分析、验证实施），这些公共特征包含了关键实践（KP），即每个KPA包括五类关键实践。通过实施这些关键实践，组织便能够实现对应KPA的目标。

成熟度级别：

1. 初始级（软件过程不稳定，项目执行无序、混乱，没有稳定的开发环境）

2. 可重复级（规则化的）

3. 已定义级（标准的、一致的）

4. 已管理级（可预测的）

5. 优化级（不断改进）

关键过程域（KPA）： KPA是指一组相互关联的操作活动，标识了要达到某个成熟度级别时必须满足的条件。KPA可以分为三大类：管理过程、组织过程和工程过程。（一个软件企业如果希望达到某一个成熟度级别，就必须完全满足该级别的关键过程域的要求，即满足每个关键过程域的目标）

关键实践（KP）： 关键实践描述了对KPA的有效实施和制度化起到最重要作用的基础设施和活动。

(2) CMMI

区别： CMMI相较于CMM，有两种表现方式：阶段式和连续式。而CMM仅有阶段式表示。

• 阶段式：

  ML1（执行的）

  ML2（已管理级）

  ML3（已定义级）

  ML4（量化管理级）

  ML5（优化级）

  固定过程域分组： 每个成熟度等级对应一组过程域（PA），必须全部达标才能升级（例如，ML2包含需求管理、项目计划等7个PA）。

• 连续式：

  组织可针对单个过程域（PA）评估其能力等级（Capability Levels, CL），共6个等级（CL0到CL5）。

  CL0（不完善的）

  CL1（已执行的）

  CL2（已管理的）

  CL3（已定义的）

  CL4（量化管理的）

  CL5（优化）

  灵活改进路径： 可优先提升关键过程域的能力（如先提升“需求管理”到CL3，再提升“风险管理”到CL2）。

• CMM的目标：帮助组织评估和提升软件开发过程的质量和效率。

• CMMI的目标：提供更通用的框架，适用于软件开发、系统工程、硬件制造、服务管理等多领域。

• CMM的范围：仅关注软件工程领域。

• CMMI的范围：覆盖跨学科、多领域的过程改进

• 成熟度划分不同：CMM的五个成熟度分别为初始级，已重复级，已定义级，已管理级，优化级。

  CMM在系统学科与软件学科在传统上没有很好地集成在一起。

  CMMI实现了将系统工程和软件工程集成成为一个过程改进框架，当出现需求时，为引进新学科提供框架。

关系： CMMI是CMM的扩展与改进，它在原有CMM的基础上增加了更细化的表示方法和更广泛的适用范围，提升了过程改进的灵活性和针对性。

2. PSP（个人软件过程）

结构：PSP旨在提供一种由能力成熟度模型（CMM）描述的支持过程改进组织进程的个人规范。具有4个等级，7个台阶组成的成熟度框架 。4个等级分别为个体度量过程、个体计划过程、个体质量管理过程和个体循环过程。PSP过程由一系列方法、表格、脚本等组成，用以指导软件开发人员计划、度量和管理他们的工作。

两种日志：

1. 时间日志：记录个人在各项活动中花费的时间，帮助分析和改进开发过程的效率。

2. 缺陷日志：记录开发过程中发现的缺陷，帮助追踪和分析缺陷产生的原因，进一步优化开发过程。

评审比测试有效的原因： 评审阶段能够更早发现错误，且修复成本较低。缺陷越早被发现，修复的成本越低。评审不仅能及早发现缺陷，还能避免后期进行大量的测试与修复，这使得评审比测试更具优势。

四个设计模板：

1. OST（操作规格模板）：用例图，用于描述系统与外界的交互，展示用户与系统在正常和异常情况下的交互，一般是动态的。

2. FST（功能规格模板）：类图，描述系统与外界的接口，包括类和类与类关系（继承，关联等）、 外部可见的属性、外部可见的方法,一般是静态的。

3. SST（状态规格模板）：时序图，可以精确定义程序的所有状态、状态之间转换以及伴随每次状态转换的动作，一般是动态的。

4. LST（逻辑规格模板）：可以精确描述系统的内部逻辑状态，一般用伪代码实现，一般是静态的。

3. 软件过程模型：瀑布、原型、增量、螺旋、形式化、组件的优缺点

模型	优点	缺点	适用场景	特点
瀑布模型	- 开发阶段清晰，流程线性，便于管理； - 强调文档，便于跟踪和沟通； - 适合需求稳定的项目。	各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； 开发过程中很难响应客户的变更要求； 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。	需求已明确且不易变动的项目	开发阶段严格按照线性方式进行、阶段间有因果关系、每个阶段需评审确认、 允许反馈、强调文档
原型模型	加强用户和软件人员之间的沟通，明确系统的需求 尽早得到系统可用性的反馈信息，及时修改以获得完整、正确需求	- 用户会由于看到的原型系统不完善，而对产品产生怀疑 可能为了快速开发原型系统，而采用未经充分论证的技术导致质量低下	需求不明确或变动频繁的项目	迅速构建一个可以运行的软件原型
增量模型	整个产品被分解成若干个构件逐步交付，用户可以不断地看到所开发软件的可运行中间版本 将早期增量作为原型有助于明确后期增量的需求 降低开发风险 重要功能被首先交付，从而使其得到最多的测试	需要软件具备开放式的体系结构，以便各个构件逐步进入 需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难，容易退化为边做边改方式，使软件过程的控制失去整体性	用户需求逐步明确或持续交付的项目	在各个阶段并不一定交付一个可运行的完整产品，而是交付满足用户需求的一个子集。
螺旋模型	风险驱动 关注软件的重用 关注早期错误的消除 将质量目标放在首位 将开发阶段与维护阶段结合在一起	需要风险评估的经验 只适应内部大规模软件开发	高风险、高复杂度的项目	将瀑布模型和快速原型模型结合起来
形式化方法模型	- 由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性。	-开发人员需要具备一定技能并经过特殊训练 形式化描述和转换是一项费时费力的工作,成本高，质量不一定高 现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述。	安全性要求高的系统，特别是关键任务系统	将软件需求描述提炼成采用数学符号表达的形式化描述； 然后经过一系列的形式化转换将形式化描述转换成可执行程序； 最后将整个系统集成起来测试。
基于组件的开发模型	- 充分体现软件复用的思想 实现快速交付软件 利用开源组件与软件	-商业组件的修改受到限制，影响系统的演化	需要快速交付并且可复用组件的项目	使用可重用的组件或商业组件建立复杂的软件系统

4. MSF（Microsoft Solution Framework）

MSF（微软解决方案框架）是一种成熟的、系统的软件项目方法，它基于一套制定好的原理、模型、准则、概念、指南，以及来自 Microsoft 的、经过检验的做法。

六个角色：

产品管理，程序经理，开发、测试、用户体验、发布经理

• （

（整个团队的6个角色至少要3个人才能担任：一人兼任产品经理、测试者和用户体验，一人兼任程序经理和实施者，另一人任开发者。所以，最小的团队只有3个人）

五个阶段：

• 构思阶段：协调与干系人的关系、项目团队的组建和准备、定义解决方案、确定解决方案范围、建立配置和变更管理

• 计划阶段：技术验证、解决方案的设计、创建主项目计划、创建主项目进度、建立开发和测试环境

• 开发阶段：开发技术基础架构、解决方案技术基础架构的验证、编码、代码审核、测试解决方案、缺陷管理

• 稳定阶段：稳定阶段的测试、缺陷消除过程、用户验收测试、实施投产前测试、试运行

• 部署阶段：部署核心组件、部署各个站点、部署的解决方案稳定、转移到运营和支持、项目完成

  三个准则：MSF项目管理准则、MSF风险管理原则、MSF就绪管理准则

• 两个模型：过程模型，团队模型

5. RUP（统一软件开发过程）

RUP（Rational Unified Process）是由IBM Rational提出的一个面向对象的软件工程的过程框架。

特点：用例驱动、以构架为中心采用迭代和增量模型

九个过程域：

核心过程域（6个）：

• 商业建模：（定义业务流程和需求，将业务需求与软件系统联系起来。）

• 需求：（收集、分析并明确用户需求，确保系统符合用户预期。）

• 分析与设计：（创建系统的架构和设计，进行详细的建模和分析。）

• 实现：（编写代码并将设计转化为可运行的系统。）

• 测试：（对软件进行功能性、性能性和安全性测试，确保产品质量。）

• 部署：（将软件交付给用户并进行必要的维护和支持。）

辅助过程域（3个）：

• 配置与变更管理：（确保所有的变更都得到正确管理和跟踪，保证版本控制。）

• 项目管理：（管理项目的进度、成本、资源和风险。）

• 环境：（提供开发、测试和部署的技术环境支持。）

四个阶段：

• 初始阶段：（规划项目的基础工作，包括确定项目愿景和进行需求初步分析。）

• 细化阶段：（对需求、架构和设计进行详细分析，开始系统开发和测试工作。）

• 构建阶段：（完成软件的主要开发工作，进行集成测试、调整和修复。）

• 交付阶段：（完成最终的部署和交付，进行生产环境的配置和维护。）

六大经验：

• 管理需求

• 迭代开发

• 基于组件的体系架构

• 可视化建模

• 验证软件质量

• 控制软件变更

五、敏捷软件开发

1. 敏捷宣言

我们一直在实践中探寻更好的软件开发方法， 身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划

也就是说，尽管右项有其价值， 我们更重视左项的价值。

2. 常见的敏捷软件过程

过程方法	特点	适合情况
极限编程（XP）	是一种全新而快捷的软件开发方法。XP团队使用现场客户、特殊计划方法和持续测试来提供快速的反馈和全面的交流。这可以帮助团队最大化地发挥他们的价值。准则：沟通，简单，反馈，勇气，尊重，谦逊。	适合小型、有高度责任心且自觉的团队，需求变化快，且希望快速交付的团队。
并⾏争球法 （Scrum）	增量迭代开发，每个迭代周期称为Sprint（通 常为2-4周）。每次Sprint结束后进⾏回顾， 持续改进。包含三个角色：产品负责人，主管，开发团队。四个会议：计划会，每日立会，评审会、反思会。三个订单：产品订单，冲刺订单，燃尽图。	适⽤于快速变化的项⽬，特别是在需求不完 全明确时，能够通过反复迭代逐步明确需求 和开发⽬标。