本文面向人群：主要是产品经理和想要学习设计用户故事看板概念的项目经理、敏捷教练。本位内容：本文介绍了产品经理如何使用用户故事，整合成看板，参与敏捷开发。
目录：
• 什么是敏捷开发？
• 什么是Scrum? Scrum标准流程是什么？
• 产品经理（Product Owner），在一次Sprint（迭代）中需要做什么？
提供本次迭代需求列表 Sprint Backlog
学会冻结需求，增加需求变更难度
撰写用户故事User Story，创建用户故事看板
迭代启动会 Sprint Planning Meeting 讲解 User Story
建议参加每日立会 Daily Standup Meeting
参加验收会Review Meeting与主导培训会
参加反思会/回顾会Retrospective Meeting
用户故事的3C原则和INVEST原则
什么是敏捷开发？
定义：敏捷 = 快速 + 灵活
用处：解决 进度预测、质量保证、成本控制、软件维护、功能不满足的问题
什么是Scrum?
Scrum是一种迭代式增量软件开发过程，框架如下：
两个文档：
需求列表 Product Backlog
本次迭代（冲刺）规划的需求拆解 Sprint Backlog
三个角色：
产品负责人 Product Owner
敏捷教练 Scrum Master
技术团队 Team
四个会议：
迭代启动会 Sprint Planning Meeting
每日立会 Daily Standup Meeting
评审会 Review Meeting
反思会/回顾会 Retrospective Meeting
Product Owner，在一次Sprint（迭代）中需要做什么？
一、提供本次迭代需求列表 Sprint Backlog
Product Owner 平时负责对User Story进行分析，整合成的Product Backlog，然后进行优先级排序，形成本次迭代需求列表 Sprint Backlog。
ZJICMHAHAH：产品方法论 | 需求分析与需求管理
二、学会冻结需求，增加需求变更难度
都叫敏捷开发了，可见快速和deadline的重要性，为了避免项目延期、成员灰心丧气，Product Owner 学会需要冻结需求，对外公布一个冻结需求的合理时间点。
如果碰到有的情况，真的无法拒绝需求的变更，那就增加需求变更的难度。给一个需求变更申请表，让相关负责人领导进行确认签字，担负起项目风险。
三、撰写用户故事，创建用户故事看板
在敏捷开发中，可以试用用户故事起到需求挖掘、需求分析，并描述实现细节来代替PRD。（类似各大项目管理平台中的看板）
描述从用户的角度中进行
我作为<某类角色>
我希望做<某件事情>
从而使我得到<某种成果>
用户故事流程：
1、明确真实场景下，某类的用户要做某件事情、期望得到某种成果。
背景：一个类似美图的APP的餐馆列表
如一级用户故事：我要和朋友三人不在同一个地方上班，下班以后要在一个位置中间的地方，一起吃一顿300左右的东北菜，吃得饱又实惠。
真实场景：不在同一个地方上班
某类用户：想吃东北菜
成果：吃得饱又实惠、而且对三人来说到达时间类似。
2、拆解成二级用户故事
我和朋友三人不在同一地方上班，下班以后要在一个位置中间的地方吃饭。
我和朋友三人要吃一顿东北菜
我和朋友三人要吃一顿300左右的饭
我和朋友三人想要吃得饱又实惠
3、二级故事代替（看清本质，背后的想法）
为什么要吃东北菜？如果是因为东北菜量大，300吃得饱，那如果能找到其他菜吃得饱行不行？行。
如果餐馆条件很好，稍微贵一些行不行？行。
如果交通便利，到达时间类似，但是位置不是中间行不行？也可以。
4、实现细节：明确了有极限值和边际成本，是一个极小的、可测试的用户故事
我输入三个位置和设置筛选条件为餐馆，就能帮我找到三人到达时间类似的餐馆。餐馆按距离和时间进行XXX算法后排序。每页10条数据。
我设置人均价格区间80-120就可以帮我找到这样的餐馆，输入框必须数字键盘，只能输入正整数，输入不能超过10位数。如果无数据显示‘暂无数据，推荐您设置人均价格100-150，60%的人在这个价格区间找到了心仪的餐馆。’
我选择关键字标签‘实惠’就可以帮我找到这样的餐馆，可以不选标签，同时只能选三个标签。
1-4点可组成 用户故事地图
四、迭代启动会 Sprint Planning Meeting 讲解 User Story
Product Owner 负责讲解 User Story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的 User Story列表
会前：
会前干系人沟通、提前两天预约-半天时间提醒，通知时候说明会议涉及内容
充分准备 功能清单、流程图、产品原型
会中：
防止偏离主题、纠缠细节；会议记录
说清楚这个功能是为了什么，帮助理清思路
会后:
发出会议纪要、按决议修改需求后封锁外部需求
后续子会议：项目团队对每一个用户故事进行任务分解，每个故事不得超过一定时间（2天），终每个任务都有明确的负责人，并完成工时的估时。
五、每日立会 Daily Standup Meeting
Product Owner 建议参加，每天Scrum Master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。进行用户故事看板的变更。
六、验收与培训会
在本次迭代结束前，给 Product Owner 演示验收并接受评价的会议。
后续子会议：演示培训会议，相关人员（客服、运营、销售、技术支持等）都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由 Product Owner 整理，形成新的Story。
七、反思会/回顾会 Retrospective Meeting
在本次迭代结束后，由Scrum Master主持， Product Owner 和 Team 参加，谈谈什么有改进了，什么还需要改进。
用户故事的3C原则和INVEST原则
3C原则：
卡片（Card）
会话（Conversation）
确认（Confirmation）
INVEST原则：
Independent：独立性
用户故事之间应该具有独立性，一般可以通过组合用户故事或者分割用户故事来减少用户故事间的相互依赖性。
Negotiable：可协商
用户故事是和客户后协商制定的。
Valuable：有价值
用户故事对于用户是有价值的，因此应该站在用户的角度去编写。
Estimable：可评估
对于一个用户故事的划分需要足够的领域知识，故事本身不能太大，可评估。
Small：短小
故事应该尽量的短小，短小的故事可以减少分解过程中估算的误差。
Testable：可测试
作者：ZJICMHAHAH，本文在PMCAFF社区发布，转载请注明作者及出处。
