12｜使用LLM辅助用户故事编写

Apr 3, 2024

12｜使用LLM辅助用户故事编写-徐昊 · AI时代的软件工程-极客时间



下载APP





关闭

渠道合作

推荐作者

12｜使用LLM辅助用户故事编写

徐昊 · 徐昊 · AI时代的软件工程

课程介绍



讲述：徐昊

时长06:33大小6.00M



你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
上节课我们介绍了为什么用户故事是大语言模型（Large Language Model，LLM）时代提取业务知识的最佳形态，以及一些编写用户故事的最佳实践。由于用户故事侧重于定义问题，而 LLM 往往更擅长提供解决方案，似乎对于用户故事而言，LLM 并不能提供太多的帮助。
然而 LLM 仍然可以在用户故事编写的环节给予我们帮助。主要是从验收条件入手，帮助我们提取整体解决方案，完善用户故事或是将整体解决方案的细节补充到用户故事中去。
那么今天我们就来看一下，如何利用 LLM 帮助我们更好地编写用户故事。
验收条件与用户故事用户故事的特质可以总结为 3C，即 Card，Conversation 和 Confirmation。Card 是指用户故事的物理载体，即索引卡（Index Card）。因为索引卡面积有限，不能事无巨细地写下所有需求信息，只能关注最重要的信息也就是用户价值。其他的不可言说知识则通过对话（Conversation）的这种社交活动传播。
在对话过程中，最重要的目标就是明确这张故事卡的验收条件（Acceptance Criteria）有哪些，也就是如何确认（Confirmation）卡确实做完了。
因而，验收条件是用户故事（User Story）的重要组成部分，用于帮助开发团队和客户明确产品或功能的期望表现、功能要求和可接受的标准。
我们知道用户故事不是凭空产生的，而是根据用户的角色画像、整体解决方案以及用户旅程，拆分出来的。那么验收条件，实际就是在当前用户故事语境下，用户旅程或整体解决方案的细化和拆分。
在不知道用户旅程和整体解决方案之前，我们是无法给出验收条件的。仍然以我们前面的用户故事为例：
作为学校的教职员工（As a faculty），
我希望学生可以根据录取通知将学籍注册到教学计划上（I want the student to be able to enroll in an academic program with given offer），
从而我可以跟踪他们的获取学位的进度（So that I can track their progress）
由于我们不知道这个故事在用户旅程中处于哪个位置，以及整体解决方案是什么，我们就无法通过验收条件明确这张卡怎么算“做完”。因而，我们需要给出一定的业务上下文，比如：
整个学籍管理系统是一个 Web 应用；
 
