用户故事与敏捷方法笔记---编写故事

提示：如有问题或错误请留言

---

前言

前面提到了故事，那么什么是故事，又该如何使用和编写呢？编写故事又该注意哪些问题呢？这篇笔记将记录这些要点。

---

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

文章概览

1. 一个优秀的故事

应该包含以下特点（《探索极限编程》和《重构手册》的作者Bill Wake，建议用INVEST 来代表这六个特征）

• 独立的
• 可讨论的
• 对用户或客户有价值的
• 可估计的
• 小的
• 可测试的

2. 独立的

• 我们应该避免故事之间相互依赖，例如一个高优先级的故事依赖一个低优先级故事，那么在优先级排列顺序时候就会出现问题。

   	1) 公司可以用Visa 信用卡对发布职位进行付费。
   	2) 公司可以用万事达信用卡对发布职位进行付款。
   	3) 公司可以用美国运通卡对发布职位付款。
   	4) 假设工程师估计支持第一种信用卡需要三天，其余的各一天，这时候你就不知道该选哪个是第一个。
  

• 出现上述情况，有两种办法绕过去。

   	i. 将相互依赖的故事合并成一个大的，独立的故事。
   		1) 上述1-3的小故事可以合成：公司可以用信用卡对发布职位进行付款。
   	ii. 用一个不同的方式去分割故事。
   		1) 用户可以用一种信用卡支付
   		2) 用户可以用另外两种信用卡支付
  

3. 可讨论的

	a. 故事应该是可以讨论的，可以修改的，因为它不是签署签署好的合同或者软件必须要实现的功能。
	b. 故事卡的作用是提醒客户团队和开发团队在以后要进行关于需求的对话，所以它并不是需求本身。
	c. 如果我们把故事卡用于提醒开发人员和客户进行需求的讨论，那么故事卡应该包含下面的信息：
		i. 一两句短语，用来提醒开发人员的客户进行对话。
		ii. 一些注释，用以表明在对话中亟待解决的问题。

4. 对用户或客户有价值的

	a. 首先明白一件事，客户（软件的购买者）和用户（软件的使用者）是不同的群体。
	b. 两个避免
		i. 避免那些只对开发人员有价值的故事
		ii. 避免在故事中出现用户界面和技术方面的定义。
	c. 如果可以的话，最好让客户来编写故事。

5. 可估计的

	a. 对于开发人员来说，估算故事用代码实现的时间是很重要的，一般有三种情况不可估计：
		i. 开发缺少相关领域知识
		ii. 开发缺少技术知识
		iii. 故事太大了

6. 小的故事

	a. 故事太大和太小都会对制定计划产生阻碍。
	b. 合适的故事大小最终取决于团队，它的容量及所使用的技术。

7. 分割故事

	a. 史诗故事分为以下两种
		i. 复合故事
		ii. 复杂故事
	b. 复合故事由多个小故事组成，例如：用户可以发布他的简历，在系统初始时这个故事还算恰当，但当开发人员和客户讨论时候，发布简历就可以拆分成以下几点
		i. 简历包含教育经历，工作经历，薪资历史。。。。
		ii. 用户可以将简历标识为非**状态
		iii. 用户可以修改简历
		iv. 用户可以删除简历
	c. 此外切记不可以太小
		i. 求职者可以在简历上输入每个社区服务的日期。
		ii. 求职者可以在简历上修改每个社区服务的日期。
	d. 通常分解故事按照：创建----编辑----删除这些动作分解故事。
	e. 复杂故事时很难分解的，但也有方法：分解为两个故事，一个是做调研的故事，一个是开发故事
		i. 公司可以用信用卡支付发布职位的费用分割为
			1) 调查研究网络上处理信用卡的相关技术。
			2) 用户可以用信用卡付费。

8. 合并故事

	a. 有时候故事太小，可将小故事合并成一个适合的故事，以便开发处理和估算时间。

9. 可测试的，故事必须是可测试的

	a. 这两个非功能性测试，这两个属于不可测试的所以不符合规则：
		i. 用户必须觉得软件很好用
        ii.用户不需要花费很长时间等待响应

总结

提示：如有问题请留言
下一篇 “角色建模”

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