敏捷需求管理过程.docx

敏捷需求管理过程
文档编号：PF_ARM_M_60
文档信息：组织级过程文件
文档名称：需求管理过程
文档类别：需求管理类
密 级：内部
版本信息：1.0
建立日期：2014/06/20

创 建 人：张世豪
审 核 者：谢东
批 准 人： 谢志华
批准日期：2014/09/12

文档修订记录
版本编号或者更改记录编号
*变化
状态
简要说明
（变更内容和变更范围）
日期
变更人
批准日期
批准人
V0.5
A
新建
2014/06/20
张世豪

V0.8
M
修改
2014/07/15
张世豪

V0.9
M
修改
2014/08/01
张世豪

V1.0
M
修改
2014/08/03
张世豪

*变化状态：A——增加，M——修改，D——删除

文档评审记录
序号
评审人
角色
评审日期
签字
备注
1
谢东
开发管理部经理
2014/08/08

2
谢东
开发管理部经理
2014/08/25

3

文档审批信息
序号
审批人
角色
审批日期
签字
备注

目录
1.简介 4
1.1文档目的 4
1.2适用范围 4
1.3术语与缩略语 4
1.4参考资料 5
2.过程概述 5
3.角色与职责 7
4. 过程活动 10
4.1收集原始需求 10
4.2编写产品需求条目 11
4.3产品需求条目优先级排序和估算 13
4.4评审产品需求 13
4.5编写产品发布计划 14
4.6评审产品发布计划 16
4.7拆分特征和细化需求 17
4.8验证需求条目和特征 18
4.9验证交互与UI规范 19
4.10测试待发布产品 20
4.11准备发布资料 21
4.11 跟踪需求 22
5.附录 24
5.1附录A---相关过程 24
5.2附录B---相关规程 24
5.3附录C---相关指南 24
5.4附录D---相关检查单 25
5.5附录E---相关模板 25
5.6附录F---相关工程方法 25
5.7附录G---相关最佳实践 25

1.简介
1.1文档目的
定义并描述敏捷需求管理过程，指导产品的需求收集，需求分析，需求拆分，需求开发，需求验证及发布，并跟踪产品概念，开发，发布，运营四大阶段中需求的形态和状态。指导研发团队管理需求。
1.2适用范围
本过程适用于：
l       机构：适用于集团内各产品研发组织
l       业务：指导需求收集，需求分析，需求拆分，需求开发，需求验证及发布 ，及全生命周期状态跟踪
l        产品类型：平台产品，标准产品，移动互联网产品
1.3术语与缩略语
l 原始需求：包括来源于规划的目标，UE/UI目标，用户最初的需求，产品创意，表达干系人及客户的最初的意愿。
l 产品规划：PO根据调查研究，在了解市场、了解客户需求、了解竞争对手、了解外在机会与风险以及市场和技术发展态势的基础上，根据公司自身的情况和产品发展方向，制定出可以把握市场机会，满足消费者需要的产品的远景目标（Vision）以及实施该远景目标的过程。产品规划的内容包括产品定位、产品生命周期规划、包含版本规划、版本范围规划。
l 需求场景：需求场景是一种分析和描述用户需求的方法，它应该拥有这样的结构：“在某某时间（when），某某地点（where），周围出现了某些事物时（with what），特定类型的用户（who）萌发了某种欲望（desire），会想到通过某种手段（method）来满足欲望。”。
l 产品需求条目：PO在产品需求分析阶段的输出, 是基于场景细化出的需求条目，是产品中独立的任务单元，产品需求条目可独立体验、测试或验证。产品需求条目的描述方式为：
a) 产品功能需求条目的描述方法为： 作为XXX 要执行XXX操作(活动)，以满足XXX。需求条目细化粒度为用户目标级的需求，不是企业概要级的条目，是基于某一个角色执行某一个活动的单一描述，而不是角色和活动的组合；
b) 设计等非功能需求：PO提出设计需求，包含性能需求、设计约束，设计行业规范、外部系统设计接口等；
l Product backlog：产品需求条目列表,是产品需求范围的载体，用于工作量评估和优先级评定，同时可作为制定sprint backlog ，sprint 计划，发布计划相关工作的输入
l 特征：特征（Feature）作为一个开发单位,是项目中的一个功能增量,是指“用户眼中最小的有用的功能”, 可以在1周内实现。特征是对应到产品模块级的描述。特征描述方法： 作为XXX（角色） 通过XXX（功能）达到XXX； 设计特征可不采用这种模式；
l 产品形态：即产品类型一般包括用友体系内的平台产品，标准产品，移动互联网产品
l 需求跟踪：跟踪“原始需求-(场景)-产品需求条目-特征-测试”的一致性。需求跟踪可通过工具或人工管理需求跟踪记录来进行，为产品追溯提供条件，保障产品符合用户需求。需求跟踪数据分析后可以为项目监控和风险管理提供依据。
1.4参考资料
《用户故事和敏捷方法》
2.过程概述
该过程旨在描述敏捷需求管理相关活动,包括收集原始需求，制定产品需求条目，制定产品发布计划，细化需求，验证需求及发布产品。指导产品概念，开发，发布，运营四大阶段中如何进行需求管理，关注需求的形态和状态。

