一、什么是用户故事？
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
二、Ron Jeffries的3个C
关于用户故事，Ron Jeffries用3个C来描述它：
卡片（Card） – 用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的交流沟通。
确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
三、用户故事的六个特性- INVEST
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）— 开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）— 一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
四、怎么拆分故事
当故事非常大时，我们将很难对它进行估计。如果故事预计在N次迭代后才进行，那么大的故事很正常。但如果预计在接下来的迭代中进行，那么我们就可能会对大的故事进行拆分。很大的故事基本上都能进行拆分，只要确定每个小故事都可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。
分割用户故事：
- 按照用户故事所支持数据的边界来分割大型用户故事（例如导入GBQ文件、Excel等）。
- 从主用户故事中除去对例外或错误条件的处理（相当于用户的基本路径和扩展路径），从而把一个大型用户故事变小许多。
- 按照操作边界分割，把大型用户故事分割成独立的建立、读取、更新和删除操作（例如预算二次导入，或者新增时需要向导、规则而比较复杂时也可以单独成一个故事来描述）。
- 考虑去除横切考虑（例如安全处理、日志记录、错误处理等），为用户故事建立两个版本：一个具备对横切考虑的支持，另一个不具备这种支持。
- 考虑功能性需求和非功能性需求隔离到不同的用户故事，从而分割大型用户故事（性能）。
在拆分故事时，我们有时也需要考虑组合故事的场景，如把bug列入产品backlog时，可以把多个类似的bug组合成一个故事。
五、怎么评定优先级
最简单的方法就是问问客户最希望在下一个迭代中最想看到的是哪一些功能。从考虑的因素来看，我们可以从以下4个因素来考虑：
- 获取这些功能带来的经济价值，价值越高的优先级越高。
- 开发成本带来的影响。例如可能2个月后由于使用新技术只需要2周，而现在做需要2个月，这时可以考虑把优先级放低一些。
- 获取新知识的重要性。在开发中会不断的产生一些项目和产品的新知识，及早了解和开发这些新知识可以减少不确定性，所以这类功能优先级会高些。
- 故事之间会存在依赖关系，这时候被依赖的优先级会更高，需要先完成。
- 开发这些功能所减少的风险。在开发过程中，会出现进度风险、成本风险、技术风险等，对于风险越高价值越大的我们需要首先处理，对风险高价值低的要尽量避免。
六、优秀的用户故事准则
1.试着让故事的大小能够在使用后让用户感到可以去喝杯咖啡休息一下；
2.不要让故事过早涉及用户界面；
3.实际编写故事时，要包括用户角色；
4.用主动语态编写故事；
5.为单个用户编写故事；
6.让客户编写故事，而不是开发人员；
7.用户故事要简短，它们只是提醒开发人员和客户进行对话；
8.不要给故事卡添加编号。
七、小结
1、用户故事是描述对用户有价值的功能，用户故事应该包括角色、功能和商业价值三个要素。
2、优秀的故事应该具备六个特征：独立的、可讨论的、 对用户有价值的、可估算的、小的、可测试的
3、当故事非常大时，我们将很难对它进行估计，有必要进行故事拆分
4、故事优先级评定，最简单的方法就是问问客户最希望在下一个迭代中最想看到哪些功能。
5、故事评估一般采用故事点来进行这类初始评估，可以通过扑克牌来进行。
若有收获，就点个赞吧
0 人点赞
