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

Apr 1, 2024

11｜如何有效编写用户故事？-徐昊 · AI时代的软件工程-极客时间



下载APP





关闭

渠道合作

推荐作者

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

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

课程介绍



讲述：徐昊

时长08:09大小7.46M



你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
前面几节课我们讲解了如何使用 LLM 辅助业务建模，这个过程里，我们非常依赖用户故事作为业务上下文的输入。那么怎么写好用户故事，就成了我们利用 LLM 建模的关键。
今天我们就了解一下用户故事，以及为什么用户故事是适用于 LLM 的需求表示形式。
用户故事与功能需求对于之前尝试使用用户故事管理需求的同学，可能一直有这么个疑问，用户故事一共也就三两句话，怎么能把复杂的功能需求说清楚呢？而这恰恰是用户故事的强大之处，也是用户故事能够匹配 LLM 的原因。
让我们回看一下在前面的几节课中一直使用的例子：
作为学校的教职员工（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 系统，那实际操作的过程可能是，学生打开页面，看到自己的录取通知书，点击完成注册。同样的流程也可以在手机应用上实现，只不过交互流程就变成在手机上打开一个界面，看到自己的录取通知书，点击完成注册。
当然，没有用户界面的情况也可以实现，比如这是一个后台的 API 服务，那么需要根据学生的录取通知书调用对应的 API 完成注册。
而在这个用户故事里，我们并没有提及具体的技术方案到底是什么。这也就是用户故事与功能需求的一个重大差异。用户故事侧重于定义问题，而功能需求往往包含着解决方案。
正如我们前面的课程中提到的，在使用 LLM 辅助时，问题的定义是困难的，而获取解决方案则容易得多。就以这个用户故事为例，我们可以很容易地让 LLM 给出不同的技术解决方案。比如想要实现为 Web UI：
用户故事
=======
作为学校的教职员工（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的交互流程
再比如，我们也可以让 LLM 帮助我们将这个需求实现为 RESTful API：
用户故事
=======
作为学校的教职员工（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）
任务
===
请为这个用户故事设计API
当我们关注于问题定义时，恰好也能帮我们应对需求的改变。回想一下过去二十年的技术变迁，从企业内网应用转为 Web 应用，到移动应用，再到前后端分离、功能服务化等等。我们有太多的时候，需要在不同的技术解决方案上，达成同样的目的，实现同样的价值。
当关注知识本身和问题定义时，可以让我们抽离具体的解决方案。因而用户故事本身就是一个更关注知识管理的需求管理方法。通过用户故事提炼知识之后，就可以借助 LLM 帮助我们在不同的技术解决方案上迁移了。
如何有效编写用户故事有太多的文章和书籍是关于如何编写用户故事的，你可以参考 Mike Cohn 的《User Stories Appiled》以及 Alistair Cockburn《Writing Effective Use Cases》。这两本书的介绍更为全面。这里我着重分享一些我个人认为特别有用的技巧。
我们常用的用户故事格式通常是三段式：
As a/ 作为 < 角色 >
I’d like to/ 我希望 < 功能 >
So that/ 从而可以 < 价值 >
我们首先需要注意的是，对于任何一个用户故事而言，角色 - 价值是不变的，而功能可以随时发生改变，是用户故事中“可协商”的部分。换句话说，角色 - 价值定义了要解决的问题，而功能只是解决这个问题的一种方法而已。举个例子：
As a 系统管理员
I’d like to 注册用户通过用户名 / 密码登录系统
So that 追踪不同用户的行为
在这个用户故事中，“系统管理员 - 追踪不同用户的行为”是问题定义，而“注册用户通过用户名 / 密码登录系统”则是功能。这个功能可以换成其他形式，而不影响我们要解决的问题。比如“注册用户通过微信账号登录系统”也是一个可行的解决方案：
As a 系统管理员
I’d like to 注册用户通过微信账号登录系统
So that 追踪不同用户的行为
第二点需要注意的是找到真正的价值。真正的价值并不一定发生在发起操作的这个角色身上。在这个登录的例子中，另一个常见的写法是：
As a 注册用户
I’d like to 通过用户名 / 密码登录系统
So that 访问我的个人信息
这里我们认为价值体现在“注册用户 - 访问我的个人信息”，而不是“系统管理员 - 追踪不同用户的行为”。那么我们就需要区分哪个才是真正的价值。也就是登录是系统管理员受益更多，还是注册用户受益更多？
很显然，在一些场景下，用户登录对于用户本身并没有受益，比如，需要登录才能访问别人写的文章。这就是额外的步骤，并没有额外的价值，那么价值就不可能是发起操作的这个角色。类似的情况还有很多，比如员工打卡，显然员工自身的收益不会多过管理者，因而不能从员工的角度书写这个故事。
第三点就是如何编写有意义的价值陈述。价值陈述需要从用户故事拆分的方式入手，才能找到合理的切入点去阐述，否则容易陷入对于功能的复述。比如，在不知道其他功能的前提下，用户登录很容易就会写成：
As a 注册用户
I’d like to 通过用户名 / 密码登录系统
So that 我们可以登录系统
想要改正这个明显没什么价值的价值陈述方式，我们需要思考这个用户故事是怎么切分出来的，与它相关的有哪些其他用户故事，才能更好地完成价值的陈述。这里，我总结了一个用户故事拆分方式，可以帮助我们更好地寻找价值陈述：
按照这样的方式拆分用户故事时，我们需要找到不同用户角色的目标，并根据这些目标设计整体解决方案。整体解决方案中包含业务中的核心概念、关键规则和主要流程。然后我们再根据整体解决方案，设计不同角色的用户旅程。接着我们就可以从用户旅程上切分用户故事了。那么此时，用户故事只有三种写法：
So that 可以满足某个用户角色的目标
So that 可以满足整体解决方案的规则或流程
So that 可以进行用户旅程的下一步
比如以学籍管理系统为例。教职员工这个用户角色，核心目标是追踪学生是否完成了教学计划的学习；而学生这个用户角色，他的核心目标是按照教学计划完成课程学习。
那么针对于这些目标，我们的整体解决方案是什么呢？我们的方案是：
设定一个教学计划，其中包含学生应该完成的所有课程，以及相应的学位。
为每一位学生指定一个学籍，也就是学习某个教学计划的资格。
学生需要根据教学计划，注册对应的课程。
学生可以根据教学计划，学习对应课程，并获得成绩。
每年依据学籍以及学生选课的成绩，判断学生是否能够毕业。
其中包含的主要流程是：发放录取通知、注册学籍、选课以及结业。根据整体解决方案，我们可以设计不同角色的用户旅程，比如，教职员工就是发放录取通知和结业的流程。而学生就是注册学籍和选课的流程。
那么学生注册学籍的用户故事，可以有这么几种写法：
作为学校的教职员工，
我希望学生可以根据录取通知将学籍注册到教学计划上，
从而我可以跟踪他们的获取学位的进度（满足角色的宏观目标）
作为学校的教职员工，
我希望学生可以根据录取通知将学籍注册到教学计划上，
从而我可以跟踪他们的学籍与成绩判断他是否能够毕业（满足具体解决方案）
作为学生，
我希望可以根据录取通知将学籍注册到教学计划上，
从而我可以跟踪教学计划学习对应课程（进行用户旅程的下一步）
这三种写法都是可以接受的用户故事。如果希望用户更加抽象一些，可以使用满足角色的宏观目标或满足具体解决方案的写法。
小结用户故事的特性被总结为 Card、Conversation 和 Confirmation，这表示少而精的文字描述（Card），一段对话以及需与交付团队和客户澄清的细节。这是一个典型的不可言说知识。然而也从侧面表明了，用户故事本身就是一种不可言说知识的管理工具。
在 LLM 的时代，我们应该永远优先聚焦于问题的定义，然后才是解决方案。用户故事恰好符合这些条件，所以它是适用于 LLM 的需求表示形式。
关于用户故事的编写还有很多细节和技巧，详细内容可以阅读我推荐的两本书，其中有更多有用的推荐。
思考题请按文中介绍的方法，根据你现在工作的场景拆分一下用户故事？
欢迎你在留言区分享自己的思考或疑惑，我们会把精彩内容置顶供大家学习讨论。

