研发运营一体化能力成熟度模型 第2部分:敏捷开发过程

曹兴文

2018/05/13 发布于 技术 分类

第九届 GOPS 全球运维大会将于2018年4月13日-14日在深圳召开。大会为期2天,侧重方向是 AIOps、运维自动化和 DevOps。

文字内容
1. 技 术 标 准 研发运营一体化能力成熟度模型 第 2 部分:敏捷开发管理过程 The DevOps capability maturity model Part 2: Agile management process (征求意见稿) 2017 年 11 月 18 日
2. YDB XXXXX—XXXX 目次 目次 ........................................................................................................................................ I 前言 ....................................................................................................................................... II 1 范围..............................................................................................................................................1 2 规范性引用文件 ...........................................................................................................................1 3 术语..............................................................................................................................................1 3.1 黄金圈 golden circle.....................................................................................................................1 3.2 用户故事 user story .....................................................................................................................1 3.3 用户故事地图 user story mapping ..............................................................................................1 3.4 影响地图 impact mapping ...........................................................................................................1 3.5 AB 测试 ab test..............................................................................................................................1 4 缩略语 ..........................................................................................................................................2 5 综述..............................................................................................................................................2 6 敏捷需求管理...............................................................................................................................2 6.1 需求收集 .......................................................................................................................................2 6.2 需求分析 .......................................................................................................................................4 6.3 需求与用例管理 ...........................................................................................................................5 6.4 需求验收 .......................................................................................................................................7 7 迭代计划管理...............................................................................................................................9 7.1 需求澄清 .......................................................................................................................................9 7.2 故事与任务排期 .........................................................................................................................10 7.3 计划变更 .....................................................................................................................................12 8 敏捷过程管理.............................................................................................................................14 8.1 迭代管理 .....................................................................................................................................14 8.2 迭代活动 .....................................................................................................................................15 8.3 过程可视化及流动 .....................................................................................................................17 8.4 度量分析 .....................................................................................................................................18 I
3. 前言 YDB XXXXX—XXXX 研发运营一体化是指在 IT 软件及相关服务的研发及交付过程中,将应用的需求、开发、测试、部 署和运营统一起来,基于整个组织的协作和应用架构的优化,实现敏捷开发、持续交付和应用运营的无 缝集成。帮助企业提升 IT 效能,在保证稳定的同时,快速交付高质量的软件及服务,灵活应对快速变 化的业务需求和市场环境。 本标准是“研发运营一体化能力成熟度模型”系列标准的第 2 部分,该系列标准的结构和名称如 下: § 第 1 部分:总体架构 § 第 2 部分:敏捷开发管理过程 § 第 3 部分:持续交付过程 § 第 4 部分:技术运营过程 § 第 5 部分:应用架构 § 第 6 部分:安全管理 § 第 7 部分:组织结构 本标准按照 GB/T 1.1-2009 给出的规则起草。 本标准由中国通信标准化协会提出并归口。 本标准起草单位:中国移动浙江公司、 DevOps 时代社区、高效运维社区、中国信息通信研究院 本标准主要起草人: 方炜、李海传、廖希密、张乐、景韵、萧田国、栗蔚 II
4. 研发运营一体化能力成熟度模型 第 2 部分:敏捷开发管理过程 1 范围 本标准规定了研发运营一体化的敏捷开发管理过程及相关能力成熟度模型。本标准中的研发运营一 体化包括IT软件及服务的需求、开发、测试、部署和运营五个环节,并实现敏捷开发、持续交付和技术 运营的顺序闭环集成。 本标准适用于企业在实施IT软件开发和服务过程中实现研发运营一体化架构,提升IT效能。 2 规范性引用文件 下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件,仅所注日期的 版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。 [1] GB/T 32400-2015 信息技术 云计算 概览与词汇 [2] GB/T 32399-2015 信息技术 云计算 参考架构 [3] YD/T2441-2013 互联网数据中心技术及分级分类标准 [4] GB/T 33136-2016 信息技术服务数据中心服务能力成熟度模型 3 术语 下列术语和定义适用于本文件。 3.1 黄金圈 golden circle 全称为黄金思维圈,及先思考Why(目的、理念),再考虑How(方法和措施),最后才是What(现 象和成果)。 3.2 用户故事 user story 从用户的角度来描述用户渴望得到的功能。 3.3 用户故事地图 user story mapping 将用户故事按一定顺序和优先级排列以分析与识别最小可行产品。 3.4 影响地图 impact mapping 是一种用户需求分析的方法,通过Why,Who,How,What逐层分析需求。 3.5 AB 测试 ab test 1
5. 为Web或App界面或流程制作两个(A/B)或多个(A/B/n)版本,在同一时间维度,分别让组成成分 相同(相似)的访客群组随机的访问这些版本,收集各群组的用户体验数据和业务数据,最后分析评估 出最好版本正式采用。 4 缩略语 下列缩略语适用于本文件。 CI Continuous Integration 持续集成 CD Continuous Delivery 持续交付 MVP Most Variable Product 最小可行产品 INVEST Independent, Negotiable,Valuable,Estimable,Small,Testable 独立的,可讨论 的,有价值的,可估算的,小的,可测试的 DEEP Principle Detailed Appropriately,Estimated,Emergent,Prioritized principle 适 当细化的,有估算的,随时产生的,有优先级的原则 UI User Interface 用户界面 5 综述 敏捷开发管理是一种新的软件开发方法,它不同于传统的瀑布式开发,以用户的需求进化为核心, 采用迭代、循序渐进的方法进行软件开发,关注有序迭代、灵活响应以及价值的快速交付,分为需求管 理、计划管理、过程管理三个维度。 敏捷需求管理 需求收集 需求分析 需求与用例 需求验收 敏捷开发管理 迭代计划管理 敏捷过程管理 需求澄清与拆解 迭代管理 故事与任务排期 迭代活动 计划变更 过程可视化及流动 度量分析 图1 敏捷开发管理 6 敏捷需求管理 敏捷需求管理包括需求收集、需求分析、需求与用例、需求验收四部分内容,体现需求管理过程中 的收集、分析、测试、验收四个阶段,敏捷的需求管理的能力主要体现在各个环节中使用敏捷的方法探 寻产品痛点、业务价值、用户体验的能力,适应需求变化的能力,快速验证反馈的能力。 6.1 需求收集 需求收集环节是需求提出方和产品经理之间明确产品需求的阶段,是产品研发运营一体化最初始阶 段,把产品的需求具象化,形成待办事项列表的过程。 需求收集环节包括三个方面工作: 1)明确单个需求点:即以问题驱动为核心,探索问题核心相关事项的过程; 2)梳理需求全貌:应能列出为了落实产品的愿景而需要完成的所有事项,即待办事项列表; 2
6. 3)确定待办事项列表:应包括用户需求所涉及的所有事项,并且作为产品研发路线图。 敏捷开发管理中,需求收集环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如 下: 主要工作完备性 级别 单个需求点 需求全貌 需求的管理 人员机制 工具能力 备注 应梳理所有 应能明确需 应有模板和规范,并 需求问题, 求问题,制 在形成需求说明书之 形成需求说 1 定明确的功 后的需求沟通、实施 无 无 明书,涵盖 能点需求要 过程中应采用契约的 所有的需求 求 方式传递。 功能要求。 需求提出方和产 品经理应有明确 的需求收集流 应通过协作 应有待办事 需求应在需求进入迭 程,制定了快速 方式形成适 2 项列表来管 代开发之前可以进行 沟通协作机制, 无 当详细的需 理需求。 变更和细化。 例如明确规定计 求说明。 划和需求之间的 流转和协作方法 和规范。 同上且产品经理对提 需求提出方 出的需求在产品演进 和产品经理 过程中持续细化和演 应通过需求 3 同上 同上 进,形成产品路线图。 同上 例如,采用精益产品 收集可视化 工具,归集到 的方法、影响力地图、 待办事项列 MVP 的方法等敏捷方 表,由产品经 法等。 理统一管理。 4 同上 同上 同上 同上且需求提出 方和产品经理之 间的机制应不限 定时间和角色, 保证需求随时入 和出。例如,建 立运营驱动需求 的体系,在产品 演进过程中,不 断涌现需求,能 不断优化和调整 待办列表的顺 同上且有协 作型需求沟 通工具,在需 求提出、收 集、分析、实 施过程中,各 角色随时沟 通都能对需 求内容进行 持续演进和 细化。 序。 5 同上 同上 同上且建立需求快速 同上且企业采用 同 上 且 使 用 上线、快速反馈流程, 扁平化的敏捷团 企 业 提 供 的 3
7. 用户反馈能快速收 集。 队组织架构,赋 统 一 的 需 求 予团队围绕产品 收集工具、协 自组织、自管理 作 型 需 求 沟 的权力,包括但 通工具,归集 不限于产品规 到待办事项 划、建设、运营、 列表,由产品 人力、绩效、核 经 理 统 一 管 算等。例如,敏 理,能够保证 捷团队以业务价 需 求 随 时 入 值为核心以运营 和出,并在需 为驱动的敏捷工 求 提 出 、 收 作模式,企业为 集、分析、实 团队提供 IT 基 施过程中,随 础设施、基础管 时 沟 通 都 能 理等支持。 对需求内容 进行持续演 进和细化。 6.2 需求分析 需求分析是产品经理将需求细化和拆解成用户故事的过程,主要体现三个方面: 1)明确需求内容和形式:需求分析形成用户故事,用户故事描述用户场景; 2)需求分析协作:用户故事是适度详细并适应变化的,可以在开发过程中对其进行评估不断细化; 3)需求管理方式:用户故事统一管理,并按照业务价值由高到低排定优先级。 敏捷开发管理中,需求分析环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如 下: 主要工作完备性 级别 需求内容和形式 需求协作 需求的管理 人员机制 工具能力 备注 需求分析人员 需求分析形成软 在完成需求规 件需求规格说明 格说明书的编 通过需求规格 1 书,作为需求提 写后离场,开 说明书统一管 无 无 出方和实施方之 发团队按照需 理。 间的契约 求规格说明书 进行开发。 需求分析形成用 迭代开始前, 应使用产品待 户故事,用户故 由产品经理、 办列表和迭代 2 事规模适中,可 需求提出方开 无 无 待办列表管 在一个迭代内完 发团队一起细 理。 成。 化用户故事。 用 户 故 事 符 合 在软件过程的 同上且当发生 3 INVEST 标准:1) 任何阶段,产 规模型产品研 无 无 故事是独立完整 品经理、需求 发情况,应建 4
8. 的,2)故事是可 提出方及团队 立跨团队的产 协商并细化的, 成员可对用户 品待办列表, 3)故事是有业务 故事进行变更 迭代待办列表 价值的,4)故事 和细化。 是能评估工作量 和优先级的,5) 故事是足够小 的,一般在 1-2 日内完成,6)故 事是可测试的。 同上且产品待 办列表应符合 DEEP 原则:1) 同上且应具备可 同上且当发生 适当的详细描 视化的 MVP 的产 跨团队的产品 述的,优先级 品演进路线,管 研发情况,应 应建立特性型研 有 协 作 型 用 越高越详细明 理用户故事和发 建 立 史 诗 故 发团队,与产品 户 故 事 沟 通 确,2)用故事 4 布迭代关系,可 事、特性故事、 经理合作提升需 工具、产品待 点进行估算过 以使用例如:用 用户故事的分 求分析落地的价 办 列 表 管 理 大小的,3)随 户故事地图、影 层管理,可跨 值流动。 工具。 着产品演进不 响力地图等敏捷 团队进行需求 断涌现和变化 方法。 拆解细化。 的,4)优先级 从高到低排序 的。 同上且企业采用 5 同上 同上 同上且应建立 需求与企业级 活动关联,把 企业战略和目 标通过愿景、 目标、关键结 果、任务、评 估、反馈等环 节进行分解, 实现企业、团 队、个人三个 层次对齐,达 到需求的业务 价值最大化。 扁平化的敏捷团 队组织架构,赋 予团队围绕产品 自组织、自管理 的权力,包括但 不限于产品规 同上且应建 划、建设、运营、 立企业级的 人力、绩效、核 需求管理工 算等。敏捷团队 具。 以业务价值为核 心以运营为驱动 的敏捷工作模 式,企业为团队 提供 IT 基础设 施、基础管理等 支持。 6.3 需求与用例管理 5
9. 需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联性,能验收产 品功能是否满足用户故事的要求的过程。主要体现在三个方面: 1)梳理需求用例:编写需求验收标准,形成测试用例的过程; 2)使用需求用例:需求用例指导需求开发,验证产品功能的过程; 3)管理需求用例:建立需求与用例的统一管理库,持续的使用和优化。 敏捷开发管理中的需求与用例管理环节,根据以上三个方面所能达到的不同程度分为以下5个等级, 具体如下: 级别 1 2 3 4 需求与用例 编写 测试用例与 需求没有关 联,测试用 例在设计结 束代码开发 阶段完成。 测试用例与 用户故事应 有关联,测 试用例在需 求分析结束 设计阶段完 成。 同上 同上且产品 的需求在最 初始阶段即 转化为测试 用例,细化 需求编写验 收标准过程 主要工作完备性 需求用例验证 需求与用例的管理 测试用例在本需求 功能测试完成后没 无 有做归档重用,在 每次有新需求重新 设计测试用例。 需求文档和测试用 每次上线前应 把编写的测试 用例全部验证 通过,才可上 线。 例应作为知识沉淀 下来,当设计现有 产品进行功能优化 的需求时,需求文 档和测试用例在现 有的知识上进行调 整优化。 测试用例应作为产 品的软件代码资产 存在,所有的功能 上线都以能测试用 同上 例验证通过为目 标,每次迭代上线 都必须执行产品沉 淀下的所有测试用 例,直到验证和修 复通过才可上线。 同上且需求作为需 求用例库作为产品 的软件代码资产存 同上 在,既保持可读性 又作为用例在产品 迭代更新中一直保 持完整和准确。 人员机制 无 无 无 无 工具能力 备注 无 无 测试用例能 通过工具自 动执行。 同上 6
10. 即编写测试 同上且所有的功能 用例的过 上线都以能被可读 程。 的需求用例验证通 过为目标,每次迭 代上线都必须执行 沉淀下的所有的需 求用例,直到验证 和修复通过才可上 线。 当产品进行升级重 构时,产品的需求 用例库无需重建就 能作为升级重构后 的验收标准。 5 同上 需求应具备可 阅读的文档和 测试验证的实 例两种特性, 通过建设企业 级可视化便捷 的平台,建立 从用户故事排 入迭代开发、 开发完成后作 为测试验收测 试、部署到生 产即作为生产 验收测试,整 个过程的全自 动化模式。 同上 企业采用扁平化 应建立企业 的敏捷团队组织 级可视化便 架构,赋予团队 捷的平台,管 围绕产品自组 理需求文档, 织、自管理的权 且可以通过 力,包括但不限 需求文档能 于产品规划、建 查看产品的 设、运营、人力、 全貌,且通过 绩效、核算等。 平台,需求提 敏捷团队以业务 出人、最终使 价值为核心以运 用人、产品经 营为驱动的敏捷 理、开发运维 工作模式,企业 人员进行更 为 团 队 提 供 IT 好的沟通和 基础设施、基础 协作。 管理等支持。 6.4 需求验收 需求验收是指产品经理、需求提出者和最终用户对产品的功能验收,要求能对需求进行快速测试、 快速确认、快速反馈、快速优化。本节的需求验收,仅是指功能验收,非功能测试不在本节的范围内。 需求验收主要体现在以下三个方面: 1)需求验收的频率:指不同角色对需求功能验收的频率,频率越高效果越好; 2)需求验收的范围:指需求验收应尽量具备有业务价值的端到端的验收; 3)需求验收的反馈效率:指需求验收的结果能准确、快速的反馈到开发团队的过程。 敏捷开发管理中,需求验收环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如 下: 级别 主要工作完备性 人员机制 工具能力 备注 7
11. 需求验收频 需求验收范围 需求验收反馈效率 率 在项目末 尾,需求上 线后,一次 需求提出者或 有验收测试流程, 性 的 实 施 最终用户应对 能把结果反馈到产 1 无 无 alpha 测 全量功能进行 品 经 理 和 开 发 团 试、beta 测 验收。 队。 试、正式验 收测试。 在验收评审会 在每个敏捷 上,产品经理 迭代,应有 2 应对团队的迭 同上 无 无 验收评审 代成果进行验 会。 收。 同上且在跨 对验收测试应有快 团队产品 同上且需求提 速的反馈和优化流 里,有跨团 验收须有产品经 出者或最终用 程,能保障反馈能 队的产品验 理、需求提出者 3 户应能在每个 在进入产品待办列 无 收会,并要 和最终用户等参 发布后进行验 表,且根据优先级 求在每个迭 与。 收。 进入迭代待办列 代都须召 表。 开。 4 同上 同上且在迭代 过程中,应有 通过原型确 认、AB 测试、 灰度测试等方 法进行验收测 试,提升验收 效果 同上且建立产品级 的业务价值验收反 馈流程,在产品推 向市场后,能在 1-2 个迭代就能快速进 行响应。 同上 应有快速的 反馈和优化 流程和工具, 能收集验收 结果,并且能 快速转化为 迭代需求。 企业采用扁平化 应 建 立 企 业 的敏捷团队组织 级 大 数 据 分 架构,赋予团队 析工具,能抓 同上且针对反馈的 围 绕 产 品 自 组 取 用 户 行 为 情况,能通过反馈 织、自管理的权 数据,通过大 5 同上 同上 发 现 迭 代 中 的 沟 力,包括但不限 数据分析,在 通、设计等各类问 于产品规划、建 用 户 功 能 验 题,并进行持续改 设、运营、人力、 收 和 用 户 体 进。 绩效、核算等。 验 时 作 为 辅 敏捷团队以业务 助决策依据, 价值为核心以运 持 续 优 化 改 营为驱动的敏捷 进。 8
12. 工作模式,企业 为 团 队 提 供 IT 基础设施、基础 管理等支持。 7 迭代计划管理 迭代计划管理是产品经理和开发团队进行需求的沟通、传递和规划的过程,包括需求澄清和拆解、 故事和任务排期、计划变更三个部分,要求产品经理和团队以业务价值的快速实现为目标,通过面对面 的沟通、制定约定、共同决策等方式,增强需求沟通、传递和规划的有效性。 7.1 需求澄清 需求澄清是产品经理和开发团队沟通和确认需求的过程,包含沟通和明确用户故事的细节(包括但 不限于背景信息、UI和交互设计、测试要点等),确定用户故事的技术实现方案,识别技术风险和依赖, 团队对用户故事进行任务拆分,产品经理和团队对于以上信息达成共识,明确用户故事完成的定义。 需求澄清主要体现在三个方面: 1)需求澄清的时间:指需求澄清发生在研发过程中的合适的阶段,以便适应研发过程中的变化及开 发团队工作的开展。 2)需求澄清内容的完备性:指在需求澄清过程中,是否澄清需求的所有内容。 3)需求澄清协作:指产品经理、开发团队及其他干系人如何协作开展澄清工作。 级别 1 2 3 4 需求澄清的 时间 在项目初 期,一次性 递交需求规 格说明书 在迭代开始 之前进行需 求澄清 同上 同上 主要工作完备性 内容的完备性 协作 需求规格说明 契约式文档传递 书内的内容 产品经理对于 用户故事的内 容进行讲解, 召开需求澄清会 并解答团队提 出的问题 同上且团队确 定用户故事的 实现方案,识 团队内的需求澄清 别技术风险, 会,团队间的需求 识别需求间的 澄清会。 依赖和团队间 的依赖。 同上且产品经 同上 人员机制 无 无 无 无 工具能力 备注 无 无 无 企业提供的 9
13. 理和团队对于 需求细节和验 收标准达成共 识,将关键信 息进行记录和 确认。 5 同上 同上 同上 统一的协作 型需求沟通 工具,便于团 队在澄清过 程中能快速 进行关键信 息的更新和 记录。 企业采用扁平化 的敏捷团队组织 架构,赋予团队 围绕产品自组 织、自管理的权 力,包括但不限 于产品规划、建 设、运营、人力、 同上 绩效、核算等。 敏捷团队以业务 价值为核心以运 营为驱动的敏捷 工作模式,企业 为 团 队 提 供 IT 基础设施、基础 管理等支持。 7.2 故事与任务排期 敏捷开发将开发过程分为多个短冲刺,故事与任务的排期过程就是确定迭代冲刺目标的过程,根据 产品待办列表中用户故事的优先级、依赖关系、故事规模和团队速度,确定迭代待办列表,迭代待办列 表确定之后,团队成员根据优先级认领故事和任务。主要体现在三个方面: 1)排版要素:指进入排版时,信息的完备性,例如产品待办列表中用户故事的优先级、依赖关系、 故事规模和团队速度等。 2)排版容量:指排版容量的大小有据可依,根据实际用户故事规模和团队速度并考虑其他影响因 素后确定。 3)排版管理:指排版活动的组织形式。 级别 1 排版要素 产品待办清 单,对产品 待办清单内 容的完备性 不做要求 主要工作完备性 排版容量 排版管理 由产品经理和 团队负责人根 据实际需要确 定,无确切依 据 命令式管理,团队 根据产品经理和团 队负责人的要求工 作。 人员机制 无 工具能力 无 备注 10
14. 有固定的排版活 产品待办清 动,约定为迭代开 单中用户故 始前的固定时间, 事 内 容 完 团队进行用户 排版活动不仅确定 备、优先级 故 事 规 模 估 迭代目标,同时确 2 无 无 确定,用户 算,具备团队 定迭代待办列表的 故事间的依 速度的参考值 优先级,便于团队 赖关系确 在迭代开始后根据 定。 优先级顺序进行开 发 同上且具备多团队 排版活动,多团队 一起排版时,识别 同上且具备用 出团队间存在依赖 3 同上 户故事规模估 的用户故事,约定 无 无 算标准 用户故事的优先 级,对于需要对齐 发布周期的团队, 进行对齐。 具备工具支 撑在线排版 活动,能自动 识别任务间 的依赖,支持 团队间依赖 管理,能实现 4 同上 同上 同上 无 任务的自动 流转等,对于 需要进行团 队对齐的情 况,能自动实 现团队的对 齐。 企业采用扁平化 的敏捷团队组织 架构,赋予团队 围绕产品自组 5 同上 同上 同上 织、自管理的权 同上 力,包括但不限 于产品规划、建 设、运营、人力、 绩效、核算等。 敏捷团队以业务 11
15. 价值为核心以运 营为驱动的敏捷 工作模式,企业 为 团 队 提 供 IT 基础设施、基础 管理等支持。 7.3 计划变更 计划变更是指在迭代过程中,迭代目标发生变化,“响应变化胜过遵循计划”是敏捷的核心价值观 之一,但进入迭代的内容发生变化会影响研发团队的工作效率,所以需要采取措施尽量减少计划变更的 负面影响。主要体现在三个方面: 1)变更决策:是指决定变更和接受变更的决策方式; 2)应对变更:是指接受变更后,是否具备措施减少变更的影响; 3)减少变更:是指是否具备措施减少变更的发生。 级别 1 2 3 变更决策 产品经理提 出变更请 求,变更委 员会(通常 为一个由需 求、开发等 团队负责人 组成的虚拟 组织)进行 审批,决定 是否接受变 更。 产品经理和 团队约定计 划变更的流 程,产品经 理提出变更 请求后,与 团队沟通, 共同决定是 否进行计划 变更 同上 主要工作完备性 应对变更 无 无 发生需求变更 时,团队成员 无 决定置换的用 户故事。 团队具备应对 无 措施,减少变 减少变更 人员机制 工具能力 备注 无 无 无 无 无 无 12
16. 4 同上 5 同上 更带来的影 响,例如:用 户故事拆分 时,充分考虑 其独立性,减 少需求变更影 响的团队范 围;团队在开 发过程中,按 照用户故事优 先级进行开 发;需求置换 时,以小换大, 即换入的用户 故事规模原则 上应小于换出 的故事规模; 优先置换出低 优先级的需 求;不能置换 出半成品。 在产品规划阶段, 具备减少变更带来 影响的措施,例如: 产品待办列表的梳 理应该贯穿于产品 生命周期的始终, 始终确保高优先级 同上 的需求优先被处 无 无 理,从而减少进入 迭代以后的变更次 数;根据经验,预 留开发资源;具备 较早的识别变更的 能力,确保变更更 早的发生。 敏捷团队围绕公司 企业采用扁平化 战略工作,在产品 的敏捷团队组织 规划、研发、发布 架构,赋予团队 同上 各层面具备灵活反 围 绕 产 品 自 组 无 应的能力,可支撑 织、自管理的权 业务价值驱动下的 力,包括但不限 灵活的计划变更, 于产品规划、建 13
17. 建立应对风险的能 力。 设、运营、人力、 绩效、核算等。 敏捷团队以业务 价值为核心以运 营为驱动的敏捷 工作模式,企业 为 团 队 提 供 IT 基础设施、基础 管理等支持。 8 敏捷过程管理 敏捷过程管理包括迭代管理、迭代活动、过程可视化及流动、度量分析四个部分,主要体现开发团 队的研发过程的敏捷性,包括开发团队的节奏感、仪式感、透明化、持续改进等方面。 8.1 迭代管理 迭代管理,即贯穿于产品研发过程中以保持恒定的时长为周期,每个周期都遵从相同的框架过程, 并且交付潜在的可发布最终产品增量。迭代管理主要体现在以下三个方面: 1)敏捷迭代周期:指团队能约定迭代时长、交付时长; 2)迭代协作机制:指团队内或团队间的工作进行相互配合,使得产品开发能快速交付; 3)迭代流程改进:指团队能通过不断检视迭代过程,对发现的问题能持续改进。 敏捷开发管理中,迭代管理根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下: 级别 1 2 主要工作完备性 迭代时间周期 迭代协作机制 迭代流程改进 产品分多次迭 代开发,每次迭 代中按照需求 分析、设计、开 无 发、上线等线性 过程进行管控, 在下次产品完整 研发过程进行改 进调整 完成产品部分 功能 团队能定义清 晰的活动时间、 团队约定任务 场所、参加人 迭代过程问题能 迭代周期,约定 员;定义各类角 以用户故事形式 交付周期 色,明确分工, 进行改进 约定协作模式; 约定环节间交 人员机制 无 无 工具能力 无 无 备注 14
18. 付物、流转规 则。 团队内约定同 团队内约定同 上,团队间建立 上,团队间能对 协同工作机制, 3 齐迭代计划、时 同上 如通过团队间 间、产品集成发 的敏捷改进会 布时间 议来推进协作。 4 同上 同上 同上 5 同上 同上 同上 无 无 能在团队间工 作对齐、角色 管理、角色工 作安排、团队 协作、流程数 据可视化等方 无 面提供工具支 持。工具平台 具备提供迭代 过程的相关数 据、进行分析 的能力。 企业采用扁平化 的敏捷团队组织 架构,赋予团队围 迭代计划与企 绕产品自组织、自 业 战 略 相 结 管理的权力,包括 合,建立企业 但不限于产品规 级敏捷支撑平 划、建设、运营、 台,提供从战 人力、绩效、核算 略规划、产品 等。敏捷团队以业 规划实施、产 务价值为核心以 品交付整个价 运营为驱动的敏 值链可视化展 捷工作模式,企业 示、数据分析 为团队提供 IT 基 的能力。 础设施、基础管理 等支持。 8.2 迭代活动 敏捷迭代活动,是指从产品规划、研发过程、产品交付、持续改进等维度来定义的产品迭代研发中 的一系列过程,目的在于推进敏捷迭代团队的持续改进和产品的快速交付。迭代活动主要体现在以下三 个方面: 1)迭代活动约定:是指团队能能在约定的时间、相对固定的场所举行相关活动; 2)迭代活动时间约定:是指团队能按照约定的时间长短进行各种会议; 15
19. 3)迭代活动范围:是指团队能在各类敏捷会议中遵守约定的会议内容。 敏捷开发管理中,迭代活动根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下: 级别 1 2 3 4 主要工作完备性 迭代活动时间 迭代活动约定 迭代活动范围 约定 产品分多次迭 代开发,每次迭 代中按照需求 分析、设计、开 时 间 根 据 会 议 发、上线等线性 内容确定,无约 过程进行管控, 定长短 不同阶段的输出 物评审 按照契约方式 进行各类评审 工作 团队能在迭代 内按照约定时 间点分别完成 产品计划会议、 各 种 会 议 能 严 按照各类会议的 迭代计划会议、 格 按 照 约 定 时 要求,控制会议 每日站立会、迭 间盒内进行 内容 代交付评审会 议、改进回顾会 议。 团队内工作方 式同上,跨团队 的敏捷产品开 发中,多团队间 建立更高级别 的迭代,具有跨 团队的产品代 能对跨团队的 办列表。团队间 产 品 按 照 约 定 定 期 举 行 跨 团 时间、节奏进行 同上 的计划会、评审 验收评审会议。 会议、回顾会 议。能不定期召 开团结间协调 推进会议。能对 跨团队的协同 问题跟进落地 实施。 在 上 一 级 的 基 同上 同上 人员机制 工具能力 根据内容确定相 无 关参与人员 产品经理、团队共 无 同参与 具备跨团队的敏 捷推进协调组织, 由产品经理、团队 无 成员、跨团队的约 定参与人员、及其 它干系人 同上 无 备注 16
20. 础上,在约定周 期内开展跨团 队的敏捷推进 会议 在上一级的基 础上,建立企业 级敏捷活动推 进组织,从组织 5 文 化 、 产 品 规 同上 划、人力成本等 多个方面进行 协同推进敏捷 持续改进 同上 企业采用扁平化 的敏捷团队组织 架构,赋予团队围 绕产品自组织、自 管理的权力,包括 但不限于产品规 划、建设、运营、 人力、绩效、核算 无 等。敏捷团队以业 务价值为核心以 运营为驱动的敏 捷工作模式,企业 为团队提供 IT 基 础设施、基础管理 等支持 8.3 过程可视化及流动 通过对敏捷迭代过程的可视化展示,实时反映用户故事的迭代进展,体现产品从需求、研发、交付 端到端的价值流动,通过在制品数量等工具实现价值流动的拉动式管理。过程可视化及流动主要体现在 以下三个方面: 1)过程可视化:通过各种数据记录,反馈敏捷开发过程质量; 2)过程价值流动:通过各种工具体现敏捷过程的业务交付价值流动过程; 3)迭代过程改进:对数据反映的各种问题,不断改进迭代过程。 敏捷开发管理中,过程可视化及流动根据以上三个方面所能达到的不同程度分为以下5个等级,具 体如下: 级别 1 2 3 主要工作完备性 过程可视化 过程价值流动 迭代过程改进 注重结果数据, 过程数据跟踪 无 无 较弱 团队级迭代内 的过程数据进 行跟踪记录,并 无 无 进行可视化管 理 满足迭代数据 无 无 人员机制 无 无 无 工具能力 备注 无 无 通过可视化的 17
21. 可视化的基础 管理工具,对 上,实现端到端 产品需求收 的可视化管理 集,分析,产 品故事优先 级,迭代用户 故事优先级等 内容进行管 理,实时反馈 需求管理的进 展 在满足前一级 通过端到端的 别的基础上,从 可视化,实现产 产品规划到产 品研发的拉到 能建立持续反馈 4 无 品 运 营 全 生 命 式管理,能暴露 机制,持续改进 周 期 的 可 视 管 过程中的问题, 通过如看板等 工具进行可视 化管理 理 管理价值流动 企业采用扁平化 的敏捷团队组织 架构,赋予团队围 在扁平化组织 绕产品自组织、自 架构下,由企 管理的权力,包括 业提供过程可 但不限于产品规 视 化 管 理 平 划、建设、运营、 台,可视化产 5 同上 同上 同上 人力、绩效、核算 品从用户价值 等。敏捷团队以业 提出到交付的 务价值为核心以 完整过程,提 运营为驱动的敏 供数据支撑, 捷工作模式,企业 建立反馈,持 为团队提供 IT 基 续优化改进 础设施、基础管理 等支持 8.4 度量分析 度量分析是对迭代过程中研发效率、质量数据进行分析,反映过程的健康程度;通过对产品端到端 指标数据进行分析,实时反映产品的表现。驱动敏捷迭代的过程改进,推动企业组织架构、人员结构、 财务制度等方面进行不断优化。使用敏捷迭代的方式推进改进措施的实施。度量分析主要体现在以下三 个方面: 1)度量的粒度:是指敏捷迭代分析度量的详细程度; 2)度量的范围:是指分析度量涉及人员组织,范围大小; 3)度量驱动持续改进:是指在分析发现问题后,能不断进行落地改进。 敏捷开发管理中,度量分析根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下: 18
22. 级别 1 2 3 4 5 主要工作完备性 度量粒度 度量范围 度量驱动持续 改进 能对团队结果 数据指标进行 分析跟踪。没有 形成有效的过 程指标分析跟 踪支持 团队内 能对产品研发中 质量问题进行分 析,形成分析报 告,对改进措施 的落地推进较弱 在敏捷团队中, 能对迭代过程 能对团队敏捷过 指标进行分析, 程发现的问题, 从交付质量、交 团队内 付速度等方面 形成团队代办任 务,以敏捷迭代 进行分析,反映 的方式实施改进 研发过程的健 措施 康程度 在团队级的基础 在团队级的基 础上,能围绕产 品的完整生命 周期,从需求提 团 队 内 及 团 队 出、研发、交付、 间 运营反馈等建 立指标分析体 系 上,建立跨团队 的产品级回顾会 议,在会议上对 多团队的迭代对 齐问题,人员技 能等问题进行分 析,形成解决方 案,以迭代的方 式持续推进解决 方案落地实施 同上 同上 在产品级回顾会 议上能以平台数 据为支撑,分析 敏捷过程的问 题,制定改进计 划,以迭代的方 式持续改进 同上 企业级 以企业级平台数 据为支撑,从战 略角度分析敏捷 实施过程的问 人员机制 无 无 无 无 企业采用扁平化 的敏捷团队组织 架构,赋予团队围 绕产品自组织、自 工具能力 无 无 无 能通过平台支 撑产品从需求 到交付的端到 端的过程指标 展示,提供指 标数据的报表 分析能力,能 从数据中分析 发现协作的问 题 建立企业级工 具平台,能通 过平台指标数 据反映产品研 备注 19
23. 题,推动企业在 组织架构、人员 结构、财务制度 等方面进行持续 改进 管理的权力,包括 发、公司战略、 但不限于产品规 资金使用、组 划、建设、运营、 织效能等方面 人力、绩效、核算 的问题 等。敏捷团队以业 务价值为核心以 运营为驱动的敏 捷工作模式,企业 为团队提供 IT 基 础设施、基础管理 等支持 20