敏捷交付方案.pdf

敏捷交付⽅案

需求承接流程

核⼼流程节点操作规范

1、⼯单级需求提出

需求⽅通过钉钉、邮件等⽅式向产品运营提出系统改进需求，产品运营根据与需求⽅沟通，获取需求

背景、需求描述。

2、创建⼯单

产品运营在“TAPD”中创建新的⼯单需求。需求分类、模块、⼊池时间、类型、需求提报⽅、产品

经理根据需求情况对应填写。⼤类勾选“⼯单”选项。完善需求标题，并在产品运营内容区填写“需

求描述”、“需求背景”内容。信息填写完成后提交并即时通知项⽬经理和对应产品经理受理需

求。

3、⼊池评估

项⽬经理收到产品运营需求⼯单后，与对应产品经理共同了解需求内容，如有需要可直接与需求⽅进

⾏需求沟通。由项⽬经理主导产品经理辅助判定需求体量、需求价值、紧急程度及是否将需求纳

⼊“敏捷交付”范畴。

P0级需求同步⾄直管总监处进⾏需求控制，P0级需求可在⽆需求交付情况下紧急开始研发，对此类

需求进⾏严格项⽬管理⼯作。

如评估需求不符合⼊池要求，则将本⼯单需求划归到“传统需求池”。

如评估需求符合⼊池要求则进⾏后续原型设计⼯作节点。

⼊池评估标准：

需求体量：项⽬侧进⾏需求整体实现体量预估，产研⼯作量在多端并⾏3天以内的需求准许⼊池。研

发⼯作量可协调组内研发负责⼈共同评估。

优先级：根据影响范、影响程度、资源投⼊情况进⾏综合评判。对影响范⼤，程度深，资源投⼊

相对较⼩的需求准许⼊池。

P0需求：战略关注、⾼管关注、核⼼业务卡点等类型需求准许⼊池。

传统需求池：

瀑布项⽬管理下产品需求池，区分于敏捷交付下的需求池。

4、原型设计

通过⼊池评估后的需求，产品经理根据需求内容进⾏原型设计。设计完成后在“TAPD”上对应需求

中产品经理内容区填写“需求调研卡⽚地址”、“需求PRD地址”内容。设计交付产出物包括不限

于：产品结构脑图、核⼼业务流程图，原型框架图。

5、需求交付

需要研发评审的需求在原型设计完成后对项⽬组内的负责⼈进⾏需求澄清，确保需求逻辑合理、内容

完备、与现有系统⽆冲突。需求交付完成后，组内负责⼈需要根据需求内容进⾏⼯作量评估，原则上

需求⼯作量评估最晚在需求交付完成后第⼆天站会中完成评估。评估的时间由项⽬经理

在“TAPD”中维护及更新。

⽆需评审的原型直接进⾏插⼊计划判定，需求⼯作量评估同上。

6、插⼊计划判定

交付完成后，项⽬经理进⾏拆⼊⽬前需求实现计划的判定，该判定依赖于⼊池评估中优先级评估及紧

急程度评估。

如评判为不插⼊⽬前需求实现计划的需求划归到“敏捷需求池”，与“敏捷需求池”内的其他需求做

横向优先级评判，在功能实现过程中按优先级顺序进⾏推进。

如评判为插⼊⽬前需求实现计划的需求则直接推⾄研发、测试侧做计划调整。

敏捷需求池：

符合敏捷交付条件的需求列表。表内记录符合敏捷交付条件的需求，从需求⼊池后⾄需求发布完成的

所有需求的当前状态、优先级、⼯作量等信息。项⽬经理负责维护敏捷需求池，并进⾏需求优先级排

定，研发及测试需按优先级顺序进⾏研发。如需调整研发顺序，需与项⽬经理进⾏沟通。

需求双向划转：

当敏捷需求池内需求数量不⾜以⽀撑敏捷交付运⾏时，可以从传统需求池内划转部分⾼优先级需求到

敏捷项⽬池，实⾏敏捷交付。

当敏捷需求池内需求数量超过15个时，或传统项⽬池内需要⼯单需求补充时，可以从敏捷项⽬池内

划转部分低优先级需求到传统需求池，进⾏分批交付。

7、计划调整：

计划调整代表着暂停当前正在研发的需求，⽴即开始新需求开发。研发及测试需要根据需求情况调整

⼯作及排期计划。如通过“紧急需求应急通道”做计划调整时，功能实现与原型设计⼯作并⾏推进，

项⽬经理协调产品经理完善原型设计⼯作，并及时做交付，完善功能场景。

8、功能实现：

研发、测试⼈员按需求进⾏开发及测试⼯作。功能实现前可预约产品⼈员进⾏⼆次需求澄清。

9、发布：

需求实现经过测试、验收，质量达到标准后，按发版计划发布到⽣产环境。所有敏捷交付项⽬必须可

独⽴发布，如需与⼤版本绑定发布，经沟通审批后可合并发布。

初步发版计划：

PC、⼩程序等产品迭代可在达到发布条件后经业务部⻔同意后即时发布。

APP等需要客⼾下载的产品集中⼀个迭代周期或两个迭代周期统⼀发布，控制产品更新频率。

待APP应⽤⽀持热更新后，采⽤即时发布⽅式进⾏更新，必须更新安装包时控制更新频率。

⾮核⼼节点操作规范

1、结果反馈：

项⽬经理在⼊池评估后，在"TAPD"上更新项⽬优先级，并将是否进⼊敏捷交付范畴及优先级情况反

馈⾄产品运营。产品运营需要将结果透传⾄需求⽅。

2、编写操作⼿册：

产品经理在需求交付