1、 PO,需求分析师获取用户原始需求，定期对原始需求进行梳理讨论，分析场景，初步评估优先级并确定解决方案，规划解决日期及产品版本。原始需求讨论确认后纳入需求池进行管理。
2、 PO基于需求池中的原始需求，进行产品需求条目的编写，并将需求条目纳入到product backlog.针对需求条目编写概要需求文档，包括场景，整体解决方案,业务需求跟踪纳等，作为产品需求条目的细化补充。
3、 对产品需求条目进行优先级的评定和估算，形成MVP。产品需求需要评审，可迭代进行。
4、 产品需求评审通过后，PO组织团队基于product backlog 制定产品发布计划。发布计划包括发布时间，版本类型，需求范围，质量要求等。评审通过后，制定相关开发和测试计划。
5、 产品需求条目评审通过后，需求分析师参考概要需求，对需求条目进行进一步的细化，与团队成员沟通产品详细解决方案，拆分特征条目和验收标准，形成Sprint backlog,开发团队基于特征进行设计，工作量估算和优先级评定；
6、 特征在SPRINT中开发完成后，提交后形成可工作产品，需求分析师及时针对可工作产品进行验证，PO对需求条目进行验证。特征验证缺陷问题反馈给开发团队进行修正，PO针对产品需求条目验证结果，调整Product backlog。
7、 需求验证通过后，提交集成，测试负责人组织测试团队，按照待发布版本的质量要求，对产品进行集成测试和发布测试。PO组织团队进行发布产品资料的准备，按照发布流程发布产品。
8、 PO在规划，立项评审通过后，建立需求跟踪矩阵，并在产品生命周期中，完善需求跟踪矩阵，当开发活动导致跟踪矩阵中产品需求条目变化时，更新需求跟踪矩阵。定期根据需求跟踪信息，报告需求的状态，确认开发产品与用户需求的一致性，并根据对比结果，调整需求和相关开发活动，应对变化。
需求管理相关迭代活动如下：
l 迭代活动1（A->B->6）:基于业务场景，针对特征和部分产品需求条目进行验证，开发团队提交特征和产品需求条目后即可开始验证，迭代周期一般小于Sprint周期。验证结果及时反馈给开发团队，开发团队修正特征和部分产品需求条目的缺陷。
l 迭代活动2（2->3->5->A->B->6）： 基于业务场景，验证产品需求条目,验证结果用于动态调整Product backlog及产品发布计划，以应对快速变化的市场需求。
l 迭代活动3（C）：Sprint开发，快速迭代开发符合一定质量要求的可工作产品,提供给PO，需求分析师，UE设计师，及相关干系人进行验证和反馈。
评审点包括产品需求评审(D)，产品发布计划评审(E)

3.角色与职责
角色
职责
参与活动
备注
开发负责人
1. 参与发布计划的制定，评审
2. 推动产品发布，协调相关部门和角色进行发布的准备工作。
3. 负责协调和解决需求跟踪中发现的问题与障碍。
1. 评审产品需求
2. 评审产品发布计划
3. 测试待发布产品

