用户故事（User story）
是指在软件开发和项目管理中用日常语言或商务用语写成的句子。User Story 是用户需求的简化表达，用一两句话表达完整的想法。User Sotry 只要求写下最有价值不能被忘记的东西，而这些内容足够帮助估算工作量以及与客户沟通。
用户故事描述了对用户、系统或软件购买者有价值的功能。一个好的用户故事包括三个要素：
1.角色：谁要使用这个功能。
2.功能：需要完成什么样的功能。
3.价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：As a <Role>, I want to <Activity>, so that <Business Value>.
中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>
举例：“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。
User Story 的好处？
User Story强调通过一个简单的情境，具体的描述出软件在「使用人」的手上，是怎样被「操作」的。这样的描述可以让开发人员尽快能的贴近使用者的真实需求，而不是做错重点。
User Sotry可以帮助与客户之间进行很好的沟通，因为是情境描述文字，客户可以很轻松的根据这些情境排定优先顺序。
通常只是口头描述，无法精准的让开发人员完成用户想要的效果，因为：
1、通常使用者和用户一般说不清楚自己真正想要的是什么
2、即使开发人员了解所有需求，也有很多细节是在开发做的过程中才知道的
3、即使一下知道所有细节，也无法一次全部理解
4、即使知道所有细节，用户需求还是会变动
User Sotry 描述了一个又一个的情景，可以帮助开发人员和沟通人员达成一致的目标。
User Story 怎么写？
作为 <xxx角色> 我想要做 <yyy 的功能>，以便<实现 zzz 的好处>
一条 User Story 只能有一个 User 角色。
独立的（Independent）— 我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.用一个不同的方式去分割故事。
可讨论的（Negotiable）— 故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
对用户或客户有价值的（Valuable）— 用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可估算的（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。
小的（Small）— 一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试的（Testable）— 故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。
总结
大家都爱听故事，就像一篇学术论文和一篇小说，想必大家都更喜欢看小说。所以现在才有越来越多的作者将专业文章写得通俗易懂，各种举例讲故事。
以上只是说了两大方面，其实在项目验收，场景测试时，都可以“讲故事”，如果连我的故事线都走不通，还有必要进行功能测试吗？还有给客户演示，别以为做几张很炫酷的PPT，然后截几张产品图片就很OK了，其实这样客户往往不会买单的。还是要说故事，模拟场景，使用不同角色账号登录系统，说一个完美而顺畅的故事，继而打动用户。
参考：转
/p/7fb8104c5cec?from=groupmessage
/jetlian/p/3576170.html
/pmd/879818.html
