1. 概述
产品Scrum是一种兼顾项目Scrum的敏捷产品设计/迭代过程，由于开发团队对每一个Sprint冲刺开始后，留给产品的下一期Backlog时间都比较紧张，所以需要产品快速迭代，满足开发能在前一个Sprint交付后提供下一个Backlog计划，满足对接整个Scrum关系链条的闭环运转；
不同于常规的产品流程，产品/需求分成两个方向进行（常规功能迭代和用户需求管理），合成一个Backlog阶段，Sprint一个周期，Review两个方向，一般产品Scrum整个时间过程要求为1～2周，（还有一个方向是规划产品方向，这个只有在产品初期进行，目前版本不进行详释）；
1.1 产品Scrum角色
1.2 Scrum规范总体流程图
2. 产品Scrum方向
2.1 常规功能迭代
从系统模块和功能扩展的角度完善项目，一般以增量为主
1. 主要文档维护围绕Axure进行，记录所有的模块结构，原型UI
2. 在原型UI上直接标注需求描述，分为页面触发事件和规则流程，如下图
2.2 用户需求管理
从对接外部服务用户体验和用户需求的角度完善产品和服务，一般以快速响应和任务临时穿插
1. 主要文档维护围绕《搜索用户需求管理》进行，记录所有用户的内/外部需求集合
2. 通过有道云笔记可同时进行多人维护，主要由运营和产品进行维护，每一个用户需求必须进行问题剖析，给出处理意见，并反馈用户
3. 通过剖析需求，快速整理出影响的用户使用模块，新需求等，并初步进行ROI评估
2.3 Backlog合成阶段
产品会维护一个按优先级排序的“产品待开发项”（Product Backlog），即从客户价值理解、描述产品功能条目，项目经理和PD会逐一挑选优先级最高的部分进行分解，形成每一期的Sprint计划，召开Sprint计划会(Sprint Planning Meeting)。评审团队可就Backlog细节、完成标准，预期时间等进行询问，评审完成后，开发经理和开发团队会逐条估算开发成本和人日，直至任务量饱和，估算结果反馈项目经理和PD，PD把分解掉的Backlog录入TFS(Team Foundation Server)，开发经理进行任务的指派，一旦迭代开始，计划任务将不会发生大的发化。
2.4 Sprint任务跟踪
在Sprint迭代期内，开发团队将决定任务分配，逐一完成任务。每天团队会进行一个简短的站立会议即每日站会 ，沟通当前进度、下一步任务和当前存在的问题，PD通过TFS看板可直接关注任务进度进行跟踪答疑。通过TFS的“燃烧图”（Burn Down Chart），所有任务的累积剩余时间随开发进程与日递减的图形，以观察和预测所有任务是否会按期完成
2.5 Review Meeting
在每个Sprint迭代的最后一天，团队会召集评审会，邀请项目经理、产品、运营、测试以及开发团队等参加，对已经完成的Sprint条目进行评审，项目经理、产品、运营、测试做出判断并给出改进反馈。
在每期Sprint完成后会召开回顾会，会对本次迭代的优点与缺点之处做出总结，主要针对Sprint计划中的用户需求满足和常规功能迭代以及Sprint开发阶段成果复盘，并在以后迭代中进行改进。
网友评论