PO
1. 产品规划，产品目标定义，制定发布计划/里程碑计划,计划评审
2. 企业建模，用户建模，用户分析
3. 产品定义及评审,包括编写产品需求条目《product backlog》，优先级定义，场景分析,产品需求条目评审
4. 参与需求分析，指导编写，评审等
1. 收集原始需求
2. 编写产品需求条目
3. 产品需求条目优先级评定和估算
4. 评审产品需求
5. 编写产品发布计划
6. 评审产品发布计划
7. 拆分特征和细化需求
8. 验证需求条目和特征
9. 验证交互与UI规范
10. 测试待发布产品
11. 准备发布资料
12. 跟踪需求
根据产品线组织架构不同，该角色可能涉及到现有产品线PO，主需求相关岗位，同时作为内部的客户代表
需求分析师
1. 收集创意，缺陷，功能需求
2. 同行同类产品分析与比较
3. 依据产品需求场景细化应用模型
4. 根据产品需求条目拆分形成特征列表，协助开发团队进行工作量评估
5. 验证需求特征
6. 协助PO验证需求
1. 收集原始需求
2. 编写产品需求条目
3. 产品需求条目优先级评定和估算
4. 评审产品需求
5. 拆分特征和细化需求
6. 验证需求条目和特征
7. 验证交互与UI规范
8. 测试待发布产品
9. 准备发布资料
10. 跟踪需求
根据产品线组织架构不同目前需求分析师可能在开发团队内部，也可能在开发团队外部
UE设计师
1. UE/UI规范
2. UE/UI设计
3. 参与产品需求条目讨论
4. UE/UI验证
1. 编写产品需求条目
2. 评审产品需求
3. 拆分特征和细化需求
4. 验证交互与UI规范

SM
1. 跟踪迭代中产品需求条目和特征开发的进度，消除团队开发中遇到的障碍，保证sprint产品需求条目和特征开发活动顺利进行。承担着内部Scrum Master的职责。
1. 产品需求条目优先级评定和估算
2. 编写产品发布计划
3. 评审产品发布计划
4. 验证需求条目和特征
5. 验证交互与UI规范
6. 测试待发布产品
7. 准备发布资料

开发团队
1. 负责产品需求条目的开发实现，包括特征优先级定义，工作量评估，特征实现，特征验证，保证按期交付可运行达到质量目标的研发成果。
1. 编写产品需求条目
2. 拆分特征和细化需求
3. 验证需求条目和特征
4. 验证交互与UI规范
5. 测试待发布产品
6. 跟踪需求
开发团队一般涵盖需求分析师，设计编码人员，测试人员，开发过程以团队为主体，承接任务，保证产品的质量，共同决策并对交付成果负责。
测试团队
1. 根据发布计划的内容，对产品的质量进行持续验证，从而保证产品的发布符合质量要求。一般承担产品线或产品的集成测试，发布和发版测试工作。
1. 编写产品需求条目
2. 拆分特征和细化需求
3. 测试待发布产品
一般是独立的测试部门，
测试负责人
1. 负责测试计划的制定，测试质量工作的推进，消除测试工作中的障碍，保证发布产品的质量。
1. 产品需求条目优先级评定和估算
2. 制定发布计划
3. 测试待发布产品

敏捷教练
1. 参与开发过程中关键活动，指导团队敏捷开发，消除团队开发中遇到的障碍，改进开发过程，保证敏捷开发活动顺利进行
1. 全活动选择性
一般为外部敏捷教练
客户
1. 参与UE设计,协助确认交互和原型
2. 参与需求分析，协助确认产品需求满足用户需求
3. 参加需求评审参与产品的验证与反馈
1. 编写产品需求条目
2. 评审产品需求

其他干系人
1. 在产品需求条目评审时，负责在产品市场、产品客户使用等层面提供信息
2. 在产品发布计划评审时，提供产品市场、产品客户使用等层面对发布计划的要求
3. 在产品生命周期中，对产品提出意见和建议，及反馈新的需求
4. 产业链部门人员负责产品发版前的产品验证工作；
1. 评审产品需求
2. 评审产品发布计划
3. 跟踪需求
其他干系人一般包括产业链相关人员，产品市场代表，产品运维，运营，产品总监，质量总监，相关领域PO

