经过前面10章内容的描述，我们了解故事、故事卡片，以用户故事推动的项目开发流程。实际开发中，团队往往会先得到巨大的故事（需求）。从产品角度，拆分意味着放弃部分功能，这种放弃引起的损失，会带来更痛苦的感受，难以抉择。从开发角度，拆分是建立在功能低耦合前提下，而这一点，又是基于程序早期合理的架构。但现实却是，研发过程中为了进度而采用速效方法（不会做太多长远考虑，这也是技术债产生的原因），长期的合理性变得不那么重要。基于以上种种，拆分过程就变得十分痛苦和坚辛。
然而，为了及时评估产品和进度，同时满足资源与时间限制、降低成本和实现商业目标的要求，故事拆分都是不二之选。
一、由谁来拆
最近在网上常常见看到嘲讽甲方的段子，怎么会有那么多乙方公司？后来仔细一看，发现很多发段子的“乙方”,和他们嘲讽的甲方都在同一家公司。而这其实就是工作中常会出现的“甲方-乙方反模式”。
甲方-乙方反模式
这一反模式的表现是，团队成员之间是”食客-服务员关系“，即我想要什么，你就要给什么。具体为甲方清楚自己想要什么，并表达给乙方，乙方则倾听理解，并找到解决问题的技术方法。然而，乙方承诺的排期会受各种原因的影响，若不能按时完成，乙方可以找各种理由为延期辩解。而甲方最终拿到功能后，也有可能发现不是自己想要的。最终，围绕解决问题的对话，变成了围绕需求的扯皮，最坏的情况是没有人成为赢家。在这场对话中，真正的核心其实是甲方需要清楚自己遇到的问题，而不是预测什么方法最合适。很显然，这种问题的一方面原因是故事（需求）的解决方案是由单一方决策。那么由多方共同决策是否就可以解决这一问题呢？
一人决策与多人决策方式
在大多数场景下，需求都是由单一方来负责并决策的。而团队成员常常表现为“你来决定，告诉我就好了”、“你要达到的效果是什么？”，对于单一方决策而言，这一场景实在太爽——指挥千军万马，指哪儿打哪儿的快感油然而生。等等，这里是不是存在什么问题？指挥固然爽，然而一旦出问题，那么团队成员也会说“这个是你定的”、“我只是照着你说的做而已”。正所谓成也萧何，败也萧何。让我们来分析一下：
- 用户故事由模糊到具体的过程中，需要展开多次对话，一个人是无法完成的；
- 在流程中的各个环节由各人负责，那么各人也将成为卡住流程的瓶颈；
- 一个人的知识、视野和专业范围是有限的。
既然单一方决策会成为瓶颈，那么多方决策是否会更好？也不尽然，一方面，当资源有限时，参与决策者会倾向于妥协，每个人都无法达成目的；另一方面，当资源无限时，大家倾向于做所有的事情。想想我们开会的时候，没有一个人做最终决策的情况。
探索团队
《用户故事地图》提供了另外一种决策方式——由跨部门、小型团队协作的方式进行，如题，它就是称之为“探索团队”的决策组织。在这个组织中，共有2〜4个人，包括产品负责人、用户体验设计师（设计师）、资深技术人员，所有参与人员必须具有一流的沟通和协作能力。
这个团队应该由一个对业务愿景、战略以及产品服务的市场有深度理解的产品负责人主导。这个核心团队应该有这样的人，他理解用户，可以自如地和用户合作，力求了解他们的工作方式，并且可以开发简单的UI原型。这个团队也应该包括一个来自开发团队的资深工程师。这个人需要理解系统目前的架构，知道哪些新的技术方案可以用来解决目前的难题。
探索团队应从探索阶段就开始介入，终止于“故事工作坊”以完成最后一次讨论。在故事工作坊中，除了探索团队成员之外，还要纳入测试人员等，共同定义最佳的开发和测试用时。探索团队通过用户故事的一系列方式，抽丝剥茧般梳理和评定用户故事，将故事拆分为大小合适的模块。这些模块，将最终流入开发流程中。
二、故事（需求）拆分
探索团队负责拆分故事，比较合适的模块大小是“每个模块开发与测试时间共计1〜3天”。如何做到呢？《用户故事地图》并没有提供具体的执行方法，但有一些思路值得借鉴。打个比方，如果把软件比做大蛋糕，那么切分的结果应该是怎样的？应该是很多纸杯蛋糕（一定有人想到刀子把蛋糕切成一块一块）。每一个纸杯蛋糕可以独立交付，食谱也都类似，都是一点糖、一点面粉、一两个鸡蛋什么的。
那些需要被拆分的故事被称之为“史诗故事”，我们会从三个角度来对它们进行切分：
- 用户角度：可以满足某一需要；
- 开发角度：只需要几天时间就可以完成开发和测试；
- 业务角度：有助于实现业务目标；
此外，还需结合在《用户故事地图（9）：开发流程之“研发-评估-交付”阶段》中讲到的研发的三个阶段。对故事（需求）进行拆分，它有些像碎石的过程，无论是怎样的石头，碎石的结果是得到一堆同样的小石头——这明显是一个技术活儿。
三、故事（需求）聚合
有时候，我们的需求池中会充拆大量的小需求，它们细碎而不值得大动干戈，但堆积太多又不知如何处理。此时，我们需要拿起另外一把工具，就是“聚合”——可以将那些细碎的小故事聚合为“主题”。
“主题”用以归类故事——收集需要下个版本发布、同一功能的不同版块、以某种其他方式关联的一堆故事。内容不多时候，我会直接根据需要将一堆小故事聚合在一个卡片中。当然，当这种故事很多时候，也可以采用以下方法：
- 有便签写下所有需求；
- 邀请理解系统的项目成员；
- 寻找一面墙；
- 给每个人分一些故事卡片；
- 大家凭土目水之，把相似的卡片放在一起；
- 过程中，大家安静的做，不要交流；
- 最后沟通不同分类观点的卡片；
- 每每一组一个相对具体的大标题，凝练故事；
以上方式是《用户故事地图》中介绍的方法，看来就是用研中“卡片分类法”的方式。
——end——
全部内容链接：
用户故事地图（1）：体验用户故事
用户故事地图（2）：作用
用户故事地图（3）：故事与卡片
用户故事地图（4）：创建方法
用户故事地图（5）：开发流程之“机会”阶段
用户故事地图（6）：开发流程之“探索”阶段
用户故事地图（7）：开发流程之“设计”阶段
用户故事地图（8）：开发流程之“故事工作坊”阶段
用户故事地图（9）：开发流程之“研发-评估-交付”阶段
用户故事地图（10）：开发流程之“回顾”阶段
用户故事地图（11）：故事（需求）拆分
用户故事地图（12）：后记
