商业分析BA:用户故事怎么拆？

什么是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的时候遇到了什么问题？
这篇文能够解答你的问题吗？