4. 过程活动
过程活动清单参考《集团敏捷需求管理过程框架》中的所有细分活动，本章针对这些细分活动逐一描述。
4.1收集原始需求
活动目标
收集原始需求，为产品需求分析，需求定义，需求拆分和开发，发布提供依据。
参与人员与职责
主要负责人： PO
PO：PO基于产品规划，进行产品模型分析,同类软件分析，市场调研，竞争分析，以及用户对产品反馈的分析明确产品的目标，基于产品目标收集，分析和编写原始需求，并将原始需求纳入到需求池
需求分析师：通过获取项目需求问题，进行分析，形成原始需求，并将原始需求纳入到需求池。
入口准则
产品规划已启动
输入
l 《产品规划》
l 用户反馈（支持网问题，用户调研需求，其他途径反馈问题）
主要步骤
1、 PO，需求分析师通过项目问题收集、产业链需求收集、同行业产品分析，用户调研等多种途径获取用户原始需求信息。
2、 原始需求信息获取后，PO，需求人员定期对原始需求信息进行梳理讨论，分析场景，初步评估优先级，给出解决方案，规划解决日期及产品版本。
3、 评审原始需求，通过的原始需求，后续将纳入产品规划，并纳入需求池进行管理。
出口准则
产品退市
输出
《原始需求》
资源和能力要求
无
度量
度量元
采集点：
原始需求条目及状态
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪

4.2编写产品需求条目
活动目标
进行产品需求场景的分析，编写产品需求条目
参与人员与职责
主要负责人：PO
l PO
分析原始需求，对需求池中的原始需求将会按照产品的规划路线，进行拆分合并。
基于原始需求进行产品的场景分析，基于场景分析，编写产品需求条目，并初步确认实现的版本和优先级。
l 需求分析师
参与原始需求的分析，场景的分析，编写产品需求条目
参加产品需求条目的讨论和确认
l 开发团队
参与非功能性需求和接口需求的分析、
参与产品需求条目讨论和确认
l UE设计师
进行UE/UI设计，并和客户或者PO确认
参与产品需求条目讨论和确认
l 测试团队
参与产品需求条目讨论和确认
l 客户
参与UE/UI设计,确UE/UI设计
参与产品需求条目讨论和确认
入口准则
1.完成规划与立项评审
2.完成原始需求的获取
输入
《产品规划》
《原始需求》
《UE/UI规范》
主要步骤
1、 针对新产品或新模块，PO需要定义产品形态；例如功能节点设计等。
2、 在规划/立项评审通过后，PO组织需求分析师,针对需求进行进一步的细化，形成产品场景图；细化方法可采用企业建模，用户建模，商业画布，痛点分析等方法。
并将场景，整体解决方案,业务需求跟踪纳入到概要需求中。
3、 PO组织需求分析师，根据场景图中每一个场景和解决方案，编写产品需求条目并纳入到Product Backlog，产品需求条目描述方法：
a) 产品功能需求条目的描述方法为： 作为XXX 要执行XXX操作(活动)，以满足XXX，此时形成的需求条目细化粒度为：用户目标级的需求，而不是企业概要级的条目，是基于某一个角色执行某一个活动的单一描述，而不是角色和活动的组合；
b) 设计等非功能需求：PO提出设计需求，包含性能需求、设计约束，设计行业规范、外部系统设计接口等；开发团队进行设计.
4、 PO，需求分析师与开发团队，测试团队,UE设计师，客户沟通需求，并在需求条目理解上达成一致。
出口准则
产品需求条目编写完成
需求开发测试ＵＥ对于需求条目理解一致
输出
《产品形态（针对新产品、新模块）》
《概要需求》
《Product Backlog》
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量与状态
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪
4.3产品需求条目优先级排序和估算
活动目标
对 Product backlog进行优先级排序和估算。
参与人员与职责
主要负责人：PO
l PO
对product backlog进行优先级排序
对product backlog 中的用户故事进行估算
l 需求分析师
协助进行产品需求条目优先级排序和估算
l SM
协助进行产品需求条目优先级排序和估算
l 测试负责人
协助进行产品需求条目优先级排序和估算
l 其他干系人
协助进行产品需求条目优先级排序和估算
入口准则
产品需求条目编写完成
输入
《Product Backlog》
主要步骤
1. PO组织需求分析师等研发人员使用优先级评定方法，在用户价值，研发资源等多个维度对《Product Backlog》中产品需求条目排列优先级，优先级序号不能重复。
2. PO组织需求分析师等研发人员使用估算方法对《Product Backlog》中产品需求条目逐一进行估算
出口准则
《Product Backlog》中产品需求条目完成优先级评定和估算。
输出
完成优先级评定和估算的《Product Backlog》
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量与状态
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪
4.4评审产品需求
活动目标
针对产品需求进行评审，包括产品形态，概要需求，产品需求条目，让开发团队及相关干系人对需求理解达成一致。
参与人员与职责
主要负责人：PO
l PO
组织相关干系人对产品形态，概要需求及Product backlog中的产品需求条目的评审。
l 开发负责人
参与产品需求的评审
l 需求分析师
参与产品需求的评审
l 客户
参与产品需求的评审
l 其他干系人
参与产品需求的评审
入口准则
1. 产品需求条目编写完成，并纳入到Product Backlog中
输入
《产品形态（针对新产品、新模块）》
《概要需求》
《Product Backlog》
主要步骤
参考评审过程
出口准则
l 概念阶段首次评审准则：
关键及高优先级产品需求条目评审通过
概要需求中关键和高优先级条目对应的应用场景评审通过
产品形态表评审通过（针对新产品，新模块）
l 需求迭代中评审准则：
下一迭代Sprint backlog中产品需求条目评审通过
下一迭代Sprint backlog中产品需求条目对应的场景，补充详细需求评审通过
输出
评审通过的
《产品形态（针对新产品、新模块）》
《概要需求》
《Product Backlog》
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量与状态
系统或人工
裁剪指南
裁剪内容
裁剪指南

