附录 A1 - 《PMBOK指南》映射
表A1显示了第六版《PMBOK指南》中定义的项目管理过程组与知识领域之间的对应关系
本附录说明了如何利用混合和敏捷方法处理《PMBOK指南》知识领域（请参见表A1-2）中所述的属性，其中涵盖了相同和不同的属性，并提供了为提高成功可能性而需考虑的一些指导原则
| 表 A1-1项目管理过程组与知识领 | |||||
| 知识领域 | 项目管理过程组 | ||||
| 启动 过程组 | 规划 过程组 | 执行 过程组 | 监控 过程组 | 收尾 过程组 | |
| 4. 项目整合管理 | 4.1 制定项目章程 | 4.2 制定项目管理计划 | 4.3 指导与管理项目工作 4.4 管理项目知识 | 4.5 监控项目工作 4.6 实施整体变更控制 | 4.7 结束项目或阶段 |
| 5. 项目范围管理 | 5.1 规划范围管理 5.2 收集需求 5.3 定义范围 5.4 创建WBS | 5.5 确认范围 5.6 控制范围 | |||
| 6 项目进度管理 | 6.1 规划进度管理 6.2 定义活动 6.3 排列活动顺序 6.4 估算活动持续时间 6.5 制定进度计划 | 6.6 控制进度 | |||
| 7 项目成本管理 | 7.1 规划成本管理 7.2 估算成本 7.3 制定预算 | 7.4 控制成本 | |||
| 8 项目质量管理 | 8.1 规划质量管理 | 8.2 管理质量 | 8.3 控制质量 | ||
| 9 项目资源管理 | 9.1 规划资源管理 9.2 估算活动资源 | 9.3 获取资源 9.4 建设团队 9.5 管理团队 | 9.6 控制资源 | ||
| 10 项目沟通管理 | 10.1 规划沟通管理 | 10.2 管理沟通 | 10.3 监督沟通 | ||
| 11 项目风险管理 | 11.1 规划风险管理 11.2 识别风险 11.3 实施定性风险分析 11.4 实施定量风险分析 11.5 规划风险应对 | 11.6 实施风险应对 | 11.7 监督风险 | ||
| 12 项目采购管理 | 12.1 规划采购管理 | 12.2 实施采购 | 12.3 控制采购 | ||
| 13 项目相关方管理 | 13.1 识别相关方 | 13.2 规划相关方参与 | 13.3 管理相关方参与 | 13.4 监督相关方参与 | |
| 表 A1-2 敏捷在《PMBOK 指南》知识领域中的应用 | |
| 《PMBOK 指南》知识领域 | 敏捷工作过程中的应用 |
| 第4章 项目整合管理 | 迭代和敏捷方法，能够促进团队成员以相关领域专家的身份参与整合管理 团队成员自行决定计划 及其 组件的整合方式 在适应型环境下（适应型生命周期 属于敏捷、迭代、或 增量），《PMBOK指南》”整合管理的核心概念”章节中所述的对项目经理的期望保持不变，但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围，并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域，那么这种合作型方法就会更加有效 |
| 第5章 项目范围管理 | 对于需求不断变化，风险大 或 不确定高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。 敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间 在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过发布多个版本来明确需求。这样一来，范围会在整个项目期间被定义和再定义。 在敏捷方法中，把需求列入未完项（定义、再定义，需求是渐进明细的，需求是不容易终止的） |
| 第6章 项目进度管理 | 适应型方法采用 短周期 开开展工作、审查结果，并在必要时做出调整 这些周期可针对方法和可交付成果的适用性提供快速反馈，通常表现为 迭代型进度计划和拉动式按需进度计划（比如 看板），具体参见《PMBOK指南》中“项目进度管理的发展趋势 和 新兴实践”一书 在大型组织中，可能同时存在小规模项目和大规模举措，需要制定长期路线图，通过规模参数（如 团队规模、地理分布、法规合规性、组织复杂性、技术复杂性）来管理这些项目集。为管理大规模的、全企业系统的、完整的交付生命周期，可能需要采用一系列技术，包括 预测法、适应型方法 或 两种方法的混合。组织还可能需要结合几种核心方法，或 采用已实践过的方法，并采纳来自传统技术的一些原则和实践 无论是采用预测型开发生命周期来管理项目，还是在适应型环境下管理项目，项目经理的角色都不变。但是，要成功实施适应型方法，项目经理需要了解如何高效使用相关的工具和技术 |
| 第7章 项目成本管理 | 对易变性高、范围并未完全明确、经常发生变更的项目，详细的成本计算可能没有多大帮助。在这种情况下，可以采用轻量级估算方法快速生成对项目人力成本的高层级预测，在出现变更时容易调整预测；而详细的估算适用于采用准时制的短期规划 如果易变的项目也遵循严格的预算，通常需要更频繁地更改范围和进度计划，以始终保持在成本制约因素之内 |
| 第8章 项目质量管理 | 为引导变更，敏捷方法要求在整个项目期间频繁开展质量与审核步骤，而不是在面临项目结束时才执行 循环回顾： 定期检查质量过程的效果 寻找问题的根本原因，然后建议实施新的质量改进方法 后续回顾会议评估实验过程，确定新方法是否可行，是否应继续使用，是否应该调整，或者直接弃用 为促进频繁的增量交付，敏捷方法关注于小批量工作，纳入尽可能多的项目可交付成果的要素。 小批量系统的目的是在项目生命周期早期（整体变更成本较低）发现不一致和质量问题 |
| 第9章 项目资源管理 | 易变性高的项目，得益于最大限度地集中和协作的团队结构，例如 拥有通才的自组织团队 协作，旨在提高生产率和促进创新的问题解决方式。 协作型团队可以促进不同工作活动的加速整合、改善沟通、增加知识分享，以及提供工作分配的灵活性和其他优势 虽然协作的优势也适用于其他项目环境，协作型团队对于易变性高且快速变化的项目成功而言通常是至关重要的，因为集中分配任务和决策所需的时间更少（团队是自组织，成员都不需要等待分配任务，都是自发的完成任务，所以时间会很节约） 对于易变性高的项目，实物和人力资源规划的可预测性要低得多。在这些环境中，关于快速供应和精益方法的协议，对控制成本和实现进度而言至关重要 |
| 第10章 项目沟通管理 | 在模糊不定的项目环境中，必然需要对不断演变和出现的细节情况，进行更频繁和快速的沟通 因此，应该尽量简化团队成员获取信息的通道，频繁进行团队检查，并让团队成员集中办公 此外，为了促进与高级管理层和相关方的沟通，还需要以透明的方式发布项目工件，并定期邀请相关方评审项目工件 |
| 第11章 项目风险管理 | 从本质上讲，越是变化的环境就存在越多的不确定性和风险 要应对快速变化，就需要采用适用型方法管理项目。即：通过跨职能项目团队和经常审查增量式工作产品，来加快知识分享，确保对风险的认识和管理。 在选择每个迭代器的工作内容时，应该考虑风险；在每个迭代期间应该识别、分析、管理风险 此外，应该根据对当前风险敞口的理解的加深，定期更新需求文件，并随项目进展重新排列工作优先级 |
| 第12章 项目采购管理 | 在敏捷型环境中，可能需要与特定卖方协作来扩充团队 这种协作关系能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目奖励 在大型项目上，可能针对某些可交付成果采用适应型方法，而对其他部分则采用更稳定的方法。在这种情况下，可以通过主体协议，如主要服务协议（MSA），来管辖整体协作关系，而将适应型工作写入附录或补充文件。ng这样一来，变更只针对适应型工作，而不会对主体协议造成影响 |
| 第13章 项目相关方管理 | 高度变化的项目，更需要项目相关方的有效互动和参与 为了开展及时且高效的讨论及决策，适应型团队会直接与相关方互动，而不是通过层层的管理级别 客户、用户、开发人员在动态的共创过程中交换信息，通常能实现更高的相关方参与和满意度 在整个项目期间保持与相关方社区的互动，有利于降低风险、建立信任和尽早做出项目调整，从而节约成本，提高项目成功的可能性 为加快组织内部和组织之间的信息分享，敏捷型方法提倡高度透明 例如，邀请所有相关方参与项目会议和审查，或将项目工件发布到公共空间，其目的在于让各方之间的不一致和依赖关系，或者与不断变化的项目有关的其他问题，都尽快浮现 |
附录A2 《敏捷宣言》映射
本附录说明了《敏捷实践指南》中涵盖的《敏捷宣言》元素（请参见表A2-1 和 表A2-2）
| 表 A2-1 《敏捷实践指南》中涵盖的《敏捷宣言》价值观 | |
| 价值 | 《敏捷实践指南》涵盖内容（按章节和标题） |
| 个体和互动 高于 流程和工具 | 4.2 仆人式领导为团队赋权 4.3 团队构成 5.1 项目章程 和 团队章程 5.2.4 每日站会6.2 组织文化 |
| 可工作的软件 高于 详尽的文档 | 5.2.2 待办事项列表编制 5.2.3 待办事项列表的细化 5.2.5 展示 / 评审 5.2.7 帮助团队交付价值的执行实践 |
| 客户合作 高于 合同谈判 | 4.3 团队构成 5.4 敏捷项目的衡量指标 6.2 组织文化 6.3 采购和合同 6.7 组织架构 |
| 响应变化 高于 遵循计划 | 5.2.1 回顾 5.2.3 待办事项列表的细化 5.2.5 展示 / 评审 |
| 表A2-2 《敏捷宣言》背后原则的实践指南映射 | |
| 原则 | 《敏捷实践指南》涵盖内容 |
| 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求 | 3.1 项目声明周期的特征 3.2 帮助团队交付价值的执行实践 |
| 欢迎对需求提出变更，即使在项目开发后期也不例外。 敏捷过程要善于利用需求变更，帮助客户获得竞争优势 | 5.2.3 待办事项列表的细化 |
| 要经常交付可用的软件，周期从几周到几个月不等，且越短越好 | 5.2 常见敏捷实践 |
| 项目实施过程中，业务人员与开发人员必须始终通力协作 | 4.2 仆人式领导为团队赋权 5.2.2 待办事项列表编制 5.2.3 待办事项列表的细化 |
| 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务 | 4.3 团队构成 5.1 项目章程 和 团队章程 5.2.1 回顾 |
| 无论是对开发团队 还是 团队内部，信息传达最有效的方法都是面对面的交谈 | 4.3.4 团队结构 5.2.4 每日站会 |
| 可用的软件，是衡量进度的首要衡量标准 | 5.2.7 帮助团队交付价值的执行实践 5.2.8 迭代和增量如何帮助交付工作产品 |
| 敏捷过程提倡可持续的开发 项目发起人、开发人员、用户，应该都能够始终保持步调稳定 | 5.1 项目章程和团队章程 |
| 对技术的精益求精 以及 对设计的不断完善，将提高敏捷性 | 5.2 常见敏捷实践 |
| 简洁，即尽最大可能减少不必要的工作，这是一门艺术 | 5.2.2 待办事项列表编制 5.2.3 待办事项列表的细化 |
| 最佳的架构、需求和设计，出自于自组织团队 | 4.3 团队构成 |
| 团队要定期反省怎样做才能更有效，并相应地调整团队的行为 | 5.2.1 回顾 |
附录A3 - 敏捷 和 精益 框架概述
精益：一切均为试验
本附录描述了一些常用的敏捷方法。这些方法可以单独或结合使用，以调整适应特定环境或情况。没有必要一定使用这些方法；敏捷方法可以完全重新开发，只需符合《敏捷宣言》的思维模式、（4）价值观、（12）原则即可。如果能够依据敏捷原则提供可持续价值，且所开发能促进与客户的协作，则无需再开发特定的方法。有关每种方法更多信息的链接，可参考本指南的“参考书目”章节
A3.1 《敏捷实践指南》的选择标准
本实践指南明确说明了许多敏捷方法和技术
图A3-1根据 指南的深度 和 生命周期的广度 描述了一些敏捷方法的示例。用于讨论的已选特定方法均是比较常用的示例，包括：
- 专供整体使用：某些敏捷方法围绕单个项目活动，如 估算或反映。所列示例仅包含更为完整的敏捷框架。其中某些方法的功能更全面，但所有选定方法旨在指导广泛的项目活动
- 适合常用环境：某些敏捷框架具有专有性，仅适合单个组织或环境特定使用。A3.2~A3.14节重点描述了各种环境中的常用框架
- 现代流行用例：某些敏捷框架经过整体化设计和优化构建，但通常通常不适用于大多数项目或组织。根据一组最新行业调查结果显示，本附录中描述的敏捷框架已被众多行业采用
A3.2 Scrum（团队方法）
Scrum是用于管理产品开发的单个团队过程框架
包含：Scrum角色、事件、工件、规则
采用迭代方法来交付工作产品
Scrum是运行在 1个月 或 更少时间 的时间盒上的，其中包含持续时间一致的多个冲刺，这些冲刺中会产生潜在可发布的产品增量
表A3-1列出了项目执行中所利用的Scrum事件和工件
【3个角色】Scrum团队包含产品负责人、开发团队、Scrum主管
- 产品负责人：负责实现产品价值的最大化
- 开发团队：是一个跨职能自组织团队，其开发成员拥有所需的一切资源，可在不依赖团队外部其他资源的情况下交付工作产品
- Scrum主管：负责确保Scrum过程获得相应支持，且 Scrum团队遵从实践和规则，并指导团队消除障碍
| 表A3-1 Scrum事件和工件 | |
| 事件 | 工件 |
| 冲刺 sprint 冲刺计划sprint plan 每日例会 冲刺评审 冲刺回顾 | 产品待办事项列表 冲刺待办事项列表 增量 |
A3.3 极限编程 XP
极限编程 XP ，是一种基于频繁交付周期的软件开发方法
极限编程，该名称基于这样一个概念：将特定最佳实践提炼到最纯粹和最简单的形式，然后在整个项目周期内持续运用该实践
XP 最受关注的地方在于：推广旨在改进软件项目成果的整套实践
极限编程，该方法最初包含12种主要实践，随后逐渐演变，采用了一些其他推论实践。表A3-2列出了这些实践
| 表 A3-2 极限编程实践 | ||
| XP实践领域 | 主要 | 次要 |
| 组织 |
|
|
| 技术 |
|
|
| 规划 |
|
|
| 整合 |
|
|
该演变是通过筛选核心价值观（沟通、简洁、反馈、勇气、尊重）并根据主要原则（人性化、经济、互惠互利、自相似、改进、反思、流程、机会、冗余、失败、质量、循序渐进、承担的责任）信息来设计和采用技术的结果
A3.4 看板方法 KanBan
看板在 精益制造 中是一种用于规划库存控制和补给的系统
看板“准时制”库存补给过程最初可在杂货店中看到，商店会根据货架不足情况，而不是供应商库存，来补给货架商品。受这种准时制库存系统的启发，大野耐一 开发了看板，并在1953年将其应用于丰田的主要制造厂
“看板”一词，按字面解释为“视觉符号”或“卡”。带有卡片的物理看板面板能够推动和实现整个系统工作流的可视化，让每个人都可以看到。该信息发射源（大型显示屏）包含许多列，表示需要完成的工作流的状态。最简单的面板可能包含三列（即：要完成的工作、进行中的工作、已完成的工作），但可以调整为使用团队所需要的任何状态
看板方法应用并适用于多种场合，可以确保工作流和价值交付的持续性。看板方法不如某些敏捷方法规范，因此开始实施时的破坏性也较小，原因在于它是原始的“原地出发”方法。在必要或适当的情况下，组织可以相对轻松地应用看板方法并通过完全实施该方法而向前发展
与大多数敏捷方法不同，看板方法未规定使用时间盒迭代。在看板方法中可以使用迭代，但应始终遵循在整个过程中持续拉取单个条目并限制在制品以优化流程的原则。
如果团队或组织有以下需要时，则看板方法最为适用：
- 灵活性：团队通常不受时间盒的限制，将执行待办事项列表中优先级最高的工作
- 专注于持续交付：团队专注于完成整个系统工作流，直至在制品完成 才会 开始新工作
- 提高工作效率和质量：通过限制在制品将可以提高工作效率和质量
- 提高效率：检查每个任务，了解 增值 或 非增值 活动，然后清除非增值活动
- 团队成员专注力：限制在制品，使团队能够专注于当前工作
- 工作负载的可变性：如果即将开展的工作存在不可预测型，团队将无法做出可预测承诺，即使对于短期工作也不例外
- 减少浪费：透明将会使浪费可视化，因而能够消除浪费
看板方法是从精益思维原则衍生而来，表A3-3列出了看板方法的定义原则和核心属性
看板方法是一种整体性组织增量演变过程和系统变更框架。该方法采用“拉式系统”来完成在制品。团队完成一个条目后，即可拉取另一个条目到该过程
| 表 A3-3 看板方法的定义原则和属性 | |
| 定义原则 | 核心属性 |
| 从当前状态开始 同意采用增量演变性变更 尊重当前过程、角色、职责、头衔 鼓励所有层级领导行为 | 工作流可视化 限制在制品 管理流程 明确过程政策 实施反馈循环 提高协作型 |
看板面板（如图A3-2所示）是一种技术含量低，但 接触广泛的技术，使用者在一开始时可能会以为其过于简单，但很快便会发现其强大的功能
看板面板利用 列 进入和退出策略 以及 限制在制品 等制约因素，可提供一目了然的工作流、瓶颈、阻碍、整体状态 信息。此外，面板可作为面向所有观众的信息发射源，提供团队工作状态的最新信息
在看板方法中，完成工作比开始新工作更为重要。从未完成的工作中无法获得任何价值，因此，团队将协作实施和遵从在制品（WIP）限制，让整个系统中的每份工作得以“完成”
A3.5 水晶方法 Crystal
水晶是一种方法论家族
水晶方法论（Crystal），旨在根据项目规模（项目中涉及的人员数量）以及 项目的关键性来量化 并 提供方法严格程度选择。水晶方法家族如图A3-3所示
水晶方法（Crystal）认识到每个项目可能需要一系列轻量级裁剪的策略、实践、过程。以匹配项目的独特特征
水晶方法论家族根据“重要性”使用不同的颜色来确定要使用的方法
“水晶”一词的使用源自宝石，宝石的不同面代表了根本的核心原则和价值观。不同面代表了 技术、工具、标准、角色。如图A3-4所示
| 表 A3-4 水晶原则的核心价值观 和 常见属性 | |
| 核心价值观 | 常见属性 |
| 人员 交互 社区 技能 人才 沟通 | 频繁交付 反思式改进 密切 或 渗透型 沟通 个人安全 专注 容易接触专家用户 具有 自动化测试、配置管理、频繁整合 的技术环境 |
| 项目中包含的这些属性越多，成功可能性越高 | |
A3.6 ScrumBan
ScrumBan是一种敏捷方法，最初设计为Scrum到看板之间的过渡方法。
ScrumBan是通过其自身衍生，演变而成的另一种混合敏捷框架和方法，其中团队将Scrum作为框架，而将看板作为过程改进方法
在ScrumBan中，工作被分解到许多小的“冲刺”，并利用看板面板来可视化和监督工作。将故事列在看板面板上，团队通过使用在制品限制来管理其工作。通过召开每日立会来维持团队之间的协作，并消除障碍。团队通过设置规划触发因素来了解何时规划下一步工作，通常发生于 在制品级别 低于 预设限制时。
ScrumBan看板中没有预定于角色 -- 团队保留其当前角色
A3.7 功能驱动开发 FDD
功能驱动开发（FDD）的开发目的是：满足大型软件开发项目的特定需求。小型商业价值功能重视能力
功能驱动开发项目有6个主要角色，每个人可以担任以下一个或多个角色
- 项目经理
- 首席架构师
- 开发经理
- 首席编程人员
- 类负责人
- 领域专家
功能驱动开发项目，分为5个过程或活动，以迭代方式执行：
- 开发整个模型
- 构建功能列表
- 依据功能规划
- 依据功能设计
- 依据功能构建
这5个过程的声明周期流程和相互作用如图A3-4所示
功能驱动开发活动由一组核心软件工程最佳实践提供支持：
- 领域对象建模
- 依据功能开发
- 个体代码所有制
- 功能团队
- 检查
- 配置管理
- 定期构建
- 进度和结果可视化
A3.8 动态系统开发方法 DSDM
动态系统开发方法DSDM，是一种敏捷项目交付框架
最初的设计目的是提高20世纪90年代普及的迭代方法的严格程度。改框架开发为行业领导者之间的非商业性协作方式
DSDM因强调制约因素驱动交付而著称。该框架从一开始便可设置成本、质量、时间，然后利用正式的范围优先级 来满足这些制约因素的要求，如图A3-5所示
可通过8个原则来指导 DSDM动态系统开发 框架的使用：
- 专注于业务需求
- 准时交付
- 协作
- 在质量上永不妥协
- 在坚实的基础上进行增量式构建
- 迭代开发
- 保持持续和明晰的沟通
- 演示控制（使用适当的技术）
A3-9 敏捷统一过程
敏捷统一过程（AgileUP）是软件项目中统一过程（UP）的分支。
与紧前统一过程相比，该过程具有加速周期和轻量级的过程。其目的在于在 7 个主要因素之间执行更多迭代的周期，并在正式交付之前纳入相关反馈。表A3-5中列出了因素 以及 指导原则
| 表A3-5敏捷统一过程的主要元素 | |
| 发布中的因素 | 指导因素的原则 |
| 模型 实施 测试 部署 配置管理 项目管理 环境 | 团队了解当前工作 简洁性 敏捷性 专注于高价值活动 工具依赖性 量身定制 特定情境 |
A3.10 扩展框架
A3.10.1 Scrum of Scrums
Scrum of Scrums （SoS）也称为“meta Scrum”，是由两个或多个Scrum团队，而不是一个大型Scrum团队所使用的一种技术，其中一个团队包含 3~9 名成员来协调其工作
每个团队的发表会 与 其他团队代表 定期召开会议，可能是每日例会，但通常是一周两次或三次。每日例会的执行方式类似于Scrum的每日站会，其中代表将报告 已完成的工作、下一步工作设置、任何当前障碍 以及 可能会阻碍其他团队的潜在未来障碍。其目标是确保团队协调工作并消除障碍，以优化所有团队的效率
具有多个团队的大型团队可能要求执行Scrum of Scrum of Scrums，其遵循的模式与SoS相同，每个SoS代表向更大组织的代表报告，如图A3-6所示
A3.11 大规模敏捷框架
大规模敏捷框架为企业的所有层级提供知识库，来进行大规模开发工作
SAFe专注于以下几项原则
- 采用经济视角
- 应用系统思维
- 假设可变性 并 预留方案
- 以快速整合的学习周期 进行 增量式构建
- 根据对工作系统的客观评估设定里程碑
- 直观显示并限制在制品，减少批次规模 并 管理队列长度
- 应用节奏 并 与跨域规划 同步
- 解锁知识员工的内在动力
- 决策分散化（因为每个团队各有自己的特点，需要存在独特的决策）
SAFe专注于项目组合、项目集、团队层详细设定实践、角色、活动，强调围绕专注于向客户提供持续价值的 价值流 来组织企业
A3.12 大规模敏捷开发 LeSS
大规模敏捷开发LeSS，是一种以扩展Scrum方法为共同目标来组织多个开发团队的框架，如图A3-6所示
其核心组织原则是：尽可能保留传统单个团队Scrum模型的元素
这将有助于减少任何模型扩展，避免造成不必要的混乱或复杂性
| 表A3-6显示了LeSS与Scrum的比较 | |
| LeSS与Scrum的相似性 | 在Scrum中添加LeSS技术 |
| 一个产品待办事项列表 一个所有项目完成的定义 一个可在每个冲刺结束时潜在可交付的产品增量 一名产品负责人 全面的跨职能团队 一个冲刺 | 冲刺计划 分为 两个正式部分：冲刺内容 和 冲刺方式 有机跨团队协作 整体跨团队优化 专注于跨团队改进的整体回顾 |
为扩展Scrum而不丢失其精髓，LeSS鼓励使用某些独特的原则，如 系统思维、整体产品专注、透明 等
A3.13 企业Scrum
企业Scrum是一种旨在通过更整体性组织层，而不是单个产品层来应用Scrum方法的框架
该框架尤其建议组织领导：
- 将所有Scrum应用扩展到 所有组织方面
- 普及Scrum技术 以便在这些不同的方面轻松应用
- 根据需要，使用补充技术扩展scrum方法
其目的在于通过实现颠覆性创新将敏捷方法扩展到项目执行范围以外
A3.14 规范敏捷 DA
规范敏捷 DA，是一种 在综合模型中 整合多种敏捷 最佳实践的过程决策框架
DA旨在平衡专注范围过于狭窄（如Scrum）或 细节过于规范（如 敏捷统一过程AgileUP）的流行方法
未实现这种平衡，DA方法根据以下原则混合了多种敏捷技术：
- 以人为先：枚举不同层级的角色和组织元素
- 面向学习：鼓励协作改进
- 完全交付生命周期：提倡多个符合目的的生命周期
- 目标驱动：提供跨部门治理方面的指导
- 可扩展：涵盖多种项目复杂性维度
附录X2 影响裁剪的属性
Shu-Ha-Ri 技能获取模型说明了从遵守规则（Shu守：表示遵守和保护），到有意识地偏离规则（Ha 破：表示变更或离题），最终通过稳定实践和改进找到个人路径（Ri 离：表示分离或离开）的进展过程。我们需要首先在Shu级开始实践，然后准备转到Ha级裁剪过程或Ri级创造新的自定义过程
X2.1 简介
本附录提供了有关裁剪敏捷方法的时机和方法的高层级指导。这些信息可用于确定可能会带来变更或引入新技术的情况，同时提供了一些可供考虑的建议
X2.2 首先应注意的一些事项
裁剪是应由有经验的从业者实施的高级课题，从业者在考虑进行裁剪之前，必须在前面说明的多种环境下成功使用过敏捷方法。换言之，必须首先积累经验并能够成功利用一种敏捷方法才能尝试裁剪
尝试采用敏捷实践时，通常会考虑是否要实施该项目。类似于“回顾不受欢迎，因此我们决定放弃”这样的陈述即说明了此问题，并显示了团队中所存在的一种更为基本的问题，这个问题通过裁剪方法是很难解决的。如果忽视旨在改进过程的回顾活动，这种情况将会变得更为糟糕
最后，应与同事或者可能受变更影响的人员合作执行裁剪。这些人员需要参与变更过程的相关思考和决策过程，以执行和支持这些变更活动，确保成功过渡。忽视裁剪过程可能会导致相关人员抗拒这些变更，即使从技术层面来看存在价值。通常有经验的教练或领导可以帮助让相关人员有效参与
X2.3 如何使用本附录
要想从本附录流出的指南中获益，我们建议首先成功运用所设计的敏捷方法，然后查看表 X2-1 中对应这些情况的裁剪指南并阅读相关建议，接着与将受变更影响的人员进行讨论并达成一套行动计划
如 第5章所述，评估变更的理想方式是：首先尝试一个或两个迭代，然后再考虑永久采用；或者考虑基于流程的方法以实现某些功能，然后通过回顾和重新评估来进行反思
一般在人们了解到可进行实验并提供实验反馈时，将更愿意尝试新事物。试用一个时间盒的时间段后，团队应回顾审查的有效性，以确定按现状继续、通过修改改进效果、放弃使用
最后成功采用后，即可在具有相同特征的项目标准过程中实施量身定制的方法。另外建议遵从第5章中说明如何采用（或裁剪）新方法的指南
X2.4 裁剪建议
下面列出了在使用裁剪方法之前应考虑的一些良好实践
X2.4.1 注意消除影响
许多敏捷实践都是具有相互作用的。例如，集中办公 和 频繁业务对话 可以快速弥补理解方面的差异，因此可以降低需求程度。同样，XP的大量测试可以支持大胆重构，因为各个实践之间是相辅相成的。在消除实践时不去了解或解决其制衡因素，可能会起到反作用
X2.4.2 使用裁剪指南表
使用表 X2-1 找到匹配特定情况的情形，然后考虑裁剪的建议。与将受变更影响的人员进行讨论并首先计划短暂尝试，然后进行真实跟踪审查，最后再实施变更
| 表 X2-1 裁剪指南 | |
| 情况 | 裁剪建议 |
| 大型项目团队 | 将大型项目重建为多个小项目 首选，尝试技术实验项目，然后再执行实施项目
|
| 分散团队 | 许多项目路都会包含（一些）分散团队成员。即时信息、视频会议、团队电子版 都有助于确保通讯流畅
|
| 某些安全关键型产品可能需要当前敏捷过程所建议的其他文档 及 合规性检查 | 在这些环境中仍可使用敏捷方法，但还需要该领域所要求的的其他相应的合规性审查、文档和认证 在这种情况下，文档可能需要随已完成的功能一起交付。只有文档完成后功能才算完成 考虑使用混合方法（多种敏捷方法），按照产品环境所要求的的更高严格程度，从敏捷所带来的的协作和沟通改善中获得益处。航空飞行系统开发商和药物公司采用敏捷方法并结合自己的其他过程，充分利用这些优势并保留了相应的控制权 |
| 稳定需求 和 执行过程 | 是够真正需要敏捷方法？
尽管协作和透明程度提高对任何项目都有益处，但某些迭代构建和审查周期可能会是多余的
|
| 团队位于职能型组织内的职能孤岛中（能力施展不出来） | 敏捷式基于跨职能团队的理念
|
| 透明会产生恐惧 | 敏捷将会创建透明文化： 员工会在整个开发期间展示和分享其成果 这种分享中间可交付成果的方式 以及 对成败得失 和 当前状态的开诚布公 的态度即反映了透明化。透明需要勇气 通过使用 状态版 或 白板，示范引导并在决策过程中展示透明化 |
| 许多团队成员缺乏技术领域知识 | 敏捷方法将会提高团队的主动性 并 发挥其优势，做出工作内容相关的本地决策，例如 任务安排顺序 以及 在解决问题时采用哪种方法
|
| 缺乏管理层支持 | 如果缺乏管理层支持，团队将会在 敏捷思维模式和方法 与 更具预测性的思维模式和方法 之间遇到冲突
|
| 敏捷术语和语言 不适合 组织文化 | 如果不是敏捷语言，就修改术语，让员工了解并同意这些活动。说明每个术语的特定含义 例如，如果组织认为“游戏”一词不够专业，请勿使用类似于“计划游戏”这样的术语，而是考虑使用“计划研讨会”这样的术语 |
附录x3 敏捷适用性筛选工具
x3.1 简介
敏捷文献包含许多敏捷适用性筛选工具，可帮助评估敏捷方法所适用的环境
1994年，动态系统开发方法DSDM开发了敏捷项目适用性使用问卷调查和组织适用性问卷调查来帮助衡量可能适合的领域和潜在的问题
水晶方法家族还利用了适用性标准，根据团队规模以及所开发产品或服务的关键性来对项目排序。水晶方法建议，较小的不太关键的项目应采用简单的方法并实施较弱的控制。大型任务或生命关键型项目建议使用更高的严格程度和验证级别
这些方法被开发出来之后，又创建了许多模型来确定利用敏捷方法的时间和地点。Boehm 和 Turner 采用DSDM和水晶方法中的一些元素开发了一种流行的评估模型，以帮助确定采用敏捷还是更传统的方法来实施项目
根据这些以前的模型 且 需要通过扩展来考虑混合方法的中间情况，建议采用以下模型。其中包括多种适用性筛选属性，可帮助组织评估和讨论采用预测、混合、还是 敏捷方法 来实施项目
X3.2 模型概述
根据三种主要类别评估组织和项目属性
- 【文化】是否具有支持该方法 并 已建立信任的 团队环境？
- 【团队】适当规模的团队是否能在采取敏捷后获得成功？成员是否能够获取成功所需的技术 以及 业务代表联系渠道？
- 【项目】变更速度极快？增量交付可行？项目关键性如何？
回答这些类别的问题，然后将结果绘制在雷达图中。
- 图中心的值表示非常适合敏捷方法
- 外围结果表示预测法可能更适合
- 中间部分（敏捷 和 预测 之间）的的值表示混合方法可能会奏效
示例见图 X3-1
x3.3 使用说明
X3.3.1 分组完成问卷调查
对于小型项目，该小组可能仅包含 发起人、技术领导、客户。
对于大型项目，这可能包含 发起人小组、项目执行团队、受影响的业务组、项目治理组、客户社区的代表
原则是：
- 如果仅代表个人观点具有个人偏见，没有一个相关方应估算或规划项目
- 如果有人持有局限性偏见，没有人应评估方法的适用性
此外，（分组完成问卷调查）该工具的价值在于鼓励与项目投资方对话。即使结果指向混合方法，但相关方希望主要采用敏捷或预测法继续进展，请遵从相关方的一致意见。（分组完成问卷调查）该工具仅支持高层级诊断，最终决策应取决于相关方并应得到其支持
X3.3.2 从1到10给问题打分
分组讨论并同意（或 妥协）最能准确反映问题主观评估的分数
仅在回答的 开始、中间、结束 点提供确定性方案，代表1分、5分、10分，可以（理想情况下）在“差不多选1，但不绝对”处使用2分 或 在“5与10之间某处”使用7分。同样，该评估是一种讨论工具---观点是主观性的，可能没有准确的答案
如果小组在得分方面无法达成一致，请开诚布公地讨论该问题。在建议妥协分数（即使用平均分 或 在PMO分数处标记蓝色“X” 并 在开发团队分数处标记绿色“0”）之前，请考虑下既然参与者无法在简单评估方面达成一致，项目的成功可能性有多少？讨论问题时，如果确定意见不同---很好，这很正常；现在达成一致意见。同样，如果评估结果是预测法，但每个人都希望尝试敏捷方法（反之亦然）--也很好，只需了解下问题并讨论如何处理该方法的影响
X3.3.3 解释结果
在空白适应性评估图上标记问题答案，然后连接分数。集聚在敏捷区域中心的结果表示非常适合完全敏捷方法
主要位于混合区域的结果表示结合使用敏捷和预测法可能最有效。但是，可能需要在敏捷方法中采取一些其他的降低风险措施才能满足需求，如 增加教育和培训 或 在高关键性项目中提高验证级别和文档严格程度。或者，在预测法中添加一些概念验证工作 或 过程 可能会奏效
主要位于预测区域的结果表示非常适合完全预测法。如 X3.3.2 节 所述（给问题打分步骤），该诊断工具旨在 与 受影响方 开始针对最合适使用方法的有意义对话。如果不能接受该工具所建议的方法，允许使用不同的方法。使用这些结果作为风险管理过程的输入，因为该工具会显示将需要管理的不匹配情况
X 3.4 适应性筛选问题
X3.4.1 类别：文化
X3.4.1.1 支持方法
高级发起人是否了解 并 支持 在该项目中使用敏捷方法？
请参见图x3-2
X 3.4.1.2 团队信任度
考虑与团队合作的发起人和业务代表的态度
相关方确信凭借持续支持和双方反馈，团队能够将其愿景和需求转换为成功产品或服务？
请参见图x3-3
X 3.4.1.3 团队决策能力
团队是否可以自主做出有关如何实施工作方面的本地决策
请参见图X3-4
X3.4.2 类别：团队
X 3.4.2.1 团队规模
核心团队的规模是多少？
使用该量表：
- 1～9 = 1（敏捷）
- 10～20 = 2（敏捷）
- 21～30 = 3（敏捷）
- 31～45 = 4（混合）
- 46 ～ 60 = 5（混合）
- 61 ～ 80 = 6（混合）
- 81 ～ 110 = 7（混合）
- 111 ～ 150 = 8（混合）
- 151 ～ 200 = 9（预测）
- 201 + = 10（预测）
请参加图 X3-5
X3.4.2.2 经验水平
考虑核心团队角色的经验和技能水平
角色中人员经验水平参差不齐是很正常的，这对顺利开展敏捷项目没有影响；但每个角色中至少有一名有经验的人员，这会更容易开展工作
请参见图X3-6
X 3.4.2.3 客户/业务联系
团队每天是否能联系到至少一名业务/客户代表 以 询问问题和获取反馈？
请参见图x-7
X 3.4.3 类别：项目
X 3.4.3.1 变更可能性
每月需求变更 或 发现新需求的可能性是多少 ？
请参见图 x3-8
X 3.4.3.2 产品 或 服务 关键性
要帮助确定 其他验证级别 和 文档严格程度 需求，请评估正在构建的产品或服务的关键性
使用评估时，考虑因可能的缺陷导致的损失，确定失败可能的后果
请参见图X3-9
X 3.4.3.3 增量交付
产品或服务是否能够按比例构建和评估？
此外，业务 或 客户代表 是否能够及时提供所交付增量方面的反馈？
请参见图X3-10
X 3.5 适用性评估图表
图 X3-11 是适用性评估所使用的雷达图
X 3.5.1 案例研究
为了说明雷达图的工作原理，下面提供了两个使用该模型为不同项目类型打分的示例
第一个是：在线药店项目示例（请参见图 X3-12）
第二个是：军事信息系统示例（请参见图 X3-13）
这两个案例研究说明了项目中存在的的一些差异
- 【中心集群】表示非常适合敏捷方法
- 【外围分数】表示预测法可能更适合
- 【中间】某些项目位于中心但延伸出一个或两个轴，这些项目可以采用混合方法解决
X 3.5.1.1 药店示例
该项目的目的是开发一个能向（主要）美国客户销售便宜的加拿大处方药的在线药店。这些药品销售在加拿大和美国都存在争议，因此该行业的特点是：
- 规范变化：极快 且 竞争激烈
- 该项目面临非常易变的需求：每周都会发生重大变更
因此，采用较短（2天）迭代和每周发布方法来解决变更速度快问题
如图X3-12所示，对于那些被赋权的团队，高层级的支持和信任是显而易见的。网站的可视化特点可以方便显示新的增量功能，但由于必要的药品资金面临风险，系统关键性很高。如上所述，该项目变更速度极快，但小型有经验的团队可以很好地处理这一点，并可轻松联系到善于解决问题的业务代表。该方法给长成功和敏捷
X 3.5.1.2 军事信息系统示例
对比第一个示例 与 大型项目来开发军事信息系统，在评估时该系统已运行5年
请参见图X3-13
该项目缺乏敏捷方法支持，组织未考虑采用敏捷方法
- 对供应商的信任程度不高，但基本保持尊重
- 决策不是通过本地完成，而是由架构和需求委员会确定
- 尽管可以在实验室增量测试设计元素，但无法收集到一起进行端到端功能演示
- 许多生命可能处于危险之中，因此关键性很高
- 因为变更会影响许多转包商组织，所以需求被锁定（无法随意变更）
- 该项目很大，一家供应商变超过300人，但每个角色都拥有许多有经验的从业者
- 与业务客户代表联系是不可能的，但可以向合同分析师询问规范问题，他们通常会在 10 日内 回复或澄清问题
- 可以分割部分项目 并 将其作为敏捷项目，但该举措的核心是 单个大型项目
X 3.6 总结
敏捷适应性筛选，是确定敏捷方法 潜在适合性 与 差距 的有用工具。他们不能作为确定性的包含或排除关口，而是作为可与所有关注方进行客观讨论的主题
