研发运营一体化能力成熟度模型敏捷开发管理.docx

1、研发运营一体化能力成熟度模型敏捷开发管理研发运营一体化（DevOps）能力成熟度模型第 2 部分：敏捷开发管理The capability maturity model of DevOpsPart 2: Agile management process前言 III1范围 12规范性引用文件 13术语 13.1用户故事 user story 13.2用户故事地图 user story mapping 13.3影响地图 impact mapping 13.4AB 测试 ab test 14缩略语 25敏捷开发管理 26敏捷需求管理 26.1需求分析 26.1.1需求内容和形式 26.1.2需求分析

2、协作 36.1.3需求管理 36.2需求与用例管理 46.2.1需求与用例编写 46.2.2需求用例验证 46.2.3需求与用例管理 47敏捷计划管理 57.1价值交付 57.1.1交付与需求 67.1.2交付质量 67.1.3交付反馈与度量 67.2交付过程管理 77.2.1交付计划 77.2.2交付活动 77.2.3价值流动 77.2.4人员组织 78敏捷协作管理 88.1产品经理和团队 98.1.1协作内容 98.1.2协作机制 98.2团队和团队 98.2.1协作内容 98.2.2协作机制 98.3干系人和团队 108.3.1协作内容 108.3.2协作机制 10附 录 A （规范性附

3、录） 五级度量指标定义 12参考文献 13表 1 敏捷开发管理 2表 2 需求分析 3表 3 需求与用例管理 4表 4 价值交付 6前 言研发运营一体化是指在IT软件及相关服务的研发及交付过程中，将应用的需求、开发、测试、部署和运营统一起来，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的无缝集成。帮助企业提升IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速变化的业务需求和市场环境。本标准是“研发运营一体化（DevOps）能力成熟度模型”系列标准的第 2 部分 敏捷开发管理，该系列标准的结构和名称如下:第1部分：总体架构第2部分：敏捷开发管理第3部分：

4、持续交付第4部分：技术运营第5部分：应用架构第6部分：风险管理第7部分：组织结构研发运营一体化（DevOps）能力成熟度模型第 2 部分：敏捷开发管理1范围本标准规定了研发运营一体化（DevOps）能力成熟度模型下敏捷开发管理过程的能力成熟度要求和评价方法。本标准适用于：a)具备 IT 软件研发交付运营能力的组织实施 IT 软件开发和服务过程的能力进行评价和指导；b)可供其他相关行业或组织进行参考；c)可作为第三方权威评估机构衡量软件开发交付成熟的标准依据。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版

5、本（包括所有的修改单）适用于本文件。1GB/T 32400-2015信息技术 云计算 概览与词汇2GB/T 32399-2016信息技术 云计算 参考架构3YD/2441-201343 术语GB/T 33136-2016信息技术服务数据中心服务能力成熟度模型下列术语和定义适用于本文件。3.1用户故事 user story从用户的角度来描述用户期望得到的功能。3.2用户故事地图 user story mapping将用户故事按一定顺序和优先级排列以分析与识别最小可行产品。3.3影响地图 impact mapping是一种用户需求分析的方法，通过Why,Who,How,What逐层分析需求。3.4

6、AB 测试 ab test为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。4缩略语下列缩略语适用于本文件。CI Continuous Integration 持续集成CD Continuous Delivery 持续交付UI User Interface 用户界面MVP Minimum Viable Product 最小可行产品INVEST Independent, Negotiable，Valuable，Estimable，Smal

7、l，Testable 独立的，可讨论的，有价值的，可估算的，小的，可测试的DEEP Principle Detailed Appropriately，Estimated，Emergent，Prioritized principle 适当细化的，有估算的，随时产生的，有优先级的原则UI User Interface 用户界面5敏捷开发管理敏捷开发管理，是一种应对快速变化的需求的新型软件开发方法。它更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而 自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，主张适度的计划、进化开发、提前交付与持续改进，并且

8、鼓励快速与灵活的面对开发与变更，更注重软件开发过程中人的作用1。分为敏捷需求管理、敏捷计划及交付管理、敏捷协作管理三个维度，每个维度细分为不同能力子项，如表1所示。表1 敏捷开发管理敏捷开发管理敏捷需求管理敏捷计划及交付管理需求分析价值交付产品经理和团队需求与用例交付过程管理团队和团队需求验收团队和干系人6敏捷需求管理敏捷需求管理包括需求分析、需求与用例、需求验收三部分内容，体现需求管理过程中的分析、测试、验收三个阶段，敏捷需求管理主要体现在各个环节中使用敏捷方法探寻产品痛点、业务价值、用户体验的能力，适应需求变化的能力，快速验证反馈的能力。6.1需求分析需求分析是指需求提出方和产品经理之间明