新产品，新模块不可裁剪
4.5编写产品发布计划
活动目标
基于MVP(最小有价值产品)制定产品的发布计划。
参与人员与职责
主要负责人： PO
l PO
根据产品需求条目优先级和估算制定产品的发布计划，包括内部发布，稳定版发布，正式版发布。
l SM
参与产品发布计划的编写
l 测试负责人
参与产品发布计划的编写，并讨论和编写发布版本的质量目标,
l 其他干系人
参与产品发布计划的编写
入口准则
产品需求条目评审通过
输入
《产品形态（针对新产品、新模块）》
《概要需求》
《Product Backlog》
主要步骤
1、 对 product backlog 中的产品需求条目进行优先级排序
2、 针对 product backlog 中的产品需求条目进行估算
3、 PO根据需求条目，需求优先级形成本产品大版本需要包含的产品需求范围；SM，测试负责人，其他干系人参与
发布计划的制定，明确里程碑的发布进程（版本类型包括稳定版、灰度发布版（正式版）和上市版）及发布时间
出口准则
完成产品需求条目优先级排序，估算，
完成产品发布计划的编写
PO,SM，测试负责人，其他干系人，对于发布计划理解一致
输出
带优先级和估算完成的《product backlog》
产品发布计划（发布的范围，多少个发布版本，发布版本的性质，具体的发布时间等）
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量及状态
发布计划视图
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪
4.6评审产品发布计划
活动目标
评审发布计划，相关干系人对于发布计划达成一致，包括产品发布范围，发布时间，发布的质量标准
参与人员与职责
主要负责人：PO
l PO
组织相关干系人对发布计划和质量目标进行评审。
l 开发负责人
参与发布计划的评审
l SM
参与发布计划的评审
l 测试负责人
参与发布计划的评审
l 其他干系人
参与发布计划的评审

入口准则
发布计划编写完成
质量目标编写完成
输入
《发布计划》
《质量目标》
主要步骤
参考评审过程
出口准则
评审最终通过
输出
评审通过的
《发布计划》
《质量目标》
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量及状态
发布计划视图
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪

4.7拆分特征和细化需求
活动目标
拆分产品需求条目到产品特征，细化过程同步生成产品解决方案，明确产品需求条目和特征的验收标准
参与人员与职责
主要负责人:需求分析师
l 需求分析师
对product backlog中的产品需求条目进行拆分，拆分过程同时要分析需求的解决方案。拆分后以特征为单元进行后续的编码，验证。给开发团队，测试团队及及UE设计师讲解特征的应用场景，特征价值及验收标准。
l PO
讲解产品需求条目及解决方案，协助需求分析师拆分特征。
l 开发团队
沟通需求条目和特征，参与特征的拆分，理解特征和特征产生的业务场景，基于特征进行设计,并完成接口设计,基于特征进行估算
l UE设计师
沟通需求条目和特征，参与功能性特征的拆分,并了解特征的场景,基于特征进行UE/UI的设计
l 测试团队
沟通需求条目和特征，参与特征的拆分，了解特征和特征产生的场景.基于场景进行，进行特征验收标准的设计，并基于场景，编写测试用例用于
入口准则
1. 场景分析完毕
2. 产品需求条目优先级已经确认
3. 完成sprint backlog的确认，并发布了sprint 计划
输入
《概要需求》
《sprint backlog》
主要步骤
1、 需求分析师参考概要需求，对需求条目进行进一步的细化。与团队成员沟通产品详细解决方案，拆分产品特征条目。
2、 UE设计师基于特征进行设计，输出高保真原型
3、 需求分析师和团队成员讨论和确认需求条目和特征的验收标准
4、 测试人员基于产品需求条目，概要需求，以场景或产品需求条目为单位编写测试用例，要覆盖所有特征条目
5、 开发团队基于特征进行设计和估算。估算包括工作量和优先级；特征优先级依赖于产品需求条目优先级。
6、
出口准则
完成sprint backlog中产品需求条目的拆分，估算，设计，及验收标准
输出
《需求特征清单》(包括优先级，工作量评估，特征验收标准)
《详细需求文档(解决方案)》(可选)
《UI高保真原型》(可选)
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量及状态
特征条目数量级状态
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪

