用户故事

核心观点

用户故事以角色、可协商的功能和用户价值表达当前的问题定义，使团队能够围绕同一目的探索不同解决方案，并在业务建模中持续校正这一定义。

用户故事通常写成“作为某个角色，我希望获得某种能力，从而实现某种价值”。其中，角色—价值构成问题定义，功能只是当前可以讨论和替换的解决方案。把功能当成不可改变的需求，会让团队在尚未理解问题时就被既定方案锁定。

用户故事不是完整需求文档，而是业务价值的占位符。Card 只保留最重要的问题与价值，Conversation 用对话展开整体解决方案、用户旅程和例外，Confirmation 再以验收条件说明当前理解下怎样才算完成。因此，写出三段式句子不等于已经理解需求；故事的范围需要在具体场景中逐步明确。

全流工程师从用户故事开始，是为了先理解“为什么做、为谁做”，再讨论“怎样做”。这一步把客户或产品头脑中的业务诉求转成可供团队继续探索的问题，但它仍压缩了大量没有被说出的业务知识，需要通过业务建模进一步展开。建模若暴露角色、价值、功能范围、场景或验收条件的理解错误，反馈应返回故事修正，而不是让故事继续充当固定输入。

在双向知识流中的位置

• 消费：业务愿景、角色目标、整体解决方案以及产品和运行反馈。
• 产生：由角色—价值定义的问题、可协商的功能和验收意图。
• 校验：通过业务对话、模型展开、验收场景和产品评价检查问题定义。
• 回流：模型或结果暴露偏差时，修正角色、价值、功能范围或验收条件。

知识连接

• 参与：功能方案反馈循环——故事、模型与中间增量在 Kickoff—Desk Check 中持续校正。
• 提供给：业务价值反馈循环——故事把整体业务目标切分为可以进入迭代的价值假设。
• 延伸：用户故事的角色—价值结构——它进一步说明角色、功能与价值在用户故事中的不同稳定性。
• 导向：业务建模——用户故事给出问题和价值，业务建模继续展开支撑它的概念、规则与场景。
• 反馈来自：业务建模——模型与场景可能暴露故事中的角色、价值、范围或验收条件需要修正。

⚠ Switch to EXCALIDRAW VIEW in the MORE OPTIONS menu of this document. ⚠ You can decompress Drawing data with the command palette: ‘Decompress current Excalidraw file’. For more info check in plugin settings under ‘Saving’

Excalidraw Data

Text Elements

问题定义在对话中变清晰

Card

Conversation

Confirmation

歧义出现，再回到对话

Embedded Files

3313f807a9ac206f9d36daa658c543cafaf4d9e5: Icon - 用户故事, 卡片, 占位符, 角色, 功能, 价值, 需求, user story - Flaticon.excalidraw

2bf81e21806cddc35caaf0bd4fcdcb925b901660: Icon - 对话, 沟通, 协商, 参与方, 客户, 交付团队, 功能方案, conversation - Flaticon.excalidraw

103b1a228d4e998bd6372779135a5f303bc50471: Icon - 验收, 确认, 批准, 清单, 勾选, 条件, 范围, confirmation - Flaticon.excalidraw