什么是User Story其实我觉得要对User Story做一个定义还是挺难的。
曾经的我以为，所谓User Story是User来讲述的Story。
你看啊，User Story的编写范式：
As a role, I want to do something or a piece of functionality, so that I can achieve some business value or statement of intent.
但是，随着真正的实践，我发现，User总是一个缺席的定义者。
我们指望User来定义User Story，而大部分情况下是由我们这群BA来定义的。
我曾经和一名敏捷教练讨论，我们BA总是在臆想用户的需要而写User Story，这样有意义吗？
这名来自美国的副总裁回答我说，至少你们从用户的角度来思考了，不是吗？
不过，并没有解答我的疑问，我也相信有很多人和我有同样的问题：User Story到底是从哪里来的？谁来写？
也有很多人认为需求提出方应该来写User Story，至少也应该来确认User Story是否恰当。
但实际情况是，很多时候我们真的只能靠想象，充分利用我们的“同理心”来想象。
我翻了一下BABOK中对于User Story的定义：
A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
——《BABOK 3.0》
这样看来，User Story只是用来描述可以带给User的价值的功能或质量需求，而非必须由User提供。
后面这段描述更加明确的指出了这点：
With a focus on stakeholder value, user stories invite exploration of the requirements by promoting additional conversations with stakeholders and grouping functional requirements for delivery.
——《BABOK 3.0》
这里，我们暂停一下，敲个黑板：价值。
User Story是强调给用户带来价值的。
OK，我们继续。
广为人知的拆分原则User Story写起来并不复杂，但是从敏捷的小步快走的角度出发，大部分的User Story是需要进行拆分的。
而各种敏捷著作中都有写明 User Story拆分的INVEST原则：
Independent：独立性User Story必须高内聚，也就是拥有独立性，不依赖于其他User Story的实现而实现。
如果你将一个User Story拆成前台和后台，那肯定不符合这个原则，因为这两个Story的依赖性非常高。
Negotiable：可协商User Story并不应该是一个人的一言堂。
之前有个小伙伴问我，是不是应该由BA来写User Story。我说，BA提供的是初稿，最终稿需要让团队所有相关人员达成一致。
Valuable：有价值再次敲黑板，价值！
价值是User Story的关键所在，这个Story如果对用户是没有价值的，那就需要重新拆分或者重写。
Estimable：可评估在之前的Scrum文中，其实我提到了关于User Story的Point评估问题。
我们必须保证User Story的可评估，因为User Story是所有实现的基础，我们需要根据评估的结果进行计划、追踪和回顾。
Small：足够小这个原则也决定了User Story要拆得足够小，至于要拆多小，这个我个人觉得应该由团队协商一致，至少也应该是在一个Sprint可以完成的程度。
我在之前的团队里，当评估的点数大于3的时候，我们就一定要拆。
因为根据我们以往的经验，5点及以上的User Story会导致我们的Sprint失败，非常可能做不完或者测不完。
而拆分的过程也是一个再次思考和讨论的过程，大家很有可能会发现之前被隐藏和遗漏的地方。
Testable：可测试为用户带来价值的User Story必须是可以测试的。
请反复读一下我上面这句话。
之所以称以上原则为“广为人知”是因为大家都知道拆User Story的时候要遵循这些原则，但是依旧不知道要怎么拆。
怎么拆都怪怪的？还记得我上面敲黑板的两个字吗？
价值
所有User Story的拆分都要以价值为导向，在拆完后也需要通过“这个小的User Story有给用户带来业务价值吗？”来校验是否拆的合适。
这么说可能有点抽象。我来举个例子。
有这么个图书馆借阅系统的User Story：作为一个用户，我希望可以找到满足条件的书籍信息，以便我可以在书架上找到它。
这个User Story有点大，好吧，不是有点大，是非常大。
如果你拿这个User Story去和大家讨论，会面临以下问题的解答：
?这个用户是注册用户，还是访问用户？
?不同类型的用户操作是一样的吗？
?所谓的“满足条件”指的是哪些条件？书名？作者？ISBN……
?要展示的书籍信息包括什么？书名？索书号？馆藏状态？
……
于是大家讨论了下，决定要拆。那这个User Story给你，你怎么拆呢？
以下是一种拆法，拆成两个User Story：
第一个：建立图书信息表，里面包括书籍的各种属性。
第二个：按照原型，画三个前台界面，包括：搜索界面和搜索结果界面，以及图书信息展示界面。
还嫌大？
那我就把第二个拆成三个，每个界面一个User Story，够小了吧？
有没有觉得哪里不对劲？
有人说，因为没有按照User Story的格式来写，没有写：作为一个用户，我希望可以查看搜索界面，这样我就可以开始准备搜索了。
更奇怪了，是吧？
来，想一下，这些被拆出来的Story对用户来说有业务价值吗？
你提供一个前台页面给用户，不能搜索，只能看，是准备打印出来挂到美术馆里面“供人瞻仰”去吗？
那么应该怎么拆呢？
我这里提供一个思路，大家可以揣摩一下。
大的User Story：
作为一个用户，我希望可以找到满足条件的书籍信息，以便我可以在书架上找到它。
第一个 User Story：
作为一个用户，我希望可以通过图书名称找到图书的书名、作者、馆藏状态以及索书号信息，以便我可以在书架上找到它。
第二个 User Story：
作为一个用户，我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息，以便我可以在书架上找到它。
或者这么拆：
大的User Story：
作为一个用户，我希望可以找到满足条件的书籍信息，以便我可以在书架上找到它。
第一个 User Story：
作为一个用户，我希望可以通过图书名称找到图书的书名以及索书号信息，以便我可以在书架上找到它。
第二个 User Story：
作为一个用户，我希望可以通过图书作者找到图书的书名、作者、馆藏状态以及索书号信息，以便我可以在书架上找到它。
有感觉到什么吗？
嗯，这样就万事大吉了嘛？
我只能说，图样图森破……
因为这里还有一个延伸的问题，就是程序猿GG看到这样的User Story拆分，很想打人。
为什么？
因为在代码实现的时候，其实在做第一个User Story的时候，可以“顺手”把第二个User Story的逻辑实现了。
而如果不顺手实现，那么意味着在做第二个User Story的时候会需要改才交付完成的第一个User Story的代码。
就好像我们装修房子。
之前的拆分方法是：水电进场开工、瓦工进场开工、木工进场开工、漆工进场开工、家具及软装进场。
而我后面的两种拆分方法是：先把客厅的水电、地砖、墙面、家具软装都搞定后，再来依照这个顺序搞一遍卫生间，再搞一遍卧室……
但是，看出差别了嘛？
前面的拆分方法一个工种干完，下一个接着干，只有当所有的都干完了，房子才能交付。
而后面的拆分方法至少保证第一个User Story可以交付一个完整的客厅给用户，这对用户来说是有价值的。
这也是敏捷的奥义所在。
但是，工人们肯定不乐意了，我水管先铺一段到客厅的，后面我还要把铺到客厅的一部分拆了再铺到卫生间去……
哈，也从另外一面说明了敏捷方法明显不适合工程装修。
那么你要怎么说服大家接受User Story的价值导向的拆分方式呢？
关键在于，敏捷的另外一项重要工作：重构。敏捷的开发过程其实很强调重构、自动构建等等。所以，这也是为什么我一直觉得敏捷的框架和流程是一个完整的体系。你不能抛开重构谈User Story拆分，你也不能无视价值来写User Story。
我大概花了两三年的时间才摸索出来写和拆User Story的感觉，当然这和业务熟悉程度也有一定的关系。
我想要说的是，想要拆好User Story是需要自己不断的去摸索的过程，没有办法说我今天看了一篇文章或者听了一堂课，我就能把User Story写好、拆好了。
重点是要亲自动手去拆，去写，去试错。
说了这么多，你在拆User Story的时候遇到了什么问题？
这篇文可以解答你的问题吗？