1. 用户故事是一种适用于LLM的需求表示形式，侧重于定义问题而不包含具体的解决方案。 2. 用户故事的简洁性使其能够匹配LLM，因为它可以用不同的技术方案实现，如Web系统、手机应用或后台API服务。 3. 用户故事的关注点在于问题定义，而功能需求则包含解决方案，这使得用户故事更适合应对需求的改变和技术变迁。 4. 用户故事提炼知识，使得借助LLM在不同的技术解决方案上迁移成为可能。 5. 用户故事的简洁性和抽象性使其成为更关注知识管理的需求管理方法。 6. 用户故事可以帮助软件工程师更好地理解业务上下文，从而更好地进行业务建模。 7. 用户故事的灵活性和通用性使其成为一种有效的需求表示形式，能够适应不同的技术解决方案和需求变化。 8. 用户故事的简短描述能够帮助团队更好地理解用户需求，促进团队协作和沟通。 9. 用户故事的重点在于描述用户的需求和期望，而不是具体的技术实现细节，这有助于更好地理解用户需求。

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

生成海报并分享

2024-04-01

赞 5

提建议

10｜LLM辅助建模（二）：构造思维链

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

 写留言

全部留言(15)

最新
精选

新的一页
置顶
2024-04-12 来自广东
受老师说的真正的价值启发，我举两个例子。业务场景：公司对不同的供应商下采购订单，供应商可以通过公司的系统看到他们的采购订单，但是要做数据权限隔离。用户故事1: 作为供应商我希望在采购订单这里只看到自己的采购订单这样可以免去我多余的查询操作用户故事2: 作为甲方公司我希望供应商在采购订单这里只能看到自己的采购订单这样可以避免因价格差异或大小单而导致的不愉快或纠纷以这两个例子来看，第一个用户故事有一种为了写用户故事而写用户故事的感觉，并没有在根本上体现出为什么要做数据权限，只是操作层面上的需求，没有特别大的实际业务价值。
展开
作者回复: 很好
2
赫伯伯
置顶
2024-04-01 来自河北
这个课有种倒序的感觉，一直盼着讲用户故事…………可能跟我做业务而不是做开发有关系吧
编辑回复: 顺序是按开发者熟悉程度安排的。一般开发会接触到模型并使用，少数会参与建模，更少数会参与需求挖掘。
共 2 条评论
1
范飞扬
2024-04-02 来自浙江
老师回复我说：“如果能写出需求那还要什么用户故事” 不太理解呀，因为本文里就说，用户故事是管理需求的[1]。既然用户故事是管理需求的，那不就是，先有需求，再有用户故事嘛？ Reference: [1] 本文原文：“对于之前尝试使用用户故事管理需求的同学，可能一直有这么个疑问，用户故事一共也就三两句话，怎么能把复杂的功能需求说清楚呢？”
作者回复: 用户故事是以不可言说的方式管理需求的技术。他不是一个特定的需求格式，把需求转成用户故事是没意义的。
共 3 条评论
4
范飞扬
2024-04-01 来自广东
用户故事显然就是 Kent Beck 说的 10% 的技能，那么如何发挥好？ 1 是看书，2 是可以尝试使用 LLM 提取用户故事。那如何使用 LLM 提取用户故事？目前的思路是，模仿 LLM 辅助建模的流程。比如，这篇文章就是个编写用户故事的方法，就是 CoT，那么 prompt 就可以是: ``` 需求文档 ====== {requirement} 编写用户故事的方法 ============ {method_for_writing_user_story} 任务 === 请根据上面需求文档，按照编写用户故事的方法，编写用户故事。 ``` 当然这是个很粗略的思路，还少了很多东西。比如，LLM 辅助建模的过程还有一个测试的过程。那如何测试 LLM 给的用户故事？这个问题我还没思路，还在研究中，不过打算先发出来抛砖引玉一下哈哈
展开
作者回复: 这是不行的如果能写出需求那还要什么用户故事
共 3 条评论
2
范飞扬
2024-06-09 来自广东
老师的图里写的persona, 经过老师的解释，我觉得更像是 user role ，而不是 persona。因为，在《User Stories Applied》里, persona 是对某一个 user role 的实例化，比如 Teresa(persona) 是 Instructor (role)的实例化。所以，不太懂，老师为什么在图里写的是 persona？写错了？
作者回复: 因为实际项目上用persona比user role多
共 2 条评论
1
术子米德
2024-04-04 来自日本
🤔☕️🤔☕️🤔 【Q】根据现在工作的场景，拆分一下用户故事？【A】<when>当某个功能会被拆分为几个部分，每个部分由不同的实体负责，这些实体之间通过消息收发来达到整体功能的效果。<as a>当我作为某个实体的设计开发，<i want>我期望有实体位置无关的通讯框架，无论实体在线程间、进程间、芯片间、系统间通讯，都不会被实体进行通讯操作所感知，<so that>这样的话，我的实体可以在系统间开发调试、部署到能运行效率最高的线程间通讯、或不同技术方案时在不同芯片间通讯，而我的实体间通讯处理的逻辑，始终保持一致，即跟实体之间的「介质无关」。 — by 术子米德@2024年4月4日
展开
作者回复: 这不是业务价值
共 2 条评论
术子米德
2024-04-04 来自日本
🤔☕️🤔☕️🤔 【R】用户故事这样的需求表示形式，跟基于LLM的建模方法，很般配。它是更关注知识管理的需求管理方法，它会让我们抽离具体的解决方案，这样就可以借助LLM帮我们在不同技术方案上迁移。 UserStory = As a「X=Who/Role」，I want 「Y=What/Func」，So that 「Z=Why/Value」。 Who/Role + Why/Value =》待解决的问题，先要定义清楚它，不变型最高，然后用What/Func解决它，可变空间很大。【.I.】谁是用户？操作者，如果他只是拿着软件完成任务，那么他的故事里的Why/Value，是否会收窄到赶紧完成、错了别赖我的窘境？这时候是否就要拉出「羊毛🐑出在狗🐶身上猪🐷出钱」的奇葩链，找出最后的🐷，甚至找出养肥猪的美食，才能跟踪挖掘到真正的价值。【Q】用户故事，已经说出来，在Card已写下、有Conversation可复述、有Confirmation来签字，咋就是不可言说知识的管理工具？难道不是提取工具吗？还有，已经被提取的知识，就该是显性知识，咋还是跟不可言说知识搅在一起？ — by 术子米德@2024年4月3日
展开
作者回复: card是占位 conversation，confirmation是socialization咋不是不可言说
共 2 条评论
李威
2024-04-01 来自湖南
所以，都AI时代了，用户故事这个古老的东西还是非常有价值，还是需要投入精力去好好学习掌握的咯。
作者回复: 一直都有用之前学不会而已
共 2 条评论
Geek_d19870
2024-04-06 来自广东
在LLM之前，我们解决问题的思路，也是先定位问题，然后才是分析解决问题的思路和方案。但在实际的实践过程中，容易出现一种现象：问题定义不全面，解决方案不完整，总有未考虑到的一面，其实也就是没有理论支撑。
3
范飞扬
2024-04-02 来自广东
开篇词提到：“在软件开发的不同阶段中，提取核心知识及关键载体，将它们表示成易于 LLM 理解的形式。” 在需求阶段，业务知识就是“核心知识”，模型和用户故事就是“关键载体”，mermaid 就是“易于 LLM 理解的形式”？
1

