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

所需积分/C币:22 2017-11-21 11:39:49 804KB PDF

本标准规定了研发运营一体化的敏捷开发管理过程及相关能力成熟度模型。本标准中的研发运营一 体化包括IT软件及服务的需求、开发、测试、部署和运营五个环节, 并实现敏捷开发、持续交付和技术 运营的顺序闭环集成。
DB XXXXX-XXXX 前言 研发运营一体化是指在IT软件及相关服务的研发及交付过程中,将应用的需求、开发、测试、部 署和运营统一起来,基于整个组织的协作和应用架构的优化,实现敏捷开发、持续交付和应用运营的无 缝集成。帮助企业提升II效能,在保证稳定的同时,快速交付髙质量的软件及服务,灵活应对快速变 化的业务需求和市场环境。 本标准是“研发运营一体化能力成熟度模型”系列标准的第?部分,该系列标准的结构和名称如 第1部分:总体架构 ■第2部分:敏捷开发管理过程 第3部分:持续交付过程 第4部分:技术运营过程 第5部分:应用架构 第6部分:组织结构 本标准按照GBT1.1-2009给出的规则起草 本标准由中国通信标准化协会提出并归口 本标准起草单位:中国移动浙江公司、 DevOps时代社区、高效运维社区、中国信息通信研究院 本标准主要起草人:方炜、李海传、廖希密、张乐、景韵、萧田国、栗蔚 研发运营一体化能力成熟度模型 第2部分:敏捷开发管理过程 范围 本标准规定了研发运营一体化的敏捷开发管理过程及相关能力成熟度模型。本标准中的研发运营 体化包括Iˆ软件及服务的需求、开发、测试、部署和运营五个环芍,并实现敏捷开发、持续交付和技术 运营的顺序闭环集成 本标准适用于全业在实施TT软件开发和服务过程中实现研发运营一体化架构,提升TT效能 2规范性引用文件 下列文件中的条款通过本部分的引用而成为木部分的条款。凡是注日期的引用文件,仅所注日期的 版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。 [1]GB/T32400-2015信恳技术云计算概览与词汇 [2]GB/T32399-2015信息技术云计算参考架构 [3]YD/T2441-2013互联网数据中心技术及分级分类标准 [4]GB/T33136-2016信息技术服务数据中心服务能力成熟度模型 3术语 下列术语和定义适用于本文件 3.1黄金圈 gol den circle 全称为黄金思维圈,及先思考Why(目的、理念),冉考虑How(方法和措施),最后才是WhaL(现 象和成果)。 3.2用户故事 user stor y 从用户的角庋来描述用户渴望得到的功能。 3.3用户故事地图 user story mapping 将用户故事按定顺序和优先缴排列以分析与识别最小可行产品。 34影响地图 i mpact mapping 是一种用户需求分析的方法,通过Why,Wo,How,Wha逐层分析需求。 3.5AB测试 ab test 为Web或App界面或流程制作两个(AB)或多个(A/B/n)版本,在同一时间维度,分别让组成成分 相同(相似)的访客群组随机的访问这些版本,收集各群组的用户体验数据和业务数据,最后分析评估 出最好版本正式采用 4缩略语 下列缩略语适用于本文件 Continuous integration 持续集成 CD Continuous Delivery 持续交付 MVP Most variable product 最小可行产品 INVEST Independent, Negotiable, Valuable, Estimable,Sma11, Testable独立的,可讨论 的,有价值的,可估算的,小的,可测试的 DEEP Principle Detailed Appropriately, estimated, Emergent, Prioritized principle ie 当细化的,有估算的,随吋产生的,有优先级的原贝 User interface 用户界面 5综述 敏捷开发管理是种新的软件开发方法,它不同于传统的瀑布式开发,以用户的需求进化为核心 釆用迭代、循序渐进的方法进行软件开发,关注有序迭代、灵活响应以及价值的快速交付,分为需求管 理、计划管理、过程管理三个维度。 敏捷开发管理 敏捷需求管理迭代计划管理敏捷过程管理 需求收集 需求澄清与拆解 迭代管理 需求分析 故事与任务排期 迭代活动 需求与用例计划变更 过程可视化及流动 需求验收 度量分析 图1敏捷开发管理 6敏捷需求管理 敏捷需求管理包括需求收集、需求分析、需求与用例、需求验收四部分内容,体现需求管理过程中 的收集、分析、测试、验收四个阶段,敏捷的需求管理的能力主要体现在各个环节中使用敏捷旳方法探 寻产品痛点、业务价值、用户体验的能力,适应需求变化的能力,快速验证反馈的能力。 6.1需求收集 需求收集环节是需求提岀方和产品经理之间明确产品需求的阶段,是产品研发运营·伓化最初始阶 段,把产品的需求具象化,形成待办事项列表的过程。 需求收集环节包括三个方面工作 1)明确单个需求点:即以问题驱动为核心,探索问题核心相关事项的过程; 2)梳理需求全貌:应能列出为了落实产品的愿景而需要完成的所有享项,即待办事项列表 3)确定待办事项列表:应包括用户需求所涉及的所有事项,并且作为产品研发路线图。 敏捷开发管理中,需求收集环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如 下 主要工作完备性 级别 单个需求点需求全貌需求的管理 人员机制 工具能力备注 应能明确需 应梳理所有 求问题,角需求问题, 应有模板和规范,并 定明确的功|形成需求说 在形成需求说明书之 能点需求要}明书,涵盖|后的需求沟通、实施无 无 过程中应采用契约的 所有的需求 求 功能要求方式传递。 需求提出方和产 品经理应有明确 应通过协作 的需求收集流 应有待办事需求应在需求进入迭程,制定了快速 方式形成适 当详细的需 项列表来管代开发之前可以进行沟通协作机制,无 理需求 变更和细化 求说明。 例如明确规定计 划和需求之间的 流转和协作方法 和规范。 同上且产品经理对提 需求提出方 出的需求在产品演进 和产品经理 过程中持续细化和演 应通过需求 同上 同上 进,形成产品路线图。 例如,采用精益产品同上 收集可视化 工具,归集到 的方法、景响力地图 待办事项列 MVP的方法等敏捷方 表,由产品经 法等。 理统一管理。 同上且需求提出 方和产品经理之间上有协 作型需求沟 间的机制应不限 定时间和角色 通工具,在需 保证需求随时入 求提出、收 和出。例如,建 集、分析、实 上 上 同上 立运营驱动需求 施过程中,各 的体系,在产品角色随时沟 通都能对需 演进过程中,不 求内容进行 不断优化和整持演进和 待办列表的顺 细化。 同上且建立需求快速同上且企业采用同上且使用 同上 同上 上线、快速反馈流程,扁平化的敏捷闭企业提供的 用户反馈能怏速收队组织架构,赋统一的需求 集 予团队围绕产品收集工具、协 自组织、自管理作型需求沟 的权力,包括但通工具,归集 不限于产品规到待办事项 划、建设、运营、列表,由产品 人力、绩效、核经坦统一管 算等。例如,敏理,能够俣证 捷团队以业务价需求随时入 值为核心以运营和出,并在需 为驱动的敏捷工求提出、收 作模式,企业为集、分析、实 团队提供IT基施过程中,随 础设施、基础管时沟通都能 理等支持。 对需求内容 进行持续演 进和细化 6.2需求分析 需求分析是产品经理将需求细化和拆解成用户故事的过程,主要体现三个方面: 1)明确需求内容和形式:需求分析形成用户故事,用户故事描述用户场景; 2)需求分析协作:用户故事是适度详细并适应变化的,可以在开发过程中对其进行评估不断细化; 3)需求管理方式:用户故事统一管理,并按照业务价值由高到低排定优先级。 敏捷开发管理中,需求分析环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如 主要工作完备性 级别 需求内容和形式需求协作需 需求的管理人风机制 工具能力 备注 需求分析人员 需求分析形成软在完成需求规 件需求规格说明|格说明书的编「通过需求规格 书,作为需求提写后离场,开说明书统一管无 无 出方和实施方之发团队按照需理。 间的契约 求规格说明书 进行开发。 需求分析形成用迭代开始前, 应使用产品待 户故事,用户故由产品经理 办列表和迭代 事规模适中,可需求提出方开 无 无 待办列表管 在一个迭代内完发团队一起细 理 成 化用户故事。 用户故事符合在软件过程的同上且当发生 INVEST标准:1)任何阶段,产规模型产品研无 故事是独立完整品理、需求发情况,应建 的,2)故事是可提出方及团队立跨团队的产 协商并细化的,成员可对用户品待办列表, 3)故事是有业务故事进行变更选代待办列表 价值的,4)故事和细化 是能评估工作量 和优先级的,5) 故事是足够小 的,一般在1-2 日内完成,6)故 事是可测试的 同上且产品待 办列表应符合 同上且应具备可同上且当发生 DEP原则:1 适当的详细描 视化的WP的产跨团队的产品 品滨进路线,管研发情况,应 述的,优先级 应建立特性型研有协作型用 越高越详细明 理用户枚事和发建立史诗故 布选代关系,可事、特性故事 确,2)用丝/发团队,与产品户故事沟通 以使用例如:用用户故事的分 点 进行估算过/经理合作提升需工具、产品待 求分析落地的价办列表管理 户故事地图、影层管理,可跨 大小的,3)随 着产品演进不/值流动 工具。 响力圯图等敏捷团队进行需求 方法。 断涌现和变化 拆解细化 的,4)优先级 从高到低排序 的 同上且企业采用 同上且应建立扁半化的敏捷团 需求与企业级/队组织架构,赋 活动关联,把 予团队围绕产品 自组织、自管理 企业战略和目 标通过愿景 的权力,包括但 目标,关键/不限于产品规 果、任务,/划、建设、运营、同上且应建 同上 同上 人力、缋效、核 立企业级的 估、反馈等环 需求管理工 算等。敏捷团队 实现企业、团以业务价值为按/具。 节进行分解 队、个人三个 心以运营为驱动 层次对齐,达 的敏捷工作模 到需求的业务 式,企业为团队 价值最大化。/提供T基础设 施、基础管理等 支持 6.3需求与用例管理 需求与用例管埋是指产品经坦和开发团队把用户故事的验收标准和测试用例进行关联性,能验收产 品功能是否满足用户故事的要求的过程。主要体现在三个方面: 1)梳理需求用例:编写需求验收标准,形成测试用例的过程 2)使用需求用例:需求用例指导需求开发,验证产品功能的过程; 3)管理需求用例:建立需求与用例的统一管理库,持续的使用和优化 敏捷开发管理中的需求与用例管理环节,根据以上三个方面所能达到的不同程度分为以下5个等级, 具体如下 主要工作完备性 级别需求与用例 需求用例验证需求与用例的管理人员机制 工具能力备注 编写 测试用例与 测试用例在本需求 需求没有关 功能测试完成后没 联,测试用 无 有做归档重用,在无 无 例在设计结 束代码开发 每次有新需求重新 设计测试用例。 阶段完成 测试用例与 需求文档和测试用 例应作为知识沉淀 用户故事应每次上线前应 有关联,测把编写的测试 下来,当设计现有 2 试用例在需用例全部验证 产品进行功能优化 无 求分析结束通过,才可上/的需求时,需求文 无 设计阶段完线。 档和测试用例在现 有的知识上进行调 成 整优化。 测试用例应作为产 品的软件代码资产 存在,所有的功能 上线都以能测试用 例验证通过为目 测试用例能 上 同上 通过工具自 标,每次迭代上线 动执行。 都必须执行产品沉 淀下的所有测试用 例,直到验证和修 复通过才可上线。 同上且产品 同上且需求作为需 的需求在最 求用例库作为产品 初始阶段即 的软件代码资产存 转化为测试同上 在,既保持可渎性|无 同上 用例,细化 又作为用例在产品 需求编写验 达代更新中一直保 收标准过程 持完整和准确。 6 即编写测试 同上且所有的功能 用例的过 上线都以能被可读 程 的需求用例验证通 过为目标,每次迭 代上线都必须执行 沉淀下的所有的需 求用例,直到验证 和修复通过才可上 线 当产品进行升级重 构时,产品的需求 用例厍无需重建就 能作为升级重构后 的验收标准。 需求应具备可 企业采用扁平化 阅读的文档和 的敏捷团队组织 应建立企业 测试验证的实 架构,赋予闭(/级可视化便 捷的半台,管 例两种特性, 围绕产品自组 理需求文档, 通过建设企业 织、白管理的权 且可以通过 级可视化便捷 力,包括但不限 需求文档能 的平台,建立 于产品规划、建 查看产品的 从用户故事排 同上 设、运营、人力、 入达代开发、同上 绩效、核算等。全貌,且通过 敏捷团队以业务 平台,需求提 开发完成后作 为测试验收测 价值为核心以运 出人、最终使 用人、产品经 试、部署到生 营为驱动的敏捷 产即作为生产 工作模式,企业 理、开发运维 人员进行更 验收测试,整 为团队提供IT 个过程的全白 基础设施、瑟础/好的沟通和 协作 动化模式。 管理等支持。 6.4需求验收 需求验收是指产品经理、需求提出者和最终用户对产品的功能验收,要求能对需求进行快速测试、 快速确认、快速反馈、快速优化。本节的需求验收,仅是指功能验收,非功能测试不在本节的范围内。 需求验收主要体现在以卜三个方面: 1)需求验收的频率:指不同角色对需求功能验收的频率,频率越高效果越好 2)需求验收的范围:指需求验收应尽量具备有业务价值的端到端的验收 3)需求验收的反馈效率:指需求验收的结果能准确、快速的反馈到开发团队的过程。 敏捷开发管理中,需求验收环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如 级别 主要工作完备性 「人员机制工具能力备注

...展开详情

评论 下载该资源后可以进行评论 1

zhaoxiao 有效资源,不错,不过为什么要分成一章一章的下载,好麻烦
2017-11-30
回复
img
caesar_wind

关注 私信 TA的资源

上传资源赚积分,得勋章
最新资源