9、确产品需求的阶段，是产品研发运营一体化最初始阶段，把产品需求具象化，形成待办事项列表的过程。主要包括需求内容和形式、需求分析协作和需求管理三方面工作，如表 2 所示。6.1.1需求内容和形式1 维基百科 zh.Wikipedia.org/wiki/敏捷软件开发需求分析是将用户需求划分为最小需求条目，并探索问题核心相关事项的过程。（如：用户故事，以下内容统称为用户故事），用户故事描述用户场景，且能适应在开发过程中对其进行评估、不断细化等变化。6.1.2需求分析协作需求分析是各个角色沟通协作形成并细化的过程，协作过程需要各角色深入且持续参与。6.1.3需求管理需求分析后的用户故事应包括用户需求所涉

10、及的所有事项，统一管理并按照业务价值由高到低排定优先级，并依据用户需求形成产品研发路线图。敏捷开发管理中，需求收集环节根据以上三个方面所能达到的不同程度分为以下 5 个等级，具体如下：表2 需求分析级别需求内容和形式需求分析协作需求的管理1需 求分析 形成需 求文档，作为需求提出方和实施方之间的契约。在软件开发过程中允许在变更流程执行后进行变更。需求提出方、需求分析人员在完成需求文档的编写后，由开发团队按照文档进行设计开发。有变更流程，需求提出方、需求分析人员可以通过流程变更需求内容。需求有收口统一管理。2需求分析 形成用 户故事，用户故事需符合：1）用户故事在软件开发过程中是可协商并细化的；

11、2）规模适中，可在一次发 布周期 的时间 内完成；3）工作量可评估、有优先级划分。在用户故事进入开发周期前，由产品经理、需求提出方、开发团队一起细化用户故事。产品经理使用产品待办列表统一管理用户故事，且通过用户故事优先级排入发布计划。3同 上且用 户故事 符合INVEST 标准：1）故事是独立完整的；2）故事是可协商并细化的；3 ） 故事是有业务价值的，能做价值评估；4）故事是能评估工作量和优先级的；5）故事是足够小的，例如：在 1-2 日内能完成；在需求收集、分析、开发、上线运营的任何阶段，需求提出方、产品经理、团队成员、运营人员、使用者等各角色都可随时对用户故事进行细化。且当发生规模型产品

12、研发情况，各个团队各角色能共同参与用户故事细化。同上且产品待办列表应符合DEEP 原则：1）适当的详细描述的，优先级越高越详细明确；2）用故事点进行估算过大小的；3）随着产品演进不断涌现和变化的；4）优先级从高到低排序的。且当发生规模型产品研发情况， 应建立跨团队的产品待办列表， 迭代待办列表。6）故事是可测试的。4同上且有提升需求价值的敏捷活动。例如：典型角色分析、影响地图、用户故事的层级化拆分等。同上且应建立改进需求分析协作的机制：1）应建立特性型的端到端产品研发运营团队，减少跨组织协作的必要性。2）应建立产品级回顾改进机制。例如，建立运营驱动需求的体系，在产品演进过程中，不断涌现需求，能

13、不断优化和调整待办列表的顺序。3）当发生跨团队的产品研发情况，应建立需求分析协作机制， 实现史诗故事、特性故事、用户故事的分层管理，可跨团队进行需求拆解细化。同上且产品经理对提出的需求在产品演进过程中持续细化和演进，形成场景化驱动和价值驱动的发布规划（如用户故事地图），以保持产品待办列表的价值最大化。例如，采用精益产品的方法、影响地图、MVP 等敏捷方法。有协作型用户故事沟通工具、产品待办列表管理工具。有数据收集和大数据分析需求价值和评估的工具，示例1：能收集用户交互操作的工具。5同上同上同上且应建立需求与企业级活动关联，把企业战略和目标通过愿景、目标、关键结果、任务、评估、反馈等环节进行分解

14、，实现企业、团队、个人三个层次对齐，达到需求的业务价值最大化。6.2需求与用例管理需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联，验收产品功能是否满足用户故事要求的过程。主要包括需求与用例编写、需求用例验证和需求与用例的管理三个方面，如表 3 所示。6.2.1需求与用例编写是指梳理需求用例，编写需求验收标准，形成测试用例的过程；6.2.2需求用例验证使用需求用例，需求用例指导需求开发，验证产品功能的过程；6.2.3需求与用例管理建立需求与用例的统一管理库，持续的使用和优化。敏捷开发管理中的需求与用例管理环节，根据以上三个方面所能达到的不同程度分为以下 5 个等级，具体如下：表3 需求与用例管理级别需求与用例编写需求用例验证需求与用例的管理1测试用例与需求关联较少，测试用例在设计阶段结束，代码开发阶段完成。无测试用例在需求功能测试完成后未做归档，无法重用。2建立测试用例与用户故事之间关联，测试用例在需求分析阶段结束，设计阶段完成。测试用例在发布线上环境前全部验证通过。同上3同上同上，且测试用例通过工具自动执行。测试用例作为软件资产管理，所有测试案例验证通过后，方可进行线上功能发布。4同上，且产品需求在最初始阶段进行实例化、形成验收标准，成为测试用例的依据，测试能和开发并行工作，形成