当教职员工发放录取通知时，会同步建立学生的账号；
学生可以根据身份信息，查询自己的账号；
在报道注册时，学生登录账号，按照录取通知书完成学年的注册；
有了上下文之后，我们才能给出相应的验收条件。通常，验收条件遵循假设 / 操作 / 结果（Given/When/Then） 格式，这个格式能帮我们清晰地描述功能的期望行为。
假设（Given）描述了在什么条件下功能应该被测试。这些条件可能包括系统的状态、前提条件或输入；操作（When）描述了在给定条件下，用户将执行的操作或事件；结果（Then）描述了功能应该如何响应用户的操作或事件，也就是功能的期望结果。
比照这个格式并结合业务上下文，我们可以为前面的用户故事编写这样的验收条件：
Given 未完成注册的学生登录系统（用户旅程：在报道注册时，学生登录账号）
When 学生在注册页面点击“注册”按钮时（整体解决方案：整个学籍管理系统是一个 Web 应用）
Then 完成当前学期的学籍注册 （用户故事：我希望学生可以根据录取通知将学籍注册到教学计划上）
可以看到，这个验收条件中，我们包含了用户旅程，整体解决方案和用户故事中提及的功能。
需要注意的是，每一张用户故事的范围，需要参照其他用户故事才能确定。比如，下面这个验收条件：
Given 未完成注册的学生
When 学生登录系统
Then 收到提醒并转跳到注册页面
它是否是当前用户故事的验收条件，取决于是否存在这样一张用户故事：
作为学生（As a student），
我希望登录之后接收到注册的通知（I want to get a notification after login），
从而我可以不会错过学期注册的期限（So that I would not miss the registration）
如果存在这样的独立故事，那么这个验收条件就不在当前故事卡之中。如果不存在，那么有可能就需要包含这个验收条件。因而，用户故事的功能范围并不是固定的。随着卡片的拆分和细化，每个用户故事的范围都可能发生改变。只有沟通过的验收条件，才表示用户故事的具体范围。
因此，还存在一种说法，用户故事只是业务价值的占位符（Placeholder）。在沟通确认之前，它只表示用户想要达到的某种目的，而具体的功能需要在沟通中才能细化。
使用 LLM 辅助用户故事编写如果用户故事只是占位符的话，那么我们在使用用户故事表达需求的时候，到底传递了哪些不可言说的知识呢？
答案是显而易见的，是整体解决方案和用户旅程。我们是否能够有效理解用户故事，重点并不在故事本身，而在于对于整体解决方案和用户旅程的掌握程度。
按照这个思路，通过 LLM 辅助我们编写用户故事的前提是，我们已经有效地提取了整体解决方案和用户旅程。我们可以通过一个推理行动模式（Reasoning and act，ReAct）的变体想 - 问 - 答（TQA，Think-Question-Answer），使用 LLM 辅助我们编写用户故事。
由于 LLM 不善于定义问题，那么定义问题的部分仍需留给人来完成，因而 TQA 的整体思路这样的：
为 LLM 提供整体解决方案和用户旅程作为业务背景说明；
提供相应的用户故事卡；
让 LLM 根据业务背景说明，考虑对于给定的用户故事，还有哪些不清楚的地方，并根据这些不清楚的地方进行提问，并由人来回答；
当 LLM 觉得已经了解了所有的细节，那么 LLM 会为当前的用户故事编写验收条件。
那么让我们看一个具体的例子。TQA 的形式无法通过 ChatGPT 直接使用，需要构造一个 Agent 调用 ChatGPT 的 API 完成。
如上图所示，这个 Agent 分成三个部分，分别是用户故事、业务上下文以及与 LLM 交互的部分。
后面这个例子展示了我们如何利用这个 Agent，让 LLM 尝试理解我们给出的用户故事，并对用户故事进行提问。
我们与 LLM 的问答摘录如下， H 表示人（Human），L 表示 LLM：
让我们来谈谈这个故事的情节
 
L: 登记教学计划是否意味着该学生已正式入学？
H: 是的，学生们每年都要注册到教学计划中
 
L: 录取通知书是电子邮件还是实体邮件？
H：两个都有。教职员工会在学生登录系统之前创建帐户
 
L：学校是否有专门的系统或平台来跟踪学生的学位进度？
H: 对，这就是我们讨论的这个系统
 
L：学校需要学生提供哪些具体信息才能注册入学？
H：姓名、身份证以及提供给他们的录取通知书
 
L：学生是否必须在特定的时间内注册？
H：对，在每个学年的第一学期之前
在一系列问题之后，LLM 也给出了它认为的验收条件：
Scenario 1:
Given: 学生已经收到他们的电子录取通知书（The student has received their admission notice electronically）
When: 学生使用提供用户名密码登录到系统（The student logs into the system using their provided credentials）
Then: 提示学生注册，并提供他们的姓名、身份证和课程（The student is prompted to register their enrollment in the teaching plan by providing their name, ID, and the program they were offered）
 
Scenario 2:
Given: 学生已经收到他们的纸质录取通知（The student has received their admission notice through physical mail）
When: 学生使用提供用户名密码登录到系统（The student logs into the system using their provided credentials）
Then: 提示学生注册，并提供他们的姓名、身份证和课程（The student is prompted to register their enrollment in the teaching plan by providing their name, ID, and the program they were offered)
 
Scenario 3:
Given: 学生已经完成注册（The student has registered their enrollment in the teaching plan）.
When: 学校希望通过系统追踪他们获得学位的进度（The school wants to track the progress of the student’s degree attainment）
Then: 学校访问当前系统，并看到他们的进度（The school accesses the current system and views the student’s degree progress）
 
