集团敏捷需求管理过程框架发文.docx

集团发文 集研管字（2014）第04号
发文编码： 01_JYGZ_2014_04

集团敏捷需求管理过程框架

签发人: 谢志华
签发时间:2014-09-12
时效: 自发文之日起生效
授权: 全体员工

第一章 总则
第101条 目的
为加快产品发展速度，推进市场驱动的产品研发，保障研发过程中产品与客户需求的一致性，并能快速迭代验证产品需求，动态调整产品以与市场互动，特发布敏捷需求管理过程框架，指导各级研发组织制定和改进敏捷需求管理过程。
第102条 适用范围
机构：集团成员机构各级产品研发组织
产品：平台产品，标准产品，解决方案产品，移动互联网产品
第二章 制定原则
第201条 简化
简化流程与产出要求，精简评审活动。针对关键点评审要求目标明确，评审材料齐全，评委按照评审活动要求进行评审。
第202条 可裁剪
各研发组织可根据产品类型，成熟阶段和版本规模的管理需求，参考本框架自行裁剪流程和对应的产出文档，加快产品发展速度，保障持续验证，动态调整产品与市场互动。同时，发布产品的需求质量目标可根据产品类型，成熟度，规模进行调整和裁剪。
第203条 可落地
集团开发管理部配合本过程框架提供了平台,工具和服务，支撑敏捷需求管理落地。
第204条 持续改进
需求管理过程是基于集团敏捷研发过程体系的新增过程。基于敏捷过程体系将进行持续的改进，具备推广和复用价值的最佳实践也将逐步纳入到过程体系中。
第三章 敏捷需求流程概述

1) 敏捷需求管理活动,主要包括收集原始需求，编写产品需求条目，产品需求条目优先级排序（MVP）与估算，制定产品发布计划，拆分特征和细化需求，验证需求及发布产品，同时还包括全生命周期的需求跟踪活动。参与需求管理活动的主要角色包括PO， 需求分析师。具体活动执行可参考如下说明：
① PO,需求分析师获取用户原始需求，定期对原始需求进行梳理讨论，分析场景，初步评估优先级并确定解决方案，规划解决日期及产品版本。原始需求讨论确认后纳入需求池进行管理。
② PO基于需求池中的原始需求，进行产品需求条目的编写，并将需求条目纳入到Product backlog.针对需求条目编写概要需求文档，包括场景，整体解决方案,业务需求跟踪等，作为产品需求条目的细化补充。
③ PO组织团队对产品需求条目进行优先级的评定和估算，形成MVP。产品需求需要评审，可迭代进行。
④ 产品需求评审通过后，PO组织团队基于product backlog 制定产品发布计划。发布计划包括发布时间，版本类型，需求范围，质量要求等。评审通过后，制定相关开发和测试计划。
⑤ 产品需求条目评审通过后，需求分析师参考概要需求，对需求条目进行进一步的细化，与团队成员沟通产品详细解决方案，拆分特征条目和验收标准，形成Sprint backlog,开发团队基于特征进行设计，工作量估算和优先级评定；
⑥ 开发团队在Sprint中进行特征的开发，提交后形成可工作产品。需求分析师，PO及时针对可工作产品进行验证，PO主要验证产品需求条目，需求分析师主要验证特征,缺陷问题反馈给开发团队进行修正.同时，PO针对产品需求条目验证结果，调整Product backlog。
⑦ 需求验证通过后，提交集成，测试经理组织测试团队，按照待发布版本的质量要求，对产品进行集成测试和发布测试。开发总监组织团队进行发布产品资料的准备，推进团队按照发布流程发布产品。
⑧ PO在规划，立项评审通过后，建立需求跟踪矩阵，并在产品生命周期中，完善需求跟踪矩阵，当开发活动导致跟踪矩阵中产品需求条目变化时，更新需求跟踪矩阵。定期根据需求跟踪信息，报告需求的状态，确认开发产品与用户需求的一致性，并根据对比结果，调整需求和相关开发活动，应对变化。
2) 需求管理相关迭代活动如下：
迭代活动1（A->B->6）:需求分析师，PO基于业务场景与开发团队沟通产品需求，开发团队提交特征和产品需求条目后即可开始验证，验证范围包括特征和部分产品需求条目，验证结果及时反馈给开发团队，开发团队修正特征和产品需求条目的缺陷。此需求迭代活动周期一般小于Sprint周期，验证可随时进行。
迭代活动2（2->3->5->A->B->6）：编写产品需求条目，评定优先级和估算，需求细化及验证迭代进行。验证基于业务场景，主要验证产品需求条目,验证结果用于动态调整Product backlog及产品发布计划，以应对快速变化的市场需求。
迭代活动3（C）：Sprint开发，快速迭代开发符合一定质量要求的可工作产品,提供给PO，需求分析师，UE设计师，及相关干系人进行验证和反馈。
3) 评审点包括产品需求评审(D)，产品发布计划评审(E)
第四章 新特性概述
第401条 制定产品需求条目，细化需求，验证需求迭代进行。
产品需求条目的编写，拆分特征，以及产品需求条目，特征的验证迭代进行。Sprint开发前完成产品需求条目的编写，特征的拆分。迭代开发过程中细化需求，并与开发团队沟通需求，及时验证开发团队提交的特征和需求条目。需求工作的迭代周期最大不超过一个Sprint周期。一个Sprint 一般为2周，建议不超过一个月。
第402条 强化基于场景的需求沟通，评审活动聚焦。
需求分析，拆分，开发，测试和验证基于业务场景进行。基于业务描述编写产品需求条目,并以需求条目为线索传递需求，降低传递过程中需求失真。
关键评审活动包括评审产品需求和评审产品发布计划。 评审需求针对产品形态，概要需求，product backlog 中的需求条目进行评审，把控产品核心目标和关键业务场景。评审发布计划评审让PO，需求分析师，开发团队，测试团队，相关干系人和客户对整体的发布计划和节奏达成一致，并分别制定相关的开发，测试计划等。
第403条 拥抱变化，可动态调整Product backlog和发布版本的需求范围。
产品生命周期中，所有需求变化将产生新的需求条目，并纳入到Product backlog中，重新评估需求条目的优先级和估算，动态调整后续Sprint backlog和发布的需求范围。
第404条 强化需求池管理
增加了原始需求的管理,包括原始需求场景，解决方案，需求类型的管理。需求池管理在整个产品生命周期内进行，并作为产品需求溯源的重要管理手段。
第405条 强化需求跟踪与监控
通过需求跟踪矩阵，以产品需求条目为线索，跟踪产品需求的变化及产品开发，测试，验证等活动的一致性。
分析需求跟踪矩阵形成产品相关报告，与产品目标，产品范围，相关计划等进行对比，监控研发项目的状态，控制风险
第406条 需求过程模型可扩展。
敏捷需求管理框架，为独立的集成和发版测试团队提供了可扩展的接口，支持独立的测试管理流程。
第五章 附则
第501条   本过程体系及框架指引自发布之日起执行，其解释权归属用友集团开发管理部。

第502条  附件 ：《集团敏捷需求管理过程框架》，《PF_ARM_M_01敏捷需求管理过程》