用户故事虽小，用好了不易。谈谈我观察到的用户故事之“上中下”三品。
下品：写故事
哪有什么用户故事，我只不过是把之前写需求规格书的时间用在了写用户故事上。
特点
- 内容丰富。从业务流程说到 UI 设计，甚至连像素都定好了。
- 主语不是用户。比如：“显示商品列表?！倍皇牵骸颁郎唐妨斜怼薄?/li>
示例对话：
- 程序员：“这个提示信息应该是什么？你 Story 里没写??！”
产品经理：“好，应该是‘名称不可为空，接叹号’， 你等等，我补一下。” - 产品经理：“你写代码前能不能好好读一下我的验收条件？”
程序员（盯着电脑，阅读理解中）：“中！”
解读
这只是披着用户故事的皮，实际什么也没改。
- 团队内的交流仍以文档为准?？谕匪档牟凰闶?，出了问题没法撕。
- 没有站在用户角度，更没有站在用户角度思考。
中品：讲故事
有些故事，还没讲完，那就算了吧。那些需求，在岁月中，已经难辨真假。
特点
- 内容适中，只写重点。
- 在需求梳理会上，产品经理讲，其它人听。
示例对话：
产品经理：“blabla，听明白了吗？不明白我再讲一遍?！?br>
程序员（一激灵）：“我没睡着。”
解读
团队开始面对面交流，而不是背对背拥抱了。但大部分时间都是产品经理的单向输出。
根源在于分工太明确：产品经理负责用户故事，程序员负责写代码。
要进入上品，需要转变意识：产品经理负责产品价值，产品经理和程序员一起负责用户故事。
上品：聊故事
我有酒，你有故事吗？
特点
- 内容简短，刻意留白。
- 需求梳理会上，你一言我一语，大家参与度都很高。
常见对话
程序员：“为什么有这个业务规则？”
产品经理：“这个背景是这样的，作为一个销售……”
程序员：“明白了。那我举个例子……是这样吗？”
解读
用户故事是对业务需求的解决方案，它至少应该考虑到
- 业务价值
- 产品方向
- 技术可行性
这就需要团队聊出一个平衡来。
结尾
用户故事不是需求，它是一个用来“理解需求，共创解决方案”的协作工具。
所以上中下三品，非针对产品经理或者程序员，而是说的整个团队。要达上品，不是单个角色凭一己之力可以达成。
祝大家开心编故事。
