一款产品，如果你的用户距离你相对较远、也抽象，比如你们隔着手机、电脑屏幕，或者国家，甚至于只是因为你所处的并非直接接触用户/市场的部门，那么用户故事都会是得力助手。但怎么用？是什么？是必须搞明白的。——📝2023年8月

PART 1 被打断的抓狂午休

大中午被楼上一群讨论吵醒（我在工位上午休，阁楼上几个成员肆无忌惮的大声嚷嚷ing），在纠结：

“用户故事是什么？”

“用户故事一定要能独立上线？”

“怎么对齐产品、项目、研发、测试多方需求理解？”

无聊而深刻又简单的疑问，你能想到这是哪些角色在讨论？项目pm、开发leader、研发管理者。（内心os：能不能自己去思考一下，学习一下啊！能不能来一个敏捷思想的实践者啊！）

1、用户故事是什么？

这部分请看下面 PART 2 详解。

2、用户故事一定要能独立上线吗？

先请参照用户故事的定义和意义。然后再回来说，用户故事不一定要能独立上线，用户故事可能归属于史诗故事，史诗故事一定是可以独立上线的，但是用户故事不一定。用户故事打散，它会对应用户的一个完整的行为，故事是让产品研发协作链路对标，颗粒度在于用户的任务流。

3、怎么对齐产品、项目、研发、测试多方需求理解？

一句话，高质量的交付，一定是为了用户价值，满足用户的交易行为。着眼脚下，心怀远方。

PART 2 用户故事是什么？干什么？

时间、地点、人物、事件，有用户、有场景、有行为、有时机，背后当然也有情绪价值。

团队最近尝试改版以前的需求卡片，调整为用户故事卡片，这件事情对谁最好，当然是开发、技术、测试（不接受反驳）。

史诗故事>>用户故事>>任务>>里程碑，是不同维度和对象的拆解实现路径。产品经理关注商业价值、用户需求、产品架构、产品路线，拆分出来故事点，开发、测试同样需要对齐故事背景，共同目标是：对用户的交付目标，而不是程序、测试的实现目标，更准确的说是共同的商业目标。

用户故事的视角，便于研发团队成员对齐目标（大目标路上的小节点），找到方向感，共同推动总目标的达成，有点像飞书中可视的中心okr。

任务是开发基于用户故事背景拆解的实现路径，是程序的建构和解构动作。任务的颗粒度对应不同的开发者、工作量、起止时间，任务决定了整个项目研发的进度计划、工作间的逻辑关系、资源计划等。

开发关心用户故事，不只是开发leader关心用户故事，每个任务的开发者也需要关心当前任务服务于哪个用户故事。这个逻辑可以对标产品维度的用户画像。

当然，故事是故事、任务是任务、发布是发布，故事线是用户视角、任务线是代码实现视角、发布线是系统版本管理/代码分支管理双重视角。任务从故事里面长出来，故事进入版本，任务进入发布范围。

产品、开发、测试都关心用户故事，目的是在相同的方向上分别结合自己的专业视角拆解，建立实现路径、排除异常，最终满足用户交易价值。