12｜使用LLM辅助用户故事编写
徐昊
你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
上节课我们介绍了为什么用户故事是大语言模型（Large Language Model，LLM）时代提取业务知识的最佳形态，以及一些编写用户故事的最佳实践。由于用户故事侧重于定义问题，而 LLM 往往更擅长提供解决方案，似乎对于用户故事而言，LLM 并不能提供太多的帮助。
然而 LLM 仍然可以在用户故事编写的环节给予我们帮助。主要是从验收条件入手，帮助我们提取整体解决方案，完善用户故事或是将整体解决方案的细节补充到用户故事中去。
那么今天我们就来看一下，如何利用 LLM 帮助我们更好地编写用户故事。
验收条件与用户故事
用户故事的特质可以总结为 3C，即 Card，Conversation 和 Confirmation。Card 是指用户故事的物理载体，即索引卡（Index Card）。因为索引卡面积有限，不能事无巨细地写下所有需求信息，只能关注最重要的信息也就是用户价值。其他的不可言说知识则通过对话（Conversation）的这种社交活动传播。
在对话过程中，最重要的目标就是明确这张故事卡的验收条件（Acceptance Criteria）有哪些，也就是如何确认（Confirmation）卡确实做完了。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
1. 用户故事的特质可以总结为3C，即Card，Conversation和Confirmation，其中验收条件是用户故事的重要组成部分，用于帮助明确产品或功能的期望表现、功能要求和可接受的标准。 2. 验收条件遵循假设/操作/结果（Given/When/Then）格式，用于清晰地描述功能的期望行为，需要结合业务上下文来编写。 3. 用户故事的功能范围并不是固定的，随着卡片的拆分和细化，每个用户故事的范围都可能发生改变，只有沟通过的验收条件才表示用户故事的具体范围。 4. 用户故事只是业务价值的占位符，在沟通确认之前，具体的功能需要在沟通中才能细化。 5. 使用LLM辅助用户故事编写时，需要提供整体解决方案和用户旅程作为业务背景说明，然后让LLM根据这些信息进行提问，并由人来回答，最终由LLM编写验收条件。 6. 通过与LLM的问答交互，可以有效地理解用户故事，重点在于对整体解决方案和用户旅程的掌握程度，以及编写清晰的验收条件。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《徐昊 · AI 时代的软件工程》，新⼈⾸单¥98
《徐昊 · AI 时代的软件工程》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
一只豆“用户故事”一直在模糊的用，上节课被老师推荐Mike Cohen 的《User Stories Appiled》赶在本节课更新前看完了，感觉如梦初醒恍然大悟，也更加觉得老师上节课对于“三类用户故事”的总结精辟实用。也引出本节课程的模糊点： 书中的“捕获”比喻和老师本节课中说的“用户故事可能变化”，都给我传递出：用户故事只是对 模糊需求空间进行逐步清晰、逐步描述的载体。相对应的，整体解决方案应该也是阶段性动态的，用户旅程也是阶段性动态的。（不知这理解对吗？） 所以，本节课教的 LLM 辅助用户故事编写的核心价值是不是可以理解为： 可以先 high level 描述整体解决方案和用户旅程，然后 通过一个个用户故事的 TQA 式对话，一步步让人类在 LLM 引导下，让 high level 的解决方案以一个个用户故事的形态 拆解出来。因为用户故事也能驱动测试，测试进一步驱动开发。所以，从整体软件工程视角看，我们通过 LLM 对需求这个复杂空间做了快速探索/试错，具体来说就是对需求和解决方案都完成了拆解，于是把最重要的“做正确的事”部分啃下来了？ 不知道是否 get 到真经，还请指教～2024-04-03归属地：广东
赫伯伯用户旅程又是如何产生的呢？2024-04-03归属地：北京
收起评论