User story，即用户故事，是敏捷的基础工具，用于描述用户的需求。那么疑问就来了，和我们日常的需求规格有什么区别呢？先占时抛开这个问题，先聊聊User story来历。
User story是Kent Beck的创意。大约在20世纪19年代末的时候，Kent发现软我们是通过文档来精确描述想要的东西。但是同一份文档，阅读的人不同，各自得到的信息也不一样。最后开发出来的东西大相径庭，才发现大家理解不一致。这时候抱怨声四起，DEV抱怨BA需求描述不清，BA抱怨业务对描述内容有缺失。但是我们依然立志写一份完美的文档，甚至是让大家在文档上签字以确保达成共识。Kent想摒弃“写出完美文档”的执念，希望大家坐在一起，通过讲故事的方式把需求呈现出来。User story因此得名。
US是想让需要解决问题的人和有能力解决问题的人，坐在一起，描述为什么要这么做，而不是传统需求文档一样只是体现了怎么做。通过彼此协作，统一语言，达成共识。
1.User Story三大要素
理解US之后，不得不提US的三大要素。
Card：在一堆卡片上写下期望的软件特性。US需求的载体，不是需求本身。敏捷宣言里也强调“可工作的软件胜于详细的文档”，记录关键要素支撑交付，切勿为了文档而写文档。Card体现了核心、简单、小。
Conversation：聚在一起对要开发的软件进行深入讨论。强调与用户沟通，确保理解一致，从而进一步探索需求细节。
Confirmation：对完工条件进行确认。即验收条件，再次确认信息传递的准确性，确认US是否实现，以及是否达到预期。
2.User story基本拆分原则
US是基于用户视角的需求描述，如果按照前台、中台、后台、数据库等维度平行切分，交付结果对用户来说没有价值，所以拆分US原则上要求端到端，有点类似竖着切蛋糕的方式，从奶油、面包、水果一起切分，而不是奶油一层、面包一层、水果一层。
拆分Story有6大原则：
Valusble：US是用户的故事，体现用户所需，对用户有价值，而不是开发团队的价值。
Negotiable：US是逐步清晰和细化的，其工具就是不断的沟通和协商。
Independent：保持US间相互独立的，便于US的排序、工作量评估和测试。
Testable：可测能让我们验证US是否完成。
Estimable：US可评估，说明了US足够清晰，达到可以开发的条件。
Small：US需确保在迭代中完成，不能太大，当然US拆分越细，需求会越清晰，而成本也会越高，团队平衡即可。
以上的Invest原则只是经验建议，实际拆分还需要按照产品情况进行，有些时候代码重构、架构优化、性能需求等也可以作为US的。
3.User story拆分方法
以下是大家伙经验总结的方法，不是唯一标准，也不是一种方法就可以hold所有情况，基本是多种方法的结合。
简单说明下以上9种方法：
工作流：每个工作节点相对独立，可以按照工作流切分，再从工作节点再深入打开。
主要/简单：先把主要部分中的简单内容进行拆分
数据输入：以数据类型进行拆分
数据处理：以数据处理模式进行拆分
主要/次要：按照需求的主要／次要的层次进行拆分
MVP：最小产品试验的理念进行拆分，最小化US数量和大小
性能：比如在功能实现和性能要求上，拆分为两个US，先实现功能，再实现性能提升。
CURD：增删改查
Spike：探针模式，这是找不到办法中的办法，先拆分试试。
4.User story书写模板
US是需求载体，强调用户和Team共同完成的，大家所想的一样。模板核心回答了“谁”、“什么”、“为什么”的问题，强调了用户想要的部分。当然该模板也只是参考，我们是可以适当增删。
但是，User story的创意初心是大家一起来讲一个好故事，共同一致理解US，强调的是团队间的协作和共识。如果仅是为了US而写US，这和传统的需求文档没差。
