敏捷开发管理过程
Posted Starzhang
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了敏捷开发管理过程相关的知识,希望对你有一定的参考价值。
Part 2: Agile management process
研发运营一
体化包括IT软件及服务的需求、开发、测试、部署和运营五个环节,并实现敏捷开发、持续交付和技术
运营的顺序闭环集成。
适用于企业在实施IT软件开发和服务过程中实现研发运营一体化架构,提升IT效能。
3.2 用户故事 user story
从用户的角度来描述用户渴望得到的功能。
3.3 用户故事地图 user story mapping
将用户故事按一定顺序和优先级排列以分析与识别最小可行产品。
3.4 影响地图 impact mapping
是一种用户需求分析的方法,通过Why,Who,How,What逐层分析需求。
3.5 AB 测试 ab test
为Web或App界面或流程制作两个(A/B)或多个(A/B/n)版本,在同一时间维度,分别让组成成分相同(相似)的访客群组随机的访问这些版本,收集各群组的用户体验数据和业务数据,最后分析评估出最好版本正式采用
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 用户界面
敏捷开发管理是一种新的软件开发方法,它不同于传统的瀑布式开发,以用户的需求进化为核心,
采用迭代、循序渐进的方法进行软件开发,关注有序迭代、灵活响应以及价值的快速交付,分为需求管
理、计划管理、过程管理三个维度。
敏捷开发管理 |
||
敏捷需求管理 |
迭代计划管理 |
敏捷过程管理 |
需求收集 |
需求澄清与拆解 |
迭代管理 |
需求分析 |
故事与任务排期 |
迭代活动 |
需求与用例 |
计划变更 |
过程可视化及流动 |
需求验收 |
度量分析 |
图 敏捷开发管理
敏捷需求管理
敏捷需求管理包括需求收集、需求分析、需求与用例、需求验收四部分内容,体现需求管理过程中
的收集、分析、测试、验收四个阶段,敏捷的需求管理的能力主要体现在各个环节中使用敏捷的方法探
寻产品痛点、业务价值、用户体验的能力,适应需求变化的能力,快速验证反馈的能力。
需求收集
需求收集环节是需求提出方和产品经理之间明确产品需求的阶段,是产品研发运营一体化最初始阶
段,把产品的需求具象化,形成待办事项列表的过程。
需求收集环节包括三个方面工作:
1)明确单个需求点:即以问题驱动为核心,探索问题核心相关事项的过程;
2)梳理需求全貌:应能列出为了落实产品的愿景而需要完成的所有事项,即待办事项列表;
3)确定待办事项列表:应包括用户需求所涉及的所有事项,并且作为产品研发路线图。
敏捷开发管理中,需求收集环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下:
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
单个需求点 |
需求全貌 |
需求的管理 |
||||
1 |
应能明确需 求问题,制 定明确的功 能点需求要 求 |
应梳理所有 需求问题, 形成需求说 明书,涵盖 所有的需求 功能要求。 |
应有模板和规范,并 在形成需求说明书之 后的需求沟通、实施 过程中应采用契约的 方式传递。 |
无 |
无 |
|
2 |
应通过协作 方式形成适 当详细的需 求说明。 |
应有待办事 项列表来管 理需求。 |
需求应在需求进入迭 代开发之前可以进行 变更和细化。 |
需求提出方和产 品经理应有明确 的需求收集流 程,制定了快速 沟通协作机制, 例如明确规定计 划和需求之间的 流转和协作方法 和规范。 |
无 |
|
3 |
同上 |
同上 |
同上且产品经理对提 出的需求在产品演进 过程中持续细化和演 进,形成产品路线图。 例如,采用精益产品 的方法、影响力地图、 MVP 的方法等敏捷方 法等。 |
同上 |
需求提出方 和产品经理 应通过需求 收集可视化 工具,归集到 待办事项列 表,由产品经 理统一管理。 |
|
4 |
同上 |
同上 |
同上 |
同上且需求提出 方和产品经理之 间的机制应不限 定时间和角色, 保证需求随时入 和出。例如,建 立运营驱动需求 的体系,在产品 演进过程中,不 断涌现需求,能 不断优化和调整 待办列表的顺 序。 |
同上且有协 作型需求沟 通工具,在需 求提出、收 集、分析、实 施过程中,各 角色随时沟 通都能对需 求内容进行 持续演进和 细化。 |
|
5 |
同上 |
同上 |
同上且建立需求快速 上线、快速反馈流程, |
同上且企业采用 扁平化的敏捷团 |
同上且使用 企业提供的 |
需求分析
需求分析是产品经理将需求细化和拆解成用户故事的过程,主要体现三个方面:
1)明确需求内容和形式:需求分析形成用户故事,用户故事描述用户场景;
2)需求分析协作:用户故事是适度详细并适应变化的,可以在开发过程中对其进行评估不断细化;
3)需求管理方式:用户故事统一管理,并按照业务价值由高到低排定优先级。
敏捷开发管理中,需求分析环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下:
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
需求内容和形式 |
需求协作 |
需求的管理 |
||||
1 |
需求分析形成软 件需求规格说明 书,作为需求提 出方和实施方之 间的契约 |
需求分析人员 在完成需求规 格说明书的编 写后离场,开 发团队按照需 求规格说明书 进行开发。 |
通过需求规格 说明书统一管 理。 |
无 |
无 |
|
2 |
需求分析形成用 户故事,用户故 事规模适中,可 在一个迭代内完 成。 |
迭代开始前, 由产品经理、 需求提出方开 发团队一起细 化用户故事。 |
应使用产品待 办列表和迭代 待办列表管 理。 |
无 |
无 |
|
3 |
用户故事符合 INVEST 标准:1) 故事是独立完整 |
在软件过程的 任 何 阶 段 , 产 品经理、需求 |
同上且当发生 规模型产品研 发情况,应建 |
无 |
无 |
的,2)故事是可 协商并细化的, 3)故事是有业务 价值的,4)故事 是能评估工作量 和优先级的,5) 故事是足够小 的,一般在 1-2 日内完成,6)故 事是可测试的。 |
提出方及团队 成员可对用户 故事进行变更 和细化。 |
立跨团队的产 品待办列表, 迭代待办列表 |
||||
4 |
同上且应具备可 视化的 MVP 的产 品演进路线,管 理用户故事和发 布迭代关系,可 以使用例如:用 户故事地图、影 响力地图等敏捷 方法。 |
同上且当发生 跨团队的产品 研发情况,应 建立史诗故 事、特性故事、 用户故事的分 层管理,可跨 团队进行需求 拆解细化。 |
同上且产品待 办列表应符合 DEEP 原则:1) 适当的详细描 述的,优先级 越高越详细明 确,2)用故事 点进行估算过 大小的,3)随 着产品演进不 断涌现和变化 的,4)优先级 从高到低排序 的。 |
应建立特性型研 发团队,与产品 经理合作提升需 求分析落地的价 值流动。 |
有协作型用 户故事沟通 工具、产品待 办列表管理 工具。 |
|
5 |
同上 |
同上 |
同上且应建立 需求与企业级 活动关联,把 企业战略和目 标通过愿景、 目标、关键结 果、任务、评 估、反馈等环 节进行分解, 实现企业、团 队、个人三个 层次对齐,达 到需求的业务 价值最大化。 |
同上且企业采用 扁平化的敏捷团 队组织架构,赋 予团队围绕产品 自组织、自管理 的权力,包括但 不限于产品规 划、建设、运营、 人力、绩效、核 算等。敏捷团队 以业务价值为核 心以运营为驱动 的敏捷工作模 式,企业为团队 提供 IT 基础设 施、基础管理等 支持。 |
同上且应建 立企业级的 需求管理工 具。 |
需求与用例管理
需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联性,能验收产
品功能是否满足用户故事的要求的过程。主要体现在三个方面:
1)梳理需求用例:编写需求验收标准,形成测试用例的过程;
2)使用需求用例:需求用例指导需求开发,验证产品功能的过程;
3)管理需求用例:建立需求与用例的统一管理库,持续的使用和优化。
敏捷开发管理中的需求与用例管理环节,根据以上三个方面所能达到的不同程度分为以下5个等级,
具体如下:
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
需求与用例 编写 |
需求用例验证 |
需求与用例的管理 |
||||
1 |
测试用例与 需求没有关 联,测试用 例在设计结 束代码开发 阶段完成。 |
无 |
测试用例在本需求 功能测试完成后没 有做归档重用,在 每次有新需求重新 设计测试用例。 |
无 |
无 |
|
2 |
测试用例与 用户故事应 有关联,测 试用例在需 求分析结束 设计阶段完 成。 |
每次上线前应 把编写的测试 用例全部验证 通过,才可上 线。 |
需求文档和测试用 例应作为知识沉淀 下来,当设计现有 产品进行功能优化 的需求时,需求文 档和测试用例在现 有的知识上进行调 整优化。 |
无 |
无 |
|
3 |
同上 |
同上 |
测试用例应作为产 品的软件代码资产 存在,所有的功能 上线都以能测试用 例验证通过为目 标,每次迭代上线 都必须执行产品沉 淀下的所有测试用 例,直到验证和修 复通过才可上线。 |
无 |
测试用例能 通过工具自 动执行。 |
|
4 |
同上且产品 的需求在最 初始阶段即 转化为测试 用例,细化 需求编写验 收标准过程 |
同上 |
同上且需求作为需 求用例库作为产品 的软件代码资产存 在,既保持可读性 又作为用例在产品 迭代更新中一直保 持完整和准确。 |
无 |
同上 |
即编写测试 用例的过 程。 |
同上且所有的功能 上线都以能被可读 的需求用例验证通 过为目标,每次迭 代上线都必须执行 沉淀下的所有的需 求用例,直到验证 和修复通过才可上 线。 当产品进行升级重 构时,产品的需求 用例库无需重建就 能作为升级重构后 的验收标准。 |
|||||
5 |
同上 |
需求应具备可 阅读的文档和 测试验证的实 例两种特性, 通过建设企业 级可视化便捷 的平台,建立 从用户故事排 入迭代开发、 开发完成后作 为测试验收测 试、部署到生 产即作为生产 验收测试,整 个过程的全自 动化模式。 |
同上 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队 围绕产品自组 织、自管理的权 力,包括但不限 于产品规划、建 设、运营、人力、 绩效、核算等。 敏捷团队以业务 价值为核心以运 营为驱动的敏捷 工作模式,企业 为 团 队 提 供 IT 基础设施、基础 管理等支持。 |
应建立企业 级可视化便 捷的平台,管 理需求文档, 且可以通过 需求文档能 查看产品的 全貌,且通过 平台,需求提 出人、最终使 用人、产品经 理、开发运维 人员进行更 好的沟通和 协作。 |
需求验收
需求验收是指产品经理、需求提出者和最终用户对产品的功能验收,要求能对需求进行快速测试、
快速确认、快速反馈、快速优化。本节的需求验收,仅是指功能验收,非功能测试不在本节的范围内。
需求验收主要体现在以下三个方面:
1)需求验收的频率:指不同角色对需求功能验收的频率,频率越高效果越好;
2)需求验收的范围:指需求验收应尽量具备有业务价值的端到端的验收;
3)需求验收的反馈效率:指需求验收的结果能准确、快速的反馈到开发团队的过程。
敏捷开发管理中,需求验收环节根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下:
需求验收频 率 |
需求验收范围 |
需求验收反馈效率 |
||||
1 |
在项目末 尾,需求上 线后,一次 性的实施 alpha 测 试、beta 测 试、正式验 收测试。 |
需求提出者或 最终用户应对 全量功能进行 验收。 |
有验收测试流程, 能把结果反馈到产 品经理和开发团 队。 |
无 |
无 |
|
2 |
在每个敏捷 迭代,应有 验收评审 会。 |
在验收评审会 上,产品经理 应对团队的迭 代成果进行验 收。 |
同上 |
无 |
无 |
|
3 |
同上且在跨 团队产品 里,有跨团 队的产品验 收会,并要 求在每个迭 代都须召 开。 |
同上且需求提 出者或最终用 户应能在每个 发布后进行验 收。 |
对验收测试应有快 速的反馈和优化流 程,能保障反馈能 在进入产品待办列 表,且根据优先级 进入迭代待办列 表。 |
验收须有产品经 理、需求提出者 和最终用户等参 与。 |
无 |
|
4 |
同上 |
同上且在迭代 过程中,应有 通过原型确 认、AB 测试、 灰度测试等方 法进行验收测 试,提升验收 效果 |
同上且建立产品级 的业务价值验收反 馈流程,在产品推 向市场后,能在 1-2 个迭代就能快速进 行响应。 |
同上 |
应有快速的 反馈和优化 流程和工具, 能收集验收 结果,并且能 快速转化为 迭代需求。 |
|
5 |
同上 |
同上 |
同上且针对反馈的 情况,能通过反馈 发现迭代中的沟 通、设计等各类问 题,并进行持续改 进。 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队 围绕产品自组 织、自管理的权 力,包括但不限 于产品规划、建 设、运营、人力、 绩效、核算等。 敏捷团队以业务 价值为核心以运 营为驱动的敏捷 |
应建立企业 级大数据分 析工具,能抓 取用户行为 数据,通过大 数据分析,在 用户功能验 收 和 用 户 体 验时作为辅 助决策依据, 持续优化改 进。 |
迭代计划管理
迭代计划管理是产品经理和开发团队进行需求的沟通、传递和规划的过程,包括需求澄清和拆解、
故事和任务排期、计划变更三个部分,要求产品经理和团队以业务价值的快速实现为目标,通过面对面
的沟通、制定约定、共同决策等方式,增强需求沟通、传递和规划的有效性。
需求澄清
需求澄清是产品经理和开发团队沟通和确认需求的过程,包含沟通和明确用户故事的细节(包括但
不限于背景信息、UI和交互设计、测试要点等),确定用户故事的技术实现方案,识别技术风险和依赖,
团队对用户故事进行任务拆分,产品经理和团队对于以上信息达成共识,明确用户故事完成的定义。
需求澄清主要体现在三个方面:
1)需求澄清的时间:指需求澄清发生在研发过程中的合适的阶段,以便适应研发过程中的变化及开
发团队工作的开展。
2)需求澄清内容的完备性:指在需求澄清过程中,是否澄清需求的所有内容。
3)需求澄清协作:指产品经理、开发团队及其他干系人如何协作开展澄清工作。
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
需求澄清的 时间 |
内容的完备性 |
协作 |
||||
1 |
在项目初 期,一次性 递交需求规 格说明书 |
需求规格说明 书内的内容 |
契约式文档传递 |
无 |
无 |
|
2 |
在迭代开始 之前进行需 求澄清 |
产品经理对于 用户故事的内 容进行讲解, 并解答团队提 出的问题 |
召开需求澄清会 |
无 |
无 |
|
3 |
同上 |
同上且团队确 定用户故事的 实现方案,识 别技术风险, 识别需求间的 依赖和团队间 的依赖。 |
团队内的需求澄清 会,团队间的需求 澄清会。 |
无 |
无 |
|
4 |
同上 |
同上且产品经 |
同上 |
无 |
企业提供的 |
理和团队对于 需求细节和验 收标准达成共 识,将关键信 息进行记录和 确认。 |
统一的协作 型需求沟通 工具,便于团 队在澄清过 程中能快速 进行关键信 息的更新和 记录。 |
|||||
5 |
同上 |
同上 |
同上 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队 围绕产品自组 织、自管理的权 力,包括但不限 于产品规划、建 设、运营、人力、 绩效、核算等。 敏捷团队以业务 价值为核心以运 营为驱动的敏捷 工作模式,企业 为 团 队 提 供 IT 基础设施、基础 管理等支持。 |
同上 |
故事与任务排期
敏捷开发将开发过程分为多个短冲刺,故事与任务的排期过程就是确定迭代冲刺目标的过程,根据
产品待办列表中用户故事的优先级、依赖关系、故事规模和团队速度,确定迭代待办列表,迭代待办列
表确定之后,团队成员根据优先级认领故事和任务。主要体现在三个方面:
1)排版要素:指进入排版时,信息的完备性,例如产品待办列表中用户故事的优先级、依赖关系、
故事规模和团队速度等。
2)排版容量:指排版容量的大小有据可依,根据实际用户故事规模和团队速度并考虑其他影响因
素后确定。
3)排版管理:指排版活动的组织形式。
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
排版要素 |
排版容量 |
排版管理 |
||||
1 |
产品待办清 单,对产品 待办清单内 容的完备性 不做要求 |
由产品经理和 团队负责人根 据实际需要确 定,无确切依 据 |
命令式管理,团队 根据产品经理和团 队负责人的要求工 作。 |
无 |
无 |
2 |
产品待办清 单中用户故 事内容完 备、优先级 确定,用户 故事间的依 赖关系确 定。 |
团队进行用户 故事规模估 算,具备团队 速度的参考值 |
有固定的排版活 动,约定为迭代开 始前的固定时间, 排版活动不仅确定 迭代目标,同时确 定迭代待办列表的 优先级,便于团队 在迭代开始后根据 优先级顺序进行开 发 |
无 |
无 |
|
3 |
同上 |
同上且具备用 户故事规模估 算标准 |
同上且具备多团队 排版活动,多团队 一起排版时,识别 出团队间存在依赖 的用户故事,约定 用户故事的优先 级,对于需要对齐 发布周期的团队, 进行对齐。 |
无 |
无 |
|
4 |
同上 |
同上 |
同上 |
无 |
具备工具支 撑在线排版 活动,能自动 识别任务间 的依赖,支持 团队间依赖 管理,能实现 任务的自动 流转等,对于 需要进行团 队对齐的情 况,能自动实 现团队的对 齐。 |
|
5 |
同上 |
同上 |
同上 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队 围绕产品自组 织、自管理的权 力,包括但不限 于产品规划、建 设、运营、人力、 绩效、核算等。 敏捷团队以业务 |
同上 |
计划变更
计划变更是指在迭代过程中,迭代目标发生变化,“响应变化胜过遵循计划”是敏捷的核心价值观
之一,但进入迭代的内容发生变化会影响研发团队的工作效率,所以需要采取措施尽量减少计划变更的
负面影响。主要体现在三个方面:
1)变更决策:是指决定变更和接受变更的决策方式;
2)应对变更:是指接受变更后,是否具备措施减少变更的影响;
3)减少变更:是指是否具备措施减少变更的发生。
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
变更决策 |
应对变更 |
减少变更 |
||||
1 |
产品经理提 出变更请 求,变更委 员会(通常 为一个由需 求、开发等 团队负责人 组成的虚拟 组织)进行 审批,决定 是否接受变 更。 |
无 |
无 |
无 |
无 |
|
2 |
产品经理和 团队约定计 划变更的流 程,产品经 理提出变更 请求后,与 团队沟通, 共同决定是 否进行计划 变更 |
发生需求变更 时,团队成员 决定置换的用 户故事。 |
无 |
无 |
无 |
|
3 |
同上 |
团队具备应对 措施,减少变 |
无 |
无 |
无 |
更带来的影 响,例如:用 户故事拆分 时,充分考虑 其独立性,减 少需求变更影 响的团队范 围;团队在开 发过程中,按 照用户故事优 先级进行开 发;需求置换 时,以小换大, 即换入的用户 故事规模原则 上应小于换出 的故事规模; 优先置换出低 优先级的需 求;不能置换 出半成品。 |
||||||
4 |
同上 |
同上 |
在产品规划阶段, 具备减少变更带来 影响的措施,例如: 产品待办列表的梳 理应该贯穿于产品 生命周期的始终, 始终确保高优先级 的需求优先被处 理,从而减少进入 迭代以后的变更次 数;根据经验,预 留开发资源;具备 较早的识别变更的 能力,确保变更更 早的发生。 |
无 |
无 |
|
5 |
同上 |
同上 |
敏捷团队围绕公司 战略工作,在产品 规划、研发、发布 各层面具备灵活反 应的能力,可支撑 业务价值驱动下的 灵活的计划变更, |
企业采用扁平化 的敏捷团队组织 架构,赋予团队 围绕产品自组 织、自管理的权 力,包括但不限 于产品规划、建 |
无 |
敏捷过程管理
敏捷过程管理包括迭代管理、迭代活动、过程可视化及流动、度量分析四个部分,主要体现开发团
队的研发过程的敏捷性,包括开发团队的节奏感、仪式感、透明化、持续改进等方面。
迭代管理
迭代管理,即贯穿于产品研发过程中以保持恒定的时长为周期,每个周期都遵从相同的框架过程,
并且交付潜在的可发布最终产品增量。迭代管理主要体现在以下三个方面:
1)敏捷迭代周期:指团队能约定迭代时长、交付时长;
2)迭代协作机制:指团队内或团队间的工作进行相互配合,使得产品开发能快速交付;
3)迭代流程改进:指团队能通过不断检视迭代过程,对发现的问题能持续改进。
敏捷开发管理中,迭代管理根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下:
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
迭代时间周期 |
迭代协作机制 |
迭代流程改进 |
||||
1 |
产品分多次迭 代开发,每次迭 代中按照需求 分析、设计、开 发、上线等线性 过程进行管控, 完成产品部分 功能 |
无 |
在下次产品完整 研发过程进行改 进调整 |
无 |
无 |
|
2 |
团队约定任务 迭代周期,约定 交付周期 |
团队能定义清 场所、参加人 员;定义各类角 色,明确分工, 约定协作模式; 约定环节间交 |
迭代过程问题能 以用户故事形式 进行改进 |
无 |
无 |
付物、流转规 则。 |
||||||
3 |
团队内约定同 上,团队间能对 齐迭代计划、时 间、产品集成发 布时间 |
团队内约定同 上,团队间建立 协同工作机制, 如通过团队间 的敏捷改进会 议来推进协作。 |
同上 |
无 |
无 |
|
4 |
同上 |
同上 |
同上 |
无 |
能在团队间工 作对齐、角色 管理、角色工 作安排、团队 协作、流程数 据可视化等方 面提供工具支 持。工具平台 具备提供迭代 过程的相关数 据、进行分析 的能力。 |
|
5 |
同上 |
同上 |
同上 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队围 绕产品自组织、自 管理的权力,包括 但不限于产品规 划、建设、运营、 人力、绩效、核算 等。敏捷团队以业 务价值为核心以 运营为驱动的敏 捷工作模式,企业 为团队提供 IT 基 础设施、基础管理 等支持。 |
迭代计划与企 业战略相结 合,建立企业 级敏捷支撑平 台,提供从战 略规划、产品 规划实施、产 品交付整个价 值链可视化展 示、数据分析 的能力。 |
迭代活动
敏捷迭代活动,是指从产品规划、研发过程、产品交付、持续改进等维度来定义的产品迭代研发中
的一系列过程,目的在于推进敏捷迭代团队的持续改进和产品的快速交付。迭代活动主要体现在以下三
个方面:
1)迭代活动约定:是指团队能能在约定的时间、相对固定的场所举行相关活动;
3)迭代活动范围:是指团队能在各类敏捷会议中遵守约定的会议内容。
敏捷开发管理中,迭代活动根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下:
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
迭代活动约定 |
约定 |
迭代活动范围 |
||||
1 |
产品分多次迭 代开发,每次迭 代中按照需求 分析、设计、开 发、上线等线性 过程进行管控, 按照契约方式 进行各类评审 工作 |
时间根据会议 内容确定,无约 定长短 |
不同阶段的输出 物评审 |
根据内容确定相 关参与人员 |
无 |
|
2 |
团队能在迭代 内按照约定时 间点分别完成 产品计划会议、 迭代计划会议、 每日站立会、迭 代交付评审会 议、改进回顾会 议。 |
各 种 会 议 能 严 格 按 照 约 定 时 间盒内进行 |
按照各类会议的 要求,控制会议 内容 |
产品经理、团队共 同参与 |
无 |
|
3 |
团队内工作方 式同上,跨团队 的敏捷产品开 发中,多团队间 建立更高级别 的迭代,具有跨 团队的产品代 办列表。团队间 定期举行跨团 的计划会、评审 会议、回顾会 议。能不定期召 开团结间协调 推进会议。能对 跨团队的协同 问题跟进落地 实施。 |
能对跨团队的 产品按照约定 时间、节奏进行 验收评审会议。 |
同上 |
具备跨团队的敏 捷推进协调组织, 由产品经理、团队 成员、跨团队的约 定参与人员、及其 它干系人 |
无 |
|
4 |
在上一级的基 |
同上 |
同上 |
同上 |
无 |
础上,在约定周 期内开展跨团 队的敏捷推进 会议 |
||||||
5 |
在上一级的基 础上,建立企业 级敏捷活动推 进组织,从组织 文化、产品规 划、人力成本等 多个方面进行 协同推进敏捷 持续改进 |
同上 |
同上 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队围 绕产品自组织、自 管理的权力,包括 但不限于产品规 划、建设、运营、 人力、绩效、核算 等。敏捷团队以业 务价值为核心以 运营为驱动的敏 捷工作模式,企业 为团队提供 IT 基 础设施、基础管理 等支持 |
无 |
过程可视化及流动
通过对敏捷迭代过程的可视化展示,实时反映用户故事的迭代进展,体现产品从需求、研发、交付
端到端的价值流动,通过在制品数量等工具实现价值流动的拉动式管理。过程可视化及流动主要体现在
以下三个方面:
1)过程可视化:通过各种数据记录,反馈敏捷开发过程质量;
2)过程价值流动:通过各种工具体现敏捷过程的业务交付价值流动过程;
3)迭代过程改进:对数据反映的各种问题,不断改进迭代过程。
敏捷开发管理中,过程可视化及流动根据以上三个方面所能达到的不同程度分为以下5个等级,具
体如下:
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
过程可视化 |
过程价值流动 |
迭代过程改进 |
||||
1 |
注重结果数据, 过程数据跟踪 较弱 |
无 |
无 |
无 |
无 |
|
2 |
团队级迭代内 的过程数据进 行跟踪记录,并 进行可视化管 理 |
无 |
无 |
无 |
无 |
|
3 |
满足迭代数据 |
无 |
无 |
无 |
通过可视化的 |
可视化的基础 上,实现端到端 的可视化管理 |
管理工具,对 产品需求收 集,分析,产 品故事优先 级,迭代用户 故事优先级等 内容进行管 理,实时反馈 需求管理的进 展 |
|||||
4 |
在满足前一级 别的基础上,从 产品规划到产 品运营全生命 周期的可视管 理 |
通过端到端的 可视化,实现产 品研发的拉到 式管理,能暴露 过程中的问题, 管理价值流动 |
能建立持续反馈 机制,持续改进 |
无 |
通过如看板等 工具进行可视 化管理 |
|
5 |
同上 |
同上 |
同上 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队围 绕产品自组织、自 管理的权力,包括 但不限于产品规 划、建设、运营、 人力、绩效、核算 等。敏捷团队以业 务价值为核心以 运营为驱动的敏 捷工作模式,企业 为团队提供 IT 基 础设施、基础管理 等支持 |
在扁平化组织 架构下,由企 业提供过程可 视化管理平 台,可视化产 品从用户价值 提出到交付的 完整过程,提 供数据支撑, 建立反馈,持 续优化改进 |
度量分析
度量分析是对迭代过程中研发效率、质量数据进行分析,反映过程的健康程度;通过对产品端到端
指标数据进行分析,实时反映产品的表现。驱动敏捷迭代的过程改进,推动企业组织架构、人员结构、
财务制度等方面进行不断优化。使用敏捷迭代的方式推进改进措施的实施。度量分析主要体现在以下三
个方面:
1)度量的粒度:是指敏捷迭代分析度量的详细程度;
2)度量的范围:是指分析度量涉及人员组织,范围大小
3)度量驱动持续改进:是指在分析发现问题后,能不断进行落地改进。
敏捷开发管理中,度量分析根据以上三个方面所能达到的不同程度分为以下5个等级,具体如下:
级别 |
主要工作完备性 |
人员机制 |
工具能力 |
备注 |
||
度量粒度 |
度量范围 |
度量驱动持续 改进 |
||||
1 |
能对团队结果 数据指标进行 分析跟踪。没有 形成有效的过 程指标分析跟 踪支持 |
团队内 |
能对产品研发中 质量问题进行分 析,形成分析报 告,对改进措施 的落地推进较弱 |
无 |
无 |
|
2 |
在敏捷团队中, 能对迭代过程 指标进行分析, 从交付质量、交 付速度等方面 进行分析,反映 研发过程的健 康程度 |
团队内 |
能对团队敏捷过 程发现的问题, 形成团队代办任 务,以敏捷迭代 的方式实施改进 措施 |
无 |
无 |
|
3 |
在团队级的基 础上,能围绕产 品的完整生命 周期,从需求提 出、研发、交付、 运营反馈等建 立指标分析体 系 |
团队内及团队 间 |
在团队级的基础 上,建立跨团队 的产品级回顾会 议,在会议上对 多团队的迭代对 齐问题,人员技 能等问题进行分 析,形成解决方 案,以迭代的方 式持续推进解决 方案落地实施 |
无 |
无 |
|
4 |
同上 |
同上 |
在产品级回顾会 议上能以平台数 据为支撑,分析 敏捷过程的问 题,制定改进计 划,以迭代的方 式持续改进 |
无 |
能通过平台支 撑产品从需求 到交付的端到 端的过程指标 展示,提供指 标数据的报表 分析能力,能 从数据中分析 发现协作的问 题 |
|
5 |
同上 |
企业级 |
以企业级平台数 据为支撑,从战 略角度分析敏捷 实施过程的问 |
企业采用扁平化 的敏捷团队组织 架构,赋予团队围 绕产品自组织、自 |
建立企业级工 具平台,能通 过平台指标数 据反映产品研 |
万水千山总是情,点个好看行不行。
欢迎加入交流群
以上是关于敏捷开发管理过程的主要内容,如果未能解决你的问题,请参考以下文章