系列文章

上一篇 用户故事验收测试

---

如有问题请留言

---

前言

了解了这么多的基础知识，接下来是一些额外的编写优秀故事的准则。

---

提示：接下来的所有理论都会伴随一个实际的例子，而所有例子都基于一个假想的职位发布和搜索网站。

文章概览

1. 从目标故事开始

• 在一个用户角色众多的大型项目中，了解用户使用我们软件的目的是非常重要的。例如求职者角色，他的最高优先级目标是找工作。因此可以从这个目标中分解出如下的目标：
  1. 搜索感兴趣的工作
  2. 自动搜索
  3. 让他的简历可见

2. 切蛋糕

• 当面临一个大的故事时候，通常可以将其分解成较小的故事。
  1. 求职者可以填写简历
  2. 简历表上的信息被写入数据库
• 写入数据库是建立在填写数据的情况下的，若没有填写简历，那么第二个写如数据库的故事是没有意义的，因此需要换一种写法：
  1. 求职者可以提交简历，简历上包括基本信息。
  2. 求职者可以提交简历，简历上包括雇主想看的所有信息。

3. 编写封闭的故事

• 封闭的故事是指，随着一个有意义的目标实现而结束的故事，能让用户觉得他使用之后确实完成了某个任务。
• 例如：”招聘者可以管理他发布的广告“
  1. 这不是一个闭合的故事，因为招聘者误发彻底完成的事情，而是一个持续性的事情。
  2. 改写这个故事：
     i. 招聘者可以审核针对他发布的招聘广告发的简历。
     ii. 招聘者可以更改招聘广告的过期时间。
     iii. 招聘者可以删除不适合的申请

4. 不要过早的涉及用户界面

• 过早的涉及用户界面，就说明很有可能你将需求和解决方案混合到一起了。
• 例如：用户可以在搜索界面上当的小部件上选择日期。这就是将界面包含到需求中的例子。

5. 有些需求并不是故事

• 系统故事只是描述系统功能的其中一个方法，还有其他方法，如果允许，一样可以使用

6. 在故事里包括用户角色

• 如果项目团队已经识别出用户角色，那么在编写故事时候就要使用：
  1. ”用户可以发布他的简历“改写成“求职者可以发布他的简历”。
• 一个简略的模板：“我作为（角色），想要（功能），以此（商业价值）”

7. 只为一个用户编写

• 当故事只为一个用户编写时，其可读性通常是最强的。
• 一般来说，从单个用户角度出发的故事，这类问题会变得更加清晰。
  1. 求职者可以从网站上删除简历—>>可以解释为
     i. 删除自己的简历
     ii. 删除别人的简历

8. 以主动语态编写

• 主动语态更容易理解，不要写成例如“简历可以被求职者发布”。

9. 不要对故事卡进行编号

• 如有必要可以加上一个标题。

10. 不要忘记意图

• 故事卡片主要目的是用来提醒开发人员和客户团队讨论的。因此要保持卡片的简洁性。仅仅加入需要的细节。

---

Finish

下一篇 “估算用户故事”

参考书籍《用户故事与敏捷方法》