4.8验证需求条目和特征
活动目标
进行需求条目和特征的验证，目标保证产品需求条目和特征符合验收标准。
参与人员与职责
主要负责人:PO,需求分析师
l PO
参照产品需求条目验收标准，对交付成果进行验证，并将验证结果反馈给开发团队和SM
l 需求分析师
参照产品需求条目和特征验收标准，对交付成果进行验证，将验证结果反馈给开发团队和SM
l 开发团队
根据需求分析师和PO的验收问题，修正缺陷，保证交付成果满足验收标准
l SM
协助开发团队和PO,需求进行需求条目和特征的验收，并推进验收问题的修正，保证交付成果符合验收标准。
入口准则
1. 迭代计划中的特征已经开发完成，并可演示
输入
可工作产品
《sprint 计划》
《需求特征清单》
主要步骤
1. PO,根据产品需求条目验收标准进行验证
2. 需求分析师根据特征清单的验收标准进行特征的验证。
3. 需求分析师协助PO进行需求条目的验证。
4. 验收结果反馈给SM和开发团队。
5. 开发团队进行验证问题的修正
出口准则
可工作产品符合验收标准
输出
需求验证过的可工作产品
《需求验证报告》（针对产品需求条目验证信息和产品特征验证信息）
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量及状态
特征条目数量及状态
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪
4.9验证交互与UI规范
活动目标
对产品UE规范，用户体验要求和原则进行验证
参与人员与职责
主要负责人：UE设计师
l UE设计师
UE设计师对产品UE规范，用户体验要求和原则进行验证。
l PO
参与UE验证，并从产品的角度给与验证结果反馈
l 需求分析师
参与UE验证，并从产品的角度给与验证结果反馈
l 开发团队
根据UE验证问题，修正缺陷，保证交付成果满足UE规范和要求
l SM
协助UE验证，并推进验收问题的修正，保证交付成果符合UE规范与标准。
入口准则
迭代计划中的特征已经开发完成，并可演示
输入
可工作产品
《UE目标》《UE规范》
《高保真原型》
主要步骤
1.UE设计师根据UE规范和UE目标进行特征的验证。
2.将验证结果反馈给开发团队和SM
3.开发团队进行验证问题的修改。
出口准则
可工作产品符合UE规范和目标
输出
UE验证通过的可工作产品
《需求验证报告》（针对UE/UI规范报告）
资源和能力要求
无
度量
度量元
采集点：
产品需求条目数量及状态
特征条目的数量及状态
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪

4.10测试待发布产品
活动目标
根据发计划，将产品需求条目进行集成，直到测试达到质量目标后，进入发布流程。
参与人员与职责
主要负责人：测试负责人
l 测试负责人
组织测试团队对产品进行集成测试和发布测试，直到符合质量目标为止
l 测试团队
执行产品的集成测试和发布测试工作
l PO
进行产品的发布前验证工作,确认是否符合产品的目标
l 需求分析师
辅助PO进行产品的验证工作
l SM
推进集成测试和发布测试阶段的开发工作
l 开发团队
修正缺陷
入口准则
1. 产品符合进入集成和发布的要求
2. 时间达到发布计划中（测试计划），集成测试和发布测试的时点
输入
《发布计划》
可用的工作产品
《product backlog》
《质量目标》
《集成测试用例》
《发版测试用例》
主要步骤
步骤参考集成测试，发版测试流程及活动
出口准则
产品符合发布质量标准
输出
1. 符合质量标准的工作产品
2. 《集成测试报告》、《发布测试报告》
资源和能力要求
无
度量
度量元
采集点：
Bug数量
系统(缺陷系统)或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪

