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