本指南内容
为什么故事拆分很重要
什么样的用户故事才算是恰当的故事？
用户故事格式
恰当的故事应遵循INVEST原则
用户故事是垂直切片
故事拆分流程图
步骤：准备好要拆分的故事/特性
步骤2：套用拆分模式
步骤3：评估拆分效果
Cynfin和故事拆分
练习故事拆分
垂直切片和规模化
是否应该让00+的人去开发一个产品？
规模化垂直切片的基线
为什么故事拆分很重要
从优先级最高的、工作量较小的用户故事开始开发，可以让产品团队持续输出高价值的产物，并获得高质量的反馈。许多团队都在努力将较大的用户故事和特性（fatur）拆分成恰当的小故事，但是他们没有从业务的垂直切片来拆分，而是从整个技术架构的的角度，拆分出了很多看起来更像研发任务（Task）或组件（Componnt）的故事，最终导致他们未能体验到小故事应有的价值或反馈。
幸运的是，故事拆分是一种可以在较短的时间内学会的技能。我们已经看到，团队仅需几个小时的练习和一些简单的工具，就可以从挣扎中解脱出来，快速地拆分故事。稍后，我们将介绍如何组织这种练习。
什么样的用户故事才算是恰当的故事？
在讨论拆分用户故事之前，我们需要确保我们对什么样的用户故事才算是恰当的故事、以及可以将哪些内容拆分为故事有一个共同的理解。
首先，让我们看下用户故事的定义：用户故事是从用户的角度描述系统行为的变化。它描述的是用户想通过系统做的事情，或者希望系统为他们做的事情，而这些事情现在的系统里还没有。
顺便说一下，请注意，用户故事位于方案域（solutionspac）而不是问题域（problmspac）。它不是一个人想在某个地方完成一个任务的描述（就像JTBD[JobtobDon，待完成的工作]一样），而是一个人想要在你的系统中完成某件事情的描述。JTBD在问题域中可以与客户产生很好的共鸣，而用户故事可以很好地将客户的共鸣转化为对软件系统的一系列改变，同时在整个交付过程中保持客户的视角。
用户故事格式
你可能经常会看到以如下特定格式书写的用户故事：
作为角色我想要功能或行动以实现价值或目标
或者有的是这样：
为了价值或目标作为角色我想要功能或行动
该模板的优点在于它要求你回答用户故事中的三个问题：
它是给谁（WHO）使用的？
他们想要做什么（WHAT），或者让系统做什么，而这些功能现在都还没有？
他们为什么（WHY）要这样做？
不过，重要的不是模板，而是回答这三个问题。
实际上，我们很少会用完整的模板来写故事。无论是在便签纸的顶部还是在在线项目管理工具的标题字段里，一个写着“WHAT”的简短标题都会是比较好的选择。“WHAT”由标题提供，而“WHO”通常由产品愿景或版本目标提供，它描述了核心目标客户。如果故事是为该目标客户准备的，我们就不重复撰写了，我们只有在为非核心目标客户撰写用户故事时，才把“WHO”加上。最后，我们将确保在在线工具的“详细描述”或类似的字段中，或者在便签纸上用较浅的字体写明“WHY”。
因此，如果我们要做一个公共图书馆的网站，并且图书馆的读者是我们的默认用户，则我们不会这样来书写用户故事：
作为图书馆的读者，我想按书名搜索一本书，以便我能在搜索结果中毫无干扰地找到我想要的书。
我们会这样来写：
按书名精确查找因为我知道我想要的具体书籍，所以我不希望在搜索结果中出现干扰
有时我们会遇到将单独的研发任务或架构组件伪装成用户故事的情况。即使你使用了诸如“作为开发人员，我想要一份数据库关系图，以便我能了解数据库的结构”这样的神奇描述，它仍然只是一个开发任务。
恰当的故事应遵循INVEST原则
几年前，极限编程先驱BillWak提出了一个很好的首字母缩略词，用来表示一个恰当的用户故事应具有的6个关键属性：INVEST。让我们来挨个看一下：
I代表INDEPENDENT（独立的）。这意味着一个恰当的故事能够足够的独立，它可以不用考虑技术依赖就可以排定优先级。有时，这意味着需要暂时提供一些Mock数据或接口，以便可以独立测试故事，让你在项目的早期就能更快地获得价值或降低风险。
N代表NEGOTIABLE（可协商的）。一个恰当的故事会为做什么、如何做等细节留下协商的空间。当然，随着协商的进行、更多细节的敲定，故事的可协商性就会降低。
V代表VALUABLE（有价值的）。每个故事都应该为用户增加一些可见的价值增量。现阶段这似乎是不可能的，因为你的ProductBacklog里可能有大量的技术组件和基础架构的任务，这些技术任务伪装成了用户故事，但这并不能直接为用户增加价值。随着你故事拆分技能的不断成长，你能更好地找到能直接提供价值的、短小的功能切片。（故事并不需要单独提供足够的价值来直接发布。你可能需要积累多个故事，才能从有价值转变为可销售。我喜欢最小可销售特性（MMF，MinimumMarktablFaturs）作为故事的容器。）
E代表ESTIMABLE（可估算的）。一个恰当的故事应该定义到足以让团队能够估算它的工作量，这个工作量一般是相对于一个基准故事所做的相对估算。
S代表SMALL（短小的）。经验告诉我们，对于一个已排序的ProductBacklog，你应该能够将优先级最高的6到0个故事排入下一个Sprint中。这样做既能经常获得反馈和管理风险，同时也不需要管理太多的故事。不过这个故事数量只是一个建议，它会随着Sprint长度、团队规模、团队速率等因素按比例缩放。
T代表TESTABLE（可测试的）。我们应该有办法知道我们已经完成了某个故事。它不能只是一个模糊的期望，而需要是系统行为的具体变化。
当然，这些属性之间存在着一定的互斥关系。比如说，随着故事的规模变小，使其变得独立且有价值的难度就会变大；随着故事的可协商性变大，其可估算和可测试的难度就会变大。
不过幸运的是，不同的属性在不同的时间起主要作用。例如在进入Sprint计划后，更重要的是故事要短小、可估算和可测试。这时我们仍然需要故事有一定的独立性、可协商性和有价值，但这些属性这时已经变得不那么重要了。而在ProductBacklog中的故事，情况恰恰相反。
用户故事是垂直切片
在提到恰当的故事时，你经常会听到垂直切片（vrticalslic）这个词。这是恰当的故事在软件架构方面的要求。
垂直切片是指“一个能给系统行为带来变化的有价值的工作项，它可能要触及多个架构层级（architcturallayrs）来实现这个变化”。当你把这个切片（slic）称为“完成”时，该系统对于用户而言显然更有价值。
水平切片（horizontalslic）与垂直切片刚好相反，它是指“对一个组件（