4.11准备发布资料
活动目标
根据发计划，准备产品发布所需资料。
参与人员与职责
主要负责人：PO
l PO
负责协调相关人员进行发布前资料的准备工作
负责组织产品手册，帮助，发布说明资料的准备
l 需求分析师
协助PO进行发布资料准备
l 测试负责人
负责组织测试团队准备发布测试报告
l 测试团队
协助测试负责人准备发布测试报告相关资料

入口准则
1.产品开始集成测试或发布测试
输入
《发布计划》
可用的工作产品
《product backlog》
《质量目标》
主要步骤
1.准备产品手册，帮助，发布说明等资料
2.准备发布测试报告
出口准则
特征集符合发布质量标准，产品进入发布状态
输出
稳定版：
《产品使用手册》，《帮助文档》，《发布说明》，稳定版光盘
正式版
《产品测试报告》 、《评审审批表》、《产品使用手册》、《产品部署手册》、《软件发版说明》、《软件发版通知》、《产品培训计划》、《红皮书》
发版光盘及清单
上市版：
包含正式版资料，另需要准备《上市（上线）通知》，《报价清单》
资源和能力要求
无
度量
度量元
采集点：
工作量
系统(缺陷系统)或人工
裁剪指南
裁剪内容
裁剪指南

不同类型版本对于输出物可裁剪

4.11 跟踪需求
活动目标
基于产品需求条目，追踪其与原始需求，场景，特征，及任务的关系。
追踪产品需求条目的状态，包括分析，产品待开发，开发进行中，开发已完成，已集成，已发布状态
追踪需求条目的发布后质量，用户反馈缺陷数，重大问题及时修改率等。
通过跟踪管理需求，应对变化。
参与人员与职责
主要负责人：PO
l PO:
1.通过需求跟踪矩阵或系统对产品需求条目在生命周期中各阶段的关系进行跟踪
2.通过需求跟踪矩阵或系统对产品需求条目的状态进行跟踪
3.收集用户反馈，支持网问题，分析产品需求条目发布后的质量
l 开发团队：
通过迭代启动会，每日站立会，迭代评审会跟踪产品需求条目在开发阶段各活动中的状态和质量
l SM:开发阶段监控产品需求条目和特征完成的状态，并进行风险的监控和预警。
l 测试团队：通过持续集成，白盒，黑盒测试等测试方法跟踪产品需求条目的质量
l 其他干系人
反馈产品问题和缺陷，提出新需求。

入口准则
规划/立项评审通过
输入
《立项任务书》
《产品规划》
主要步骤
1. 建立需求跟踪矩阵
2. 更新需求跟踪矩阵中产品需求条目的形态和状态
3. 定期根据需求跟踪，报告需求开发的状态，并进行product backlog和开发活动的更新和调整，应对变化。

出口准则
产品退市
输出
手工或系统《需求跟踪矩阵》
反馈（包括开发过程中的缺陷，需求验证，测试验证，ＵＥ／ＵＩ验证的问题清单，站立会问题跟踪表，迭代评审会问题跟踪表，支持网问题，用户反馈问题列表）
《Product backlog》
可用的产品
资源和能力要求
无
度量
度量元
采集点：
需求满足度，需求变更率，用户满意度等
系统或人工
裁剪指南
裁剪内容
裁剪指南

不可裁剪

5.附录
5.1附录A---相关过程
PF_ASE_A_01
产品规划立项过程
2014.12
PF_ASE_A_02
迭代开发策划过程
2014.12
PF_ASE_A_03
制定产品需求条目过程
2014.12
PF_ASE_A_04
制定发布计划过程
2014.12
PF_ASE_A_05
细化需求过程
2014.12
PF_ASE_A_06
Sprint开发过程
2014.12
PF_ASE_A_07
发布产品过程
2014.12
PF_ASE_A_08
上线发布过程
2014.12
PF_ASE_A_09
运营中与研发相关活动
2014.12
5.2附录B---相关规程
5.3附录C---相关指南
《敏捷站立会》
《敏捷迭代评审会》
《任务版使用指南》
5.4附录D---相关检查单
5.5附录E---相关模板
《原始需求》
《Product Backlog清单》
《产品发布计划》
《特征清单》
5.6附录F---相关工程方法
5.7附录G---相关最佳实践