Scenario 4:
Given: 学校为注册设定了的截止日期（The school has set a deadline for students to register their enrollment in the teaching plan）
When: 目前已经超过截止日期（The deadline for registration passes）
Then: 没有完成注册的学生就不能继续注册了（Students who have not registered their enrollment in the teaching plan are no longer eligible to continue their studies）
小结我们感受到最直观的不同是，LLM 主要负责提问，而不是回答问题。LLM 提问的问题主要是关于解决方案的，这是一个什么系统？有哪些流程等等。
针对 LLM 提出的问题，我们有三种不同的应对方式：
如果 LLM 提出的问题，包含了对于基础概念或流程的误解，那么我们要重新定义和修改业务背景。
如果 LLM 提出的问题，包含了对于操作的误解，那么我们要重新修改用户故事。
如果 LLM 提出的问题，仅仅是关于交互细节的，那么我们只需要在会话中回答这些细节就可以了。
这三种应对方式也分别代表了三种通过 LLM 辅助用户故事编写的形式：通过 LLM 提取不可言说的业务知识，修改用户故事以及补充完善验收条件。
TQA 是我在去年（2023 年）年初的时候发明的一种 LLM 交互模式，在下一节课中，我们将详细讲解如何实现基于 TQA 的 AI Agent。
思考题当我们提取不可言说业务知识时，LLM 会问怎样的问题？
欢迎你在留言区分享自己的思考或疑惑，我们会把精彩内容置顶供大家学习讨论。

1. 用户故事的特质可以总结为3C，即Card，Conversation和Confirmation，其中验收条件是用户故事的重要组成部分，用于帮助明确产品或功能的期望表现、功能要求和可接受的标准。 2. 验收条件遵循假设/操作/结果（Given/When/Then）格式，用于清晰地描述功能的期望行为，需要结合业务上下文来编写。 3. 用户故事的功能范围并不是固定的，随着卡片的拆分和细化，每个用户故事的范围都可能发生改变，只有沟通过的验收条件才表示用户故事的具体范围。 4. 用户故事只是业务价值的占位符，在沟通确认之前，具体的功能需要在沟通中才能细化。 5. 使用LLM辅助用户故事编写时，需要提供整体解决方案和用户旅程作为业务背景说明，然后让LLM根据这些信息进行提问，并由人来回答，最终由LLM编写验收条件。 6. 通过与LLM的问答交互，可以有效地理解用户故事，重点在于对整体解决方案和用户旅程的掌握程度，以及编写清晰的验收条件。

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

2024-04-03

赞 6

提建议

11｜如何有效编写用户故事？

13｜构建基于TQA模式的AI Agent

 写留言

全部留言(10)

最新
精选

