需求条目化快捷之道：SEAi 需求分析法
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Ø 量化指标 胜过 文字评价 Ø 当前，所有敏捷流派都是“行为驱动”的，主要以在团队中建立起某种管理、技术过程为 主，而缺乏可比较的量化效果。“吞吐率”“故事点生产率”等概念到底多大程度上表征 实际生产率？自动化测试为什么常常比原来人工测试显得生产率更低？迭代开发是否带来 了高质量？在效果不明的情况下贸然进行大规模全员转型，常常走向骑虎难下的境地。 Ø 企业级敏捷转型需要建立起有说服力的度量项，从而作为判断试点成功，进行后继推广的 决策依据。
测试质量度量项： o 测试缺陷密度 D/FP o 测试用例有效率 D/TC
D测试 o 过程效益 = —————— %
D测试+D发布）
发布与运维度量项： o 发布周期 天 o 发布缺陷密度 D/FP o 缺陷响应周期 天 o 发布缺陷成本 人天/D o 发布缺陷次率 次/D
5
SEAi 需求分析法
将产品功能按商业目 标分解为若干场景：
简化迭代 计划会
迭代跟踪 DevOpsBan + 实时度量表
每日立会
迭代度量表
迭代回顾
项目管理度量项：
o 发布周期 天 o 名义生产率 FP/人天 o 实际生产率 FP/人天 o 成本 RMB/FP
场景 Scenario （商业目标）
实体 Entity （史诗故事）
行为 Action （用户故事）
需求实例 Instance （验收测试用例）
SEAi 需求层次与传统方法的映射关系
用户故事地图 XP，Jira Scrum SAFe，TFS 看板
UML 功能点分析FPA Word FP，工作量
~1个橙色纸片 ~1个Epic ~1个2级目录 ~N/A，30~300人天
~1个蓝色纸片 ~1个史诗故事Epic ~1个Feature ~1个实体Entity ~1个ILF或EIF ~1个3级目录 ~35/15FP，30/12人天
3
敏捷开发 端到端流程 全貌
精益创业 MVP 用户故事地图
看板
Scrum
路线图 Which
发布计划 When
迭代计划
（Roadmap, MVP最小可用产品）
Release Plan
Sprint Planning Meeting
DDD + 需求实例化
项目监控
Daily Standup
迭代评审
Retrospective Meeting
Ø 衔接步骤 胜过 零散实践 Ø 敏捷开发中存在各种似是而非的概念。比如：产品经理正在用户故事地图上张贴三种颜色 的需求纸片， Scrum Master则在维护两个Backlog，人们立会站在看板前移动任务纸片， 但开发人员回去之后完成的是用户故事 ，测试则正在研究需求实例和测试用例…… Ø 企业级敏捷转型，必须统一需求、计划、人物、开发、测试等各环节的定义，方可在令下 一道工序继承上一道工序的输出，从而达到事半功倍的效果
◇商铺管理场景 ◇购物场景 ◇收发货场景 ◇常规广告场景 ◇聚划算促销场景 ◇节日活动场景
场景 Scenario （商业目标）
将其中每个场景描述 为一段话：
购物场景： 顾客搜索商品，找到 以后创建订单，卖家 会生成发货记录，等 买家确认收货之后， 淘宝产生结算记录结 算货款及佣金。
实体 Entity （史诗故事）
Ø 具体方法 胜过 指导理念 Ø 如今，敏捷开发已经成为常态，从业界顶尖团队到资质平庸的无名团队都在尝试敏捷。这 时候，仅仅是“按用户价值优先级排序”、“自组织团队”、“INVEST原则”、“故事点” 这些模糊原则和概念，已经很难让普通团队学习和掌握了。 Ø 企业级敏捷转型，需要各个环节都有一种各种资质的人员30分钟都能学会，且工作结果接 近的具体方法。
火星人陈勇 企业级敏捷转型框架：QAD量化敏捷开发 手册
2
QAD量化敏捷开发宣言
尽管我们认为右侧的敏捷理念也很 重要，但要实现企业级敏捷转型， 我们更加认同：
全程优化 胜过 局部优化 具体方法 胜过 指导理念 衔接步骤 胜过 零散实践 量化指标 胜过 文字评价
Ø 全程优化 胜过 局部优化 Ø 极限编程，聚焦于编码、测试、集成等技术实践；Scrum，聚焦于计划、跟踪等项目管理 实践；看板，聚焦于项目管理中的任务管理；某些流派的DevOps，聚焦于持续集成、自动 化发布上线等技术实践…… Ø 企业级敏捷转型，需要一种端到端完整、自洽、连续的敏捷体系
需求，计划，开发，测试，质量，发布， 六大领域全程量化管理
微服务
数据库表 类
来自百度文库页面/接口 方法
测试用例
测试缺陷
发布缺陷
开发水平度量项 o 编码消耗率 LLOC/FP o 陈旧语法密度 个/FP
测试水平度量项：
o 行为覆盖率 % o 测试密度 TC/FP o 测试用例自动化率 % o 测试用例生产率 TC/测试人天 o 测试工作量占比 %
其中会被增查改删的宾 语就是【实体】：
购物场景： 顾客搜索【商品】，找 到以后创建【订单】， 卖家会生成【发货记 录】，等卖家确认收货 之后，淘宝产生【结算 记录】结算货款及佣 金。
行为 Action （用户故事）
为每一个实体，如【订 单】，分析增查改删行 为：
订单： 增： 创建 查多个： 列表，搜索，报表 查单个： 详情 改： 支付 删： 删除，取消
可工作产品
项目经理 Scrum Master
创新 Why
用户 Who
场景 Where
（Scenario）
实体/接口 What
（史诗故事，Epic）
行为 hoW
（用户故事，Story）
需求实例
（ATDD测试用例）
质量报告
产品评审
Review Meeting
持续发布 CD
产品上市与反馈
产品经理 Product Owner
微服务 Area（asp.net） Package（Java）
0.25～12人月
Controller Model
～35/15人天
Action View
～5.4人天
测试用例
持续集成 CI
自动化测试
微服务 + 重构 + XP
DevOps
团队 Team
QAD核心实践
早期估算表
迭代规划 故事地图
版本规划
整体 计划会
需求实例 Instance （验收测试用例）
按成败快慢程度，将单个 行为分解为需求实例
订单.创建： 最快成功：正常创建； 成功：调整商品数量大于 0；调整商品数量小于等于 0（被阻止）； 失败：创建不存在的商品 订单；创建未上架的商品 订单； 最快失败：不登录访问创 建订单链接；拷贝访问别 人的创建订单链接；
测试质量度量项： o 测试缺陷密度 D/FP o 测试用例有效率 D/TC
D测试 o 过程效益 = —————— %
D测试+D发布）
发布与运维度量项： o 发布周期 天 o 发布缺陷密度 D/FP o 缺陷响应周期 天 o 发布缺陷成本 人天/D o 发布缺陷次率 次/D
5
SEAi 需求分析法
将产品功能按商业目 标分解为若干场景：
简化迭代 计划会
迭代跟踪 DevOpsBan + 实时度量表
每日立会
迭代度量表
迭代回顾
项目管理度量项：
o 发布周期 天 o 名义生产率 FP/人天 o 实际生产率 FP/人天 o 成本 RMB/FP
场景 Scenario （商业目标）
实体 Entity （史诗故事）
行为 Action （用户故事）
需求实例 Instance （验收测试用例）
SEAi 需求层次与传统方法的映射关系
用户故事地图 XP，Jira Scrum SAFe，TFS 看板
UML 功能点分析FPA Word FP，工作量
~1个橙色纸片 ~1个Epic ~1个2级目录 ~N/A，30~300人天
~1个蓝色纸片 ~1个史诗故事Epic ~1个Feature ~1个实体Entity ~1个ILF或EIF ~1个3级目录 ~35/15FP，30/12人天
3
敏捷开发 端到端流程 全貌
精益创业 MVP 用户故事地图
看板
Scrum
路线图 Which
发布计划 When
迭代计划
（Roadmap, MVP最小可用产品）
Release Plan
Sprint Planning Meeting
DDD + 需求实例化
项目监控
Daily Standup
迭代评审
Retrospective Meeting
Ø 衔接步骤 胜过 零散实践 Ø 敏捷开发中存在各种似是而非的概念。比如：产品经理正在用户故事地图上张贴三种颜色 的需求纸片， Scrum Master则在维护两个Backlog，人们立会站在看板前移动任务纸片， 但开发人员回去之后完成的是用户故事 ，测试则正在研究需求实例和测试用例…… Ø 企业级敏捷转型，必须统一需求、计划、人物、开发、测试等各环节的定义，方可在令下 一道工序继承上一道工序的输出，从而达到事半功倍的效果
◇商铺管理场景 ◇购物场景 ◇收发货场景 ◇常规广告场景 ◇聚划算促销场景 ◇节日活动场景
场景 Scenario （商业目标）
将其中每个场景描述 为一段话：
购物场景： 顾客搜索商品，找到 以后创建订单，卖家 会生成发货记录，等 买家确认收货之后， 淘宝产生结算记录结 算货款及佣金。
实体 Entity （史诗故事）
Ø 具体方法 胜过 指导理念 Ø 如今，敏捷开发已经成为常态，从业界顶尖团队到资质平庸的无名团队都在尝试敏捷。这 时候，仅仅是“按用户价值优先级排序”、“自组织团队”、“INVEST原则”、“故事点” 这些模糊原则和概念，已经很难让普通团队学习和掌握了。 Ø 企业级敏捷转型，需要各个环节都有一种各种资质的人员30分钟都能学会，且工作结果接 近的具体方法。
火星人陈勇 企业级敏捷转型框架：QAD量化敏捷开发 手册
2
QAD量化敏捷开发宣言
尽管我们认为右侧的敏捷理念也很 重要，但要实现企业级敏捷转型， 我们更加认同：
全程优化 胜过 局部优化 具体方法 胜过 指导理念 衔接步骤 胜过 零散实践 量化指标 胜过 文字评价
Ø 全程优化 胜过 局部优化 Ø 极限编程，聚焦于编码、测试、集成等技术实践；Scrum，聚焦于计划、跟踪等项目管理 实践；看板，聚焦于项目管理中的任务管理；某些流派的DevOps，聚焦于持续集成、自动 化发布上线等技术实践…… Ø 企业级敏捷转型，需要一种端到端完整、自洽、连续的敏捷体系
需求，计划，开发，测试，质量，发布， 六大领域全程量化管理
微服务
数据库表 类
来自百度文库页面/接口 方法
测试用例
测试缺陷
发布缺陷
开发水平度量项 o 编码消耗率 LLOC/FP o 陈旧语法密度 个/FP
测试水平度量项：
o 行为覆盖率 % o 测试密度 TC/FP o 测试用例自动化率 % o 测试用例生产率 TC/测试人天 o 测试工作量占比 %
其中会被增查改删的宾 语就是【实体】：
购物场景： 顾客搜索【商品】，找 到以后创建【订单】， 卖家会生成【发货记 录】，等卖家确认收货 之后，淘宝产生【结算 记录】结算货款及佣 金。
行为 Action （用户故事）
为每一个实体，如【订 单】，分析增查改删行 为：
订单： 增： 创建 查多个： 列表，搜索，报表 查单个： 详情 改： 支付 删： 删除，取消
可工作产品
项目经理 Scrum Master
创新 Why
用户 Who
场景 Where
（Scenario）
实体/接口 What
（史诗故事，Epic）
行为 hoW
（用户故事，Story）
需求实例
（ATDD测试用例）
质量报告
产品评审
Review Meeting
持续发布 CD
产品上市与反馈
产品经理 Product Owner
微服务 Area（asp.net） Package（Java）
0.25～12人月
Controller Model
～35/15人天
Action View
～5.4人天
测试用例
持续集成 CI
自动化测试
微服务 + 重构 + XP
DevOps
团队 Team
QAD核心实践
早期估算表
迭代规划 故事地图
版本规划
整体 计划会
需求实例 Instance （验收测试用例）
按成败快慢程度，将单个 行为分解为需求实例
订单.创建： 最快成功：正常创建； 成功：调整商品数量大于 0；调整商品数量小于等于 0（被阻止）； 失败：创建不存在的商品 订单；创建未上架的商品 订单； 最快失败：不登录访问创 建订单链接；拷贝访问别 人的创建订单链接；