1、 ICS 35.020 CCS YD 中华人民共和国通信行业标准 YD/T 1754T2018 代替 YD/T 研发运营一体化（ DevOps）能力成熟度 模型 第 2 部分：敏捷开发管理 The capability maturity model of DevOps Part 2: Agile management process （报批稿） （本稿完成日期： 2018.12.18） -发布 -实施 中 华 人 民 共 和 国 工 业 和 信 息 化 部 发 布 YD/T 1754T2018 I 目 次 前 言 .II 1 范围 .1 2 规范性引用文件 .1 3 术语和定义 .1 3.1
2、用户故事 user story .1 3.2 用户故事地图 user story mapping .1 3.3 影响地图 impact mapping .1 3.4 AB 测试 ab test .1 4 缩略语 .2 5 敏捷开发管理 .2 6 价值交付管理 .2 6.1 需求工件 .2 6.2 需求活动 .4 7 敏捷过程管理 .7 7.1 价值流 .7 7.2 仪式活动 .8 8 敏捷组织模式 .10 8.1 敏捷角色 .10 8.2 团队结构 .11 YD/T 1754T2018 II 前 言 研发运营一体化是指在 IT软件及相关服务的研发及交付过程中，将应用的需求、开发、测试、部 署和
3、运营统一起来，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的 无缝集成。帮助企业提升 IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速 变化的业务需求和市场环境。 本标准是“研发运营一体化（ DevOps）能力成熟度模型”系列标准的第 2 部分 敏捷开发管理， 该系列标准的结构和名称如下 : 第 1部分：总体架构 第 2部分：敏捷开发管理 第 3部分：持续交付 第 4部分：技术运营 第 5部分：应用设计 第 6部分：安全及风险管理 第 7部分：评估方法 第 8部分：系统和工具技术要求 本标准 /本部分按照 GB/T 1.12009给出的规则起草。 请
4、注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本标准 /本部分由中国通信标准化协会提出并归口。 本标准 /本部分起草单位： 中国信息通信研究院、北京华佑科技有限公司、中国移动通信集团有限 公司、华为技术有限公司、百度在线网络技术 (北京 )有限公司、北京京东尚科信息技术有限公司、阿 里巴巴（中国）有限公司、中国联合网络通信集团有限公司。 本标准 /本部分主要起草人： 方炜、李海传、何勉、栗蔚、萧田国、牛晓玲、景韵、黎嘉豪、申健、 徐毅、廖靖斌、徐奇琛、廖希密、罗琼、程颖 YD/T 1754T2018 1 1 范围 本标准规定了研发运营一体化（ DevOps）能力
5、成熟度模型下敏捷开发管理过程的能力成熟度要求 和评价方法。 本标准适用于具备 IT软件研发交付运营能力的组织实施 IT软件开发和服务过程的能力进行评价和 指导；可供其他相关行业或组织进行参考；也可作为第三方权威评估机构衡量软件开发交付成熟的标 准依据。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本 文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 1 GB/T 32400-2015 信息技术 云计算 概览与词汇 2 GB/T 32399-2016 信息技术 云计算 参考架构 3 YD/2441-2013 互联
6、网数据中心技术及分级分类标准 4 GB/T 33136-2016 信息技术服务数据中心服务能力成熟度模型 3 术语和定义 下列术语和定义适用于本标准。 3.1 用户故事 user story 从用户的角度来描述用户期望得到的功能。 3.2 用户故事地图 user story mapping 将用户故事按一定顺序和优先级排列以分析与识别最小可行产品 。 3.3 影响地图 impact mapping 是一种用户需求分析的方法，通过 Why,Who,How,What逐层分析需求 。 3.4 AB 测试 ab test 为 Web或 App界面或流程制作两个（ A/B）或多个（ A/B/n）版本，在
7、同一时间维度，分别让组成成 分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析 评估出最好版本正式采用。 研发运营一体化（ DevOps）能力成熟度模型 第 2 部分：敏捷开发管理 YD/T 1754T2018 2 4 缩略语 下列缩略语适用于本文件。 CI Continuous Integration 持续集成 CD Continuous Delivery 持续交付 UI User Interface 用户界面 MVP Minimum Viable Product 最小可行产品 INVEST Independent, Negotiable， Valuab
8、le， Estimable， Small， Testable 独 立的，可讨论的，有价值的，可估算的，小的，可测试的 DEEP Principle Detailed Appropriately， Estimated， Emergent， Prioritized principle 适当细化的，有估算的，随时产生的，有优先级的原则 UI User Interface 用户界面 5 敏捷开发管理 敏捷开发，是一种新型软件开发方法，应对快速变化的市场和技术环境。它更强调价值交付过程 中所涉及的各类角色（如业务、产品、开发和测试等）之间的紧密协作、能够很好地适应变化的团队 组织、协作和工作方式，主张演
9、进式的规划和开发方式、持续和尽早的交付，并不断反馈调整与持续 改进，并且鼓励快速与灵活的面对变更，更注重软件开发过程中人的作用。敏捷开发分为价值交付管 理、敏捷过程管理、敏捷组织模式三个维度，每个维度细分为不同能力子项， 如表 1所示。 表 1 敏捷开发管理 敏捷开发管理 价值交付管理 敏捷过程管理 敏捷组织模式 需求工件 价值流 敏捷角色 需求活动 仪式活动 团队结构 6 价值交付管理 价值交付管理包括需求工件、需求活动两部分内容，体现需求管理过程中的分析、测试、验收三 个阶段。价值交付管理主要体现在各个环节中使用敏捷方法探寻用户（客户）问题和诉求、业务价值、 并定义有效产品功能的能力，适应
10、需求变化的能力，快速验证反馈的能力。 6.1 需求 工件 需求工件是指对需求和用例的管理，是产品经理和开发团队将用户故事的验收标准和需求测试用 例进行关联、验收产品功能是否满足用户故事要求的过程。主要由以下四个部分组成： 1）需求内容与形式：需求内容的分析是探索问题核心相关事项的过程，这一过程需要形成足够小 的需求条目，如：用户故事。用户故事是一种有效的需求形式，它描述用户的业务场景及用户在场景 中的活动。可以在开发过程中对其进行评估、不断细化； 2）需求测试用例编写：编写需求验收标准，形成测试用例的过程； 3）需求测试用例验证：需求测试用例指导需求开发，验证产品功能的过程； YD/T 175
11、4T2018 3 4）需求测试用例管理：建立需求与测试用例的统一管理库，持续的使用和优化。 敏捷开发管理中的需求与工件环节，根据以上四个部分所能达到的不同成熟程度，可分为 以下 5 个等级 ， 如表 2 所示。 表 2 需求工件 级 别 需求内容和形式 需求测试用例编写 需求测试用例验证 需求测试用例管理 1 a) 需求分析形成需 求文档，作为需 求提出方和实施 方之间的契约。 b) 在软件开发过程 中允许经变更流 程执行后进行变 更。 测试用例与需求相互 独立，测试用例在设 计结束、代码开发阶 段完成。 无。 测试用例在需求功能 测试完成后没有做归 档，无法重用。 2 同上，且需求分析形 成
12、用户故事，用户故 事需符合以下要求： a) 用户故事在软件 开发过程中是可 协商并细化的； b) 规模适中，可在 一次发布周期内 完成； c) 可以评估工作 量、有优先级。 同上，且建立测试用 例与用户故事之间的 关联，测试用例在需 求分析结束，设计阶 段完成。 同上，且测试用例在 发布线上环境前全部 验证通过。 同上。 3 同上，且用户故事符 合 INVEST 标准： a) 用户故事是独立 完整的； b) 用户故事是可协 商并细化的； c) 用户故事是有业 务价值的，能做 价值评估； d) 用户故事是能评 估工作量和优先 级的； e) 用户故事是足够 小的，例如：在 同上。 同上，且测试用例
13、通 过工具自动执行。 同上，且测试用例作 为软件资产管理，所 有测试用例验证通过 后，方可进行线上功 能发布。 YD/T 1754T2018 4 1-2 日内能完 成； f) 用户故事是可测 试的。 4 同上，且有挖掘和分 析需求价值的敏捷活 动。例如：典型角色 分析、影响地图、用 户故事的层级化拆分 等。 同上，且产品需求在 最初始阶段能进行实 例化、形成验收标 准，成为测试用例的 依据。测试能和开发 并行工作，形成测试 用例。 同上。 a) 同上，且测试用 例在产品迭代更 新中一直保持完 整和准确。 b) 所有的功能上线 都以测试通过用 例验证为目标， 每次迭代上线都 必须执行沉淀下 的所
14、有的测试用 例，直到验证和 修复通过才可上 线。 c) 需求测试用例无 需重建就能为产 品功能回归验收 时使用。 5 同上。 同上。 a) 同上，且需求应 具备可阅读的文 档和可测试验证 的实例。 b) 通过建立可视化 生产流程，将用 户故事应用到迭 代开发、验收测 试、部署上线的 整个过程中。 a) 同上，且应建立 企业级可视化便 捷的平台，管理 包含测试用例的 需求文档，可以 通过需求文档查 看产品的全貌。 b) 需求提出人、最 终使用人、产品 经理、开发运维 人员可依托平台 进行更好的沟通 和协作。 6.2 需求 活动 需求活动包括需求分析、需求验收两个部分，需求分析主要是指需求提出方和
15、产品经理之间明确 产品需求的活动，是产品研发运营一体化的初始阶段，把产品需求具象化，形成待办事项列表的过程。 需求验收是指产品经理、需求提出者和最终用户对产品的功能验收，要求能对需求进行快速测试、快 速确认、快速反馈、快速优化。本节的需求验收，仅是指功能验收，非功能测试不在本节的范围内。 需求活动包括以下五个方面的工作： 1）需求分析协作：需求分析是各个角色沟通协作形成需求用例或用户故事，并细化的过程，协作 过程中各角色深入持续参与； YD/T 1754T2018 5 2）需求管理方式：需求分析后的用户故事应包括用户需求所涉及的所有事项，统一管理并按照业 务价值由高到低排定优先级，并依据其形成
16、产品研发路线图； 3）需求验收的频率：指不同角色对需求功能验收的频率，频率越高效果越好； 4）需求验收的范围：指需求验收应尽量具备有业务价值的端到端的验收； 5）需求验收的反馈效率：指需求验收的结果准确、快速的反馈到开发团队的过程的效率。 敏捷开发管理中，需求活动根据以上五个方面所能达到的不同程度分为以下 5 个等级， 如表 3 所 示： 表 3 需求活动 级 别 需求分析协作 需求管理方式 需求验收频率 需求验收范围 需求验收反馈效 率 1 a) 需求提出 方、需求分 析人员在完 成需求文档 的编写后离 场，开发团 队按照文档 进行设计开 发。 b) 有变更流 程，需求提 出方、需求 分析人
17、员可 以通过流程 变更需求内 容。 需求有归口统一 管理。 在项目过程中， 有 多 次 验 收 测 试。 项 目 最 终 上 线 后，需求提出者 或最终用户应对 全量功能进行验 收。 有 验 收 测 试 流 程，能把结果反 馈到产品经理和 开发团队。 2 同上，且在用户 故事进入开发周 期前，由产品经 理 、 需 求 提 出 方、开发团队一 起 细 化 用 户 故 事。 同上，且产品经 理使用产品待办 列表统一管理用 户故事，通过用 户故事优先级排 入发布计划。 同上，且产品研 发有稳定的迭代 和 有 计 划 的 交 付，每次交付都 应有验收。 同上，且在每次 交付验收时，产 品经理应对团队
18、的交付成果进行 验收。 同上。 3 a) 同上，且在 需求收集、 分 析 、 开 发、上线运 营的任何阶 段，需求提 出方、产品 经理、团队 成员、运营 人员、使用 者等各角色 同上，且产品待 办 列 表 应 符 合 DEEP 原则： 1）适当的详细描 述的，优先级越 高越详细明确； 2）用故事点进行 估算过大小的； 3）随着产品演进 同上，且产品研 发 有 稳 定 的 交 付，在每次交付 都应有验收。在 跨团队产品里， 有跨团队的产品 验收，并要求在 每个交付周期都 须进行。 同上，且需求提 出者、最终用户 或用户代表应能 在每次交付进行 验收。 同上，且对验收 测试应有快速的 反 馈 和
19、优 化 流 程，保障反馈能 在进入产品待办 列表，且根据优 先级进入研发。 YD/T 1754T2018 6 都可随时对 用户故事进 行细化。 b) 当发生规模 型产品研发 情况，各个 团队各角色 能共同参与 用户故事细 化。 不断涌现和变化 的； 4）优先级从高到 低排序的。 当发生规模型产 品研发情况，应 建立跨团队的产 品待办列表，迭 代待办列表。 4 同上，且应建立 改进需求分析协 作的机制： a) 应建立特性 型的端到端 产品研发运 营团队，减 少跨组织协 作 的 必 要 性。 b) 应建立产品 级回顾改进 机 制 。 例 如，建立运 营驱动需求 的体系，在 产品演进过 程中，不断
20、涌现需求， 能不断优化 和调整待办 列 表 的 顺 序。 c) 当发生跨团 队的产品研 发情况，应 建立需求分 析 协 作 机 制，实现史 诗故事、特 性故事、用 户故事的分 层管理，可 跨团队进行 需求拆解细 a) 同上，且产 品经理对提 出的需求在 产品演进过 程中持续细 化和演进， 形成场景化 驱动和价值 驱动的发布 规划（如用 户 故 事 地 图 ） ， 以 保 持产品待办 列表的价值 最大化。例 如，采用精 益产品的方 法、影响地 图 、 MVP 等 敏捷方法。 有协作型用 户故事沟通 工具、产品 待办列表管 理工具。 b) 有数据收集 和大数据分 析需求价值 和评估的工 具，例如：
21、 能收集用户 交互操作的 工具。 同上。 同上，且在迭代 过程中，应有通 过原型确认、 AB 测试、灰度测试 等方法进行验收 测试，提升验收 效果。 a) 同上，且建 立产品级的 业务价值验 收 反 馈 流 程，在产品 推 向 市 场 后，能快速 响应用户反 馈。 b) 通过反馈发 现迭代中的 沟通、设计 等问题，并 进行持续改 进。应有快 速的反馈和 优化流程和 工具，能收 集 验 收 结 果，并且能 快速转化为 迭代需求。 YD/T 1754T2018 7 化。 5 同上。 同上，且应建立 需求与企业级活 动关联，把企业 战略和目标通过 愿景、目标、关 键结果、任务、 评估、反馈等环 节进
22、行分解，实 现企业、团队、 个人三个层次对 齐，达到需求的 业 务 价 值 最 大 化。 同上。 同上。 同上，且应建立 企业级大数据分 析工具，能抓取 用户行为数据， 通 过 大 数 据 分 析，在用户功能 验收和用户体验 时作为辅助决策 依据，持续优化 改进。 7 敏捷过程管理 敏捷过程管理是产品经理、研发团队以及与产品相关的干系人围绕业务价值交付进行的软件研发 过程，包括价值流、仪式活动两个部分，要求产品经理、团队以及与产品相关的干系人建立以 尽早和 持续地交付有价值的软件为目标，通过高效的沟通方式、高效的可视化的工作流程、有效的度量和快 速反馈机制，实现 软件研发业务价值最大化 。 7
23、.1 价值流 价值流是指产品经理、研发团队在软件研发过程中将软件产品转化为业务价值的能力，包括按照 用户故事地图按需交付可用的软件，交付的软件能准确反映需求提出者的诉求，软件质量、用户体验 能让使用者满意，软件运行结果能快速反馈并持续优化提升，如表 4 所示。 价值流主要包括以下四项内容： 1）交付与需求：指价值交付过程中提升交付节奏和效率的措施。 2）交付质量：指产品价值交付的过程中，需要控制价值交付质量。 3）交付反馈与度量：指建立了对价值交付的反馈机制。 4）价值流动：从产品价值交付角度，通过交付速度、频率等度量指标的优化，不断提升交付的效 率，实现开发任务的拉动式管理。 表 4 价值流
24、 级 别 交付与需求 交付质量 交付反馈与度量 价值流动 1 研发团队的软件交付 以符合需求文档内容 为基准，允许产品经 理在项目全部交付前 变更需求。 软件验收方和研发团 队有约定软件质量指 标。 有 交 付 验 收 测 试 流 程，能把结果反馈到 产 品 经 理 和 开 发 团 队。 通 过 交 付 式 管 理 模 式，在职能团队间通 过契约式交付上下游 间的交付物。 YD/T 1754T2018 8 2 同上，且产品经理、 研发团队采用敏捷的 方法提升交付价值： a）采用用户故事编写 需求，提升需求的业 务价值； b）产品经理、研发团 队在交付迭代中持续 沟 通 并 细 化 用 户 故
25、事，例如：召开需求 澄清会； c）产品经理在迭代交 付上线前进行需求验 收，保障交付符合需 求要求。 同上，且软件质量指 标 包 括 过 程 质 量 指 标、结果质量指标。 在结果质量指标中应 包 含 业 务 连 续 性 指 标 、 用 户 体 验 指 标 等。 同 上 ， 且 需 求 提 出 者、使用者或使用者 代表都参与验收。 a) 同上，且建立团 队工作进展可视 化的工具，能通 过工具展示产品 需求提出到开发 交付的全开发流 程，可视化用户 价值，可视化瓶 颈问题。 b) 团队进行用户故 事规模估算，具 备各团队交付速 度的参考值。 3 a) 同上，且有稳定 的交付节奏，根 据产品待办列
26、表 的优先级持续交 付。 b) 当发生规模型产 品研发情况，所 有团队的需求和 交付计划都是统 一协同的。 同上，且软件质量指 标包括业务价值评估 指标、业务准确性指 标等。 同上。 同时，且具备工具支 撑计划安排活动，能 自动识别任务间的依 赖，支持团队间依赖 管理，能实现任务的 自动流转等 ,对于需要 进 行 团 队 对 齐 的 情 况，能自动实现团队 的对齐。 4 a) 同上，且有提升 需求价值的敏捷 活动。例如：典 型角色分析、影 响地图等。 b) 有提升交付优先 级的价值最大化 的敏捷活动。例 如：精益产品的 方法、用户故事 地图、 MVP 等。 同上，且建立产品级 回顾改进机制，在
27、每 次交付迭代都开展回 顾改进活动，包括根 据交付质量优化软件 研发过程。 同上，且建立产品级 回顾改进机制，在每 次交付迭代都开展回 顾改进活动，包括根 据用户反馈优化软件 研发过程。应具备支 撑软件交付质量、交 付速度的度量评估工 具。 同上，且通过平台能 可视化交付速度等度 量指标，对发现阻碍 问题，团队能通过改 进措施，进行持续改 进。 5 同上，且软件交付节 奏是根据业务的需求 持 续 部 署 ， 按 需 发 布。 同上。 同上。 同上。 7.2 仪式活动 通过建立价值流动的管控机制，可视化地管理价值流动，控制流动节奏，建立反馈机制，不断提 升价值交付效率。包括各类计划会议、评审会议
28、等。主要包括以下三项内容： 1）交付计划：是指需求任务和产品增量的实现计划。 2）交付活动：为了能快速有效的交付业务价值，而进行的相关会议、评审等活动。 YD/T 1754T2018 9 3）人员组织：是在仪式活动中团队组织的形态要求，合作方式。 根据以上三个方面所能达到的不同程度分为以下 5个等级，如表 5所示： 表 5 仪式活动 级别 交付计划 交付活动 人员组织 1 产品计划按照需求分析、开 发、测试、发布上线等划分为 不同阶段。需求变更由产品经 理和团队商量确定。 初步具备敏捷交付的特 征，能进行多次交付，相 关干系人能参与到交付过 程中。 职能型团队 2 a) 同上，且产品待办清单中
29、 用户故事内容完备、优先 级确定，用户故事间的依 赖关系确定。团队能从产 品待办列表中根据优先级 确定将要开发的内容。 b) 产品经理和团队约定计划 变更的流程，产品经理提 出变更请求后，与团队沟 通，共同决定是否进行计 划变更。发生需求变更 时，团队成员决定可以置 换的用户故事。 同上，且能流畅使用产品 需求计划会议、站会、发 布计划会议等，进行需 求、任务对齐、发布交付 的计划确定。具备跨团队 的计划活动，能识别出团 队间存在依赖的用户故 事，约定用户故事的优先 级，对于需要对齐发布周 期的团队，进行发布周期 的对齐。能通过交付评审 会议进行交付结果验收。 明确了产品经理、敏捷教练、 团队
30、三类角色，三者一起工 作。 3 同上，且产品经理和团队围绕 交付价值共同制定产品需求计 划，控制交付的节奏，形成稳 定的价值交付速度。 同上，且团队具备应对措 施，减少变更带来的影 响。例如：需求条目进一 步拆分时，充分考虑其独 立性，减少需求变更影响 的团队范围；团队在开发 过程中，按照用户故事优 先级进行开发；按照团队 约定规则进行需求替换， 最小化对已有需求的影 响；优先置换出低优先级 的需求。 同上，且建立特性团队，保持 业务价值交付的独立性。 4 同上。 同上。 同上，且通过建立和相关干系 人一起工作的机制，变外部沟 通为内部沟通，提升协作效 率。 5 同上，且通过不断优化改进， 实
31、现灵活规划，按需交付。敏 捷团队围绕公司战略工作，在 产品规划、研发、发布各层面 具备灵活反应的能力，可支撑 业务价值驱动下灵活的计划变 更，建立应对风险的能力。 同上。 同上，且企业采用扁平化的敏 捷团队组织架构，赋予团队围 绕产品自组织、自管理的权 力，包括但不限于产品规划、 建设、运营、人力、绩效、核 算等。敏捷团队建立以业务价 值交付为核心、以运营为驱动 的工作模式，企业为团队提供 IT 基础设施、基础管理等支 YD/T 1754T2018 10 持。 8 敏捷组织模式 敏捷组织模式是指团队在研发过程中的角色定义、角色能力以及之间的协作，团队结构的工作方 式、团队间的协作模式等方面的要
32、求，主要从敏捷角色、团队结构两个方面进行定义，如表 6所示。 8.1 敏捷角色 敏捷角色主要是指产品经理、团队、敏捷教练等角色间的职责分工、能力提升、协作方式，角色 都能以价值交付为目标，持续提升交付效率。主要包含以下三项内容： 1）角色职责：定义在敏捷团队中的不同角色及职责。 2）角色能力：对团队成员角色能力的要求。 3）角色协作：定义了团队内外不同角色间的工作协作模式和要求。 根据以上三个方面所能达到的不同程度分为以下 5个等级，具体如下： 表 6 敏捷角色 级 别 角色职责 角色能力 角色协作 1 按照开发流程的上下游关系进 行分工。 以某项专一的专业技术能力为 主。 每个角色关注自身的
33、工作，根 据开发流程的上下游关系进行 协作。 2 a) 同上，且每种角色职责中包括业务价值和 架构价值的内容（例 如：开发人员关注需 求的最终目的。测试 人员在测试过程中关 注用户使用的便捷 性）。 b) 须有产品经理角色。 同上，且每个角色关注自身专 业技术之外的角色技能。 a) 角色间的协作有敏捷实践 （例如：站会、计划会 等） 。 b) 角色间有跨边界的合作。 3 同上，且须有敏捷教练的角 色，该角色可以是全职，也可 以兼职。该角色引导团队进行 敏捷实践，驱动敏捷实践的运 转。 同上，且产品经理能够用敏捷 实践进行工作（例如：用户故 事、影响地图等）。 团队成员，团队内每个角色能 在完成
34、自身工作的同时，当其 他角色的工作发生瓶颈时，能 快速变更角色完成该项工作。 同上，且团队能关注整体交付 进度，能快速发现交付瓶颈， 能通过各角色协作解决瓶颈问 题。 4 a) 同上，且敏捷教练角色弱化，在没有敏捷教练的情 况下，团队敏捷实践有效 运转。 同上，且团队成员能力趋于同 质化，每个成员有强项，具备 跨功能或角色的能力。 同上。 YD/T 1754T2018 11 b) 角色分为产品经理和团队 成员两种，团队成员角色 分工可以有，但是角色职 责不再固化，全部都以价 值交付为目标进行合作。 5 同上。 同上 同上，且团队能在协作模式、 工作方式等方面形成可以借鉴 或推广的经验积累，为其
35、他团 队提供指导。 8.2 团队结构 团队结构在研发过程中以最小化的功能团队，以共同的价值观，通过可视化的方式，紧密合作， 实现业务价值的快速交付。如表 7所示，主要包括以下三项内容： 1）团队组成：定义团队角色组成，核心是强调价值交付的最小实现单元。 2）团队工作模式：用敏捷的工作模式管理团队，形成一致的约定、目标和价值观。 3）团队间协作：重点描述敏捷团队间协作完成价值交付，强调计划对齐和有节奏的交付。 根据以上三个方面所能达到的不同程度分为以下 5个等级，具体如下： 表 7 团队结构 级 别 团队组成 团队工作模式 团队间协作 1 按系统功能模块或专业职责进 行划分。 无。 团队间为完成
36、最终目标有相互 协调的机制。 2 团队足够小，在 10人以下。 a) 团队有达成一致的约定，团队成员能自觉 遵守，所有成员能理 解团队工作目标。 b) 有敏捷实践尝试。 a) 同上，且建立可视化 的产品开发过程 （如：看板、燃尽图 等）。 b) 产品经理和团队进行 面对面的沟通，随时 可以了解研发进度。 c) 团队间能通过敏捷实 践进行沟通协作 （如：跨团队的敏捷 计划会议、 Scrum of Scrum 等）。 3 同上，且组建特性团队，能独 立完成价值交付。 同上，且有敏捷教练，敏捷教 练引导团队进行敏捷实践，团 队成员能熟练使用敏捷实践进 行工作，认可团队敏捷价值 观。 a) 同上，且产
37、品经理和 团队具有共同的交付 价值诉求，共同围绕 着可交付的软件进行 工作。共同遵守团队 约定。 b) 建立多级产品经理制 YD/T 1754T2018 12 度，围绕产品价值紧 密合作。 c) 围绕客户交付价值， 交付可工作的软件。 客户、用户参加产品 验收。 4 同上，且持续提升团队能力， 具备跨产品或业务的交付能 力。团队成员稳定。 同上，且团队不再需要敏捷教 练进行引导，完全自组织、自 管理。通过持续改进，消除瓶 颈和浪费。 a) 同上，且团队和上下 游进行频密良好的协 作和沟通。 b) 建立团队间的回顾改 进制度，并能完成改 进。 5 同上，且组建价值交付能力够 足够强的团队，通过技术架构 的突破，实现组织任何产品或 项目能够在尽量少的团队（ 1- 2个团队）团队内实现价值交 付。 同上。 同上，且由纵向分割的团队间 交付节奏对齐的协作，转变为 由能力提供方提供能力给业务 研发使用的模式。能力提供足 够丰富，使得业务开发能够在 独立团队内完成业务价值交 付。消除了产品业务跨团队的 协作。 _
