用户故事——敏捷开发的代言人，以其灵活、快迭代而闻名IT界。俗话说，你写一篇需求文档的时间，我能写20个用户故事。
目录：
1、用户故事是什么？
2、用户故事和用例的对比
3、个人心得体会
一、用户故事是什么？
1. 用户故事（User Story）：一种敏捷开发常用的需求捕获手段，描述对系统用户或客户有价值的功能。PS：只是需求描述，而不是详细的需求规范。
2. 3C原则：
卡片（Card） – 用户故事一般写在小的卡片上。卡片正面写上故事的简短描述，格式为：作为一个<角色>, 我想要<活动>, 以便于<商业价值>。卡片背面写测试点，可随时补充。
交谈（Conversation）- 用户故事背后的细节来源于和客户或者产品负责人的频繁的交流沟通。
确认（Confirmation）- 通过验收测试确认用户故事被正确完成。
可能是在这样的卡片上写下用户故事
写完故事贴到墙上，确保所有人都能时刻查阅
3. Invest原则：
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事，可以独立被开发、验收、测试。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。
这里我踩过一个坑，今年8月时我接了一个需求。因我将拆解时拆得太细了，导致后续的开发互相挚肘，不能独立完成开发、和验收测试。开发、BA、测试都觉苦不堪言。但当时拆完后，没有人有异议，可见大家并未对独立性引起重视。
比如以下两个小issue：
1. 配置表增加【入仓属性】字段，用户可以在配置表维护【入仓属性】值。
2. 执行完成单据的操作后，单据上的【入仓属性】自动赋值。
issue2依赖issue1的开发，若issue1未开发好会影响issue2入场。这时我应该在卡片背面将其合并为一个用户故事：
作为一个仓库作业员，“我”想要在完成单据时让系统告诉我这个物料进哪个仓库，这样我可以把物料入到正确的仓库里。在卡片背面写上测试条件：可以配置仓库值。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
我理解，如果在整个流程中始终采用用户故事，则用户故事永远可协商，甚至直到功能上线、卡片被弃。但若已产出用例或需求文档准备交付给开发时，请BA让stakeholder对文档进行评审，让其确认和sign off。（下文会详细讲）
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
就我所呆过3个项目组经历而言，让客户写价值比较难但也不是无法实现。在用户和IT团队的合作模式已磨合得较成熟的团队里，用户对软件和业务的熟悉程度较高，给出价值的可能性高。反之，则需要BA去沟通、总结这个故事的价值。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的
二、用户故事和用例的区别：
目的不同：
用户故事适合探索需求。用例适合交付给开发和测试人员，且作为备案。
范围不同：
用户故事更轻量级、概括化、更随意，用例更详细、更正式。
创造方式不同：
用户故事是由客户团队、开发坐一起写在卡片上头脑风暴出来的。用例主要是BA书写的。
寿命不同：
用户故事在功能上线后就被丢掉，而用例会作为书面文档保存。
用户故事的优势和劣势：
优势：早期捕获需求时，更灵活、更节约需求分析时间（最主要）
劣势：没有上下文关系，是一个个的需求点，无法连成面（但用户故事地图一定程度上可以缓解）
适合用户故事的：
从0到1搭建起来的有现场客户支持的新系统、快速迭代的互联网公司。对敏捷和用户故事认同、用户较配合的理想的团队。
适合用例/ 需求文档的：传统瀑布式开发的团队、运行多年（没有现场支持客户）的大系统。
三、个人体会
一点小心得：
用户故事更多从用户角度出发，而用例更多是从软件开发的角度撰写，各有侧重。
在需求探索阶段，以用户故事捕获整理需求。需求确认较明确后，以需求文档内嵌用例的方式发给stakeholder做评审。
等所有stakeholder都确认后让其sign off（签名确认，虽然较难实现），理论上此时这份文档就该停止更新了。如果以后再发现需要改动的地方，就应该出一个change request，然后改动后再让所有的stakeholder去sign off，全部sign off之后再一次baseline。
早期，我无法区分用户故事、用例、场景、需求文档的区别，统一以需求文档概括它们。而在不断的学习和实践当中，我认识到他们是不同的。孰优孰劣并无定论，使用哪种技术也得看你所在的团队的具体情景而定。
只有反复的学习、实践、总结，方能化纸上方法论为心经吧。
推荐阅读：《用户故事与敏捷方法》https://book.douban.com/subject/4743056/
关于用例及更多的需求分析技术，请在后台回复“用例”获取精华文章。