一只豆
2024-04-03 来自广东
“用户故事”一直在模糊的用，上节课被老师推荐Mike Cohen 的《User Stories Appiled》赶在本节课更新前看完了，感觉如梦初醒恍然大悟，也更加觉得老师上节课对于“三类用户故事”的总结精辟实用。也引出本节课程的模糊点：书中的“捕获”比喻和老师本节课中说的“用户故事可能变化”，都给我传递出：用户故事只是对模糊需求空间进行逐步清晰、逐步描述的载体。相对应的，整体解决方案应该也是阶段性动态的，用户旅程也是阶段性动态的。（不知这理解对吗？）所以，本节课教的 LLM 辅助用户故事编写的核心价值是不是可以理解为：可以先 high level 描述整体解决方案和用户旅程，然后通过一个个用户故事的 TQA 式对话，一步步让人类在 LLM 引导下，让 high level 的解决方案以一个个用户故事的形态拆解出来。因为用户故事也能驱动测试，测试进一步驱动开发。所以，从整体软件工程视角看，我们通过 LLM 对需求这个复杂空间做了快速探索/试错，具体来说就是对需求和解决方案都完成了拆解，于是把最重要的“做正确的事”部分啃下来了？不知道是否 get 到真经，还请指教～
展开
作者回复: 用户故事第一要务不是清晰需求而是清晰价值然后是明确roi
共 2 条评论
1
可乐了
2024-05-02 来自福建
"TQA 的形式无法通过 ChatGPT 直接使用，需要构造一个 Agent 调用 ChatGPT 的 API 完成。" 徐老师，如果要快速构造一个你文中提到的 Agent 用辅助用户故事的编写，有什么快速的构造方法建议？或者您这个是否可以提供使用？比如开源等方式。谢谢！
作者回复: langchain
范飞扬
2024-04-11 来自广东
用户旅程又是如何产生的呢？我假设“用户旅程”和“业务流程或交互流程”是类似的，那么我们就可以用老师在《如何落地业务建模》里面说过的“从收入流与成本结构中寻找事件”，来产生用户旅程了。
作者回复: 用户旅程是产品设计的
共 2 条评论
范飞扬
2024-04-11 来自广东
原文0 ==== 如果 LLM 提出的问题，包含了对于操作的误解，那么我们要重新修改用户故事。问题 === 老师，对这句话我有三问题~ 1、“操作”是指的什么？是指User Story里面的 I want 么？还是根据[原文1]，是指验收条件的 When 部分？ 2、如果“操作”指的是验收条件的When，那么根据[原文2]，应该修改整体解决方案把？而不是修改用户故事？ 3、可以举一个“LLM对于操作的误解”的问题的例子嘛~ 注释： [原文1]：操作（When）描述了在给定条件下，用户将执行的操作或事件 [原文2]：When 学生在注册页面点击“注册”按钮时（整体解决方案：整个学籍管理系统是一个 Web 应用）
展开
作者回复: 与验收条件无关毕竟在上下文里没有ac。操作是指i would like to部分
共 2 条评论
赫伯伯
2024-04-03 来自北京
用户旅程又是如何产生的呢？
作者回复: 方法非常多
范飞扬
2024-05-16 来自浙江
业务上下文 (又称业务背景说明或 Business Context) = 整体解决方案 + 用户旅程
6点无痛早起学习的和...
2024-05-03 来自北京
现在有点迷糊“业务上下文”和“用户故事”，这 2 者的关系和区别了
术子米德
2024-04-06 来自日本
🤔☕️🤔☕️🤔 【Q】提取不可言说业务知识时，LLM会问怎样的问题？【A】哪些概念存在、是否已经定义、能否举个例子？有哪些角色存在、何时何地上场？开始在哪里、过程有哪些、结束在哪里？何时无法开始、会有哪些异常、何时放弃？任何操作改变哪些状态、引起哪些变化？ — by 术子米德@2024年4月6日
术子米德
2024-04-06 来自日本
🤔☕️🤔☕️🤔 【R】用户故事，它处于问题的定义域，LLM，它处于问题的解决域，逻辑上而言，LLM依赖问题的清晰定义，然后给出具体的解决方案。不过，在用户故事定义后的验证环节，LLM可用来提取整体方案、完善用户故事。此时，采用TQA（Think-Question-Answer），让LLM对用户故事进行提问，而非回答问题，尤其是让LLM向用户故事发验收条件方面的问。【.I.】对话（Conversation），在提纲下聊，就像个提线木偶，僵硬感十足，在发散下聊，就像西红柿在溜冰，刚开始奔放自由到僵硬冻住；如果盯住价值，就是这会对我有实用或有意义，并且对于什么条件达到接受有共识，那么在手心有把握感后，会迅速期望暂停，先把这到手的东西给实现，算是成功对话嘛？【.I.】助手（Copilot），他能帮我干任何事情，把事情扔给他就行，结果得我自己来判定。当我清楚想干啥，那就给任务列表给助手，当我还在弄清楚要干啥，那就让助手来协同，让他来向我发问，就像我提前找个评审方，在正式交付之前，先借LLM来预审。【Q】用户故事，占位符的含义，是指它在故事链的位置，随着这些位置出现关联和顺序，对应到整体解决方案和用户旅程，其中需求的不可言说知识，被逐步传递出来、并在用户故事里体现的过程？【Q】TQA里的L为啥能问出示例中的问题？ — by 术子米德@2024年4月6日
展开
I. Z.
2024-04-04 来自加拿大
太精彩啦！

