User Story and Use Case
carol
23 Jul 2015
今天，我想跟大家分享一下User Story and Use Case。
#What is a User Story ？
User Story就是指使用一段简短的描述表达出用户的需求，是从用户的角度来描述用户渴望得到的功能。
一个好的用户故事包括三个要素：
- 角色：谁要使用这个功能
- 活动：需要完成什么样的功能
- 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事的六个特性- INVEST
INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable。
一个好的用户故事应该遵循INVEST原则。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖性得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
#User Story examples.
友约：作为一个“普通用户”，我想要“看看最近有什么好玩的活动”，以便于“打发打发时间，认识些新朋友”。
Gogograd:作为一个“学生”，我想要“找个私人家教远程辅导我”，以便于“我提高成绩”。
#What is a use case？
Use Case就是对系统功能的描述，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。每个Use Case提供了一个或者多个场景，该场景说明了系统是如何和最终用户或其他系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。Use Case一般是由软件开发者和最终用户共同创作的。
#Use Case examples.
case 1 微信发朋友圈:
- 进入朋友圈
- 点击右上角图标进入相册挑选照片
- 确认照片
- 编辑内容
- 发送
case 2 微信添加好友：
- 去到通讯录页面
- 选择添加朋友
- 输入微信号/QQ号/手机号
- 在搜索结果页面找到好友并添加
- 发送验证
- 好友同意
- 添加好友成功，返回主页
#What is the difference between “User Story” and “Use Case” ?
从层面上，User Story更偏向于用户能理解或者看懂的内容。User Story是能够产生核心的业务价值的单位。User Story能达到这目的，但是Use Case就不一定了。
从详细程度看，User Story偏用户需求或业务场景，重点把业务需求和场景说清楚即可，比较简单。而Use Case比较复杂，涉及业务流程，业务规则，输入，输出，界面，交互等各个方面的内容。
#When to use “User Story” ？
User Story适合早期的探索需求阶段，因为它表述起来非常简单，一个User Story只需要几句话就可以完成，另外一个因素就是，用户需求的细节是会经常变的，而其高层描述却是相当稳定的，所以我们可以通过User Story来从高层描述中确定他的需求，这些单独的User Story相当于系统中可能要实现的一点，而由我们通过与用户交流所得到的所有 User Story 则构成了一个面，它就是整个系统所需要实现的功能，举个例子， “作为用户，我希望能够查看订单列表”，非常简洁，但是阐述清楚了谁需要什么的需求。
#When to use “Use Case”？
Use Case更适合于需求分析阶段，因为该阶段需要比较详细的、更系统的需求分析，而Use Case能够满足这一切，不过，由于这里需求进行了具体化处理，因此用户可能在变换交互方式的时候，对于User Story来讲不会变的东西，而对于Use Case来讲可能就会有所有变更。
#Can we use “User Story” and “Use Case” at the same time？
有人认为，不应该同时使用User Story和Use Case。
因为Use Case相当详细，并且它所描述功能的流程或者步骤是可以改动的，制作Use Case的过程中，你需要做的准备非常多，首先你要非常了解整个业务的规则，并分析当用户使用这个功能的时候会遇到的多种情况，正确的或者错误的，以及，当规则发生改变的时候，你又要重新编写，所以，在编写Use Case上会花费相当多的时间和精力，而这一行为与敏捷开发的理论是相悖的，所以有的人不赞同在敏捷开发中同时使用User Story和Use Case。我觉得不赞同的人大概是因为觉得Use Case花费的时间成本比较高。
但是，也有的人认为，可以同时使用User Story和Use Case。
因为两者使用情况和目的都不同，应该根据当前的情况来判断是否合适，这包括项目上的需要，也包括团队的能力。
最后，总结以上两个观点，我自己更偏向于同时使用，首先，User Story在敏捷开发中是必要的，它在项目开发前期需求不是非常精细的情况下，对于解决如何安排开发人员的工作是非常有效的。而Use Case呢，在项目开发阶段，可以让开发人员对于功能细节方面有更多的思考，以及对流程步骤更加了解，因为有时候开发人员各自做各自的任务时，对于整个系统的所有功能有时并不是很清楚，而集合所有的use case能帮助开发人员了解所有的规则。在测试方面，User Story可以作为集成测试的测试文档，而Use Case就是其中的具体步骤。
合适当前场景的选择才是最好的选择，不要拘泥于这其中的死条款不放才能取得最好的效果。
参考文档：
http://www.zhihu.com/question/19597971
http://txf2004.iteye.com/blog/607251
http://www.infoq.com/cn/news/2008/08/use-case-or-user-story
http://www.baike.com/wiki/Use+Case
http://www.batimes.com/articles/user-stories-and-use-cases-dont-use-both.html