Bruce有话说
很喜欢Humanizing Work公司网站上关于用户故事拆分的文章。周末的时间通读了一下。把有感觉的部分分享给大家。
本文中的故事拆分流程全景图最早是在Bob(姜信宝)老师的CSM课程的时候第一次看到。印象深刻。后来发现原始出处是在Humanizing Work公司网站上，本文翻译了全景图的配套说明文字，可以帮助大家更好的理解和使用这个全景图。
正文
为了支持我们指导的团队，Richard创建了一个故事拆分全流程图，我们在帮助团队分割故事时要问下面的问题。(请参考最下方的全景图)
步骤 1:准备好带切分的故事(或特性)
首先要确保你想要分割的故事(或功能)满足INVEST标准(而不只是体量小)。通常，有价值的是问题。当人们给我们带来“不可分割”的故事时，它们变成了伪装成故事的任务或组件。如果你从一个不是价值递增的东西开始，就没有办法把它分割得更小，然后得到增量的价值。在这种情况下，下一步是考虑将当前的非故事的故事与其他故事结合起来成为一个新的故事，这样它就有可能成为有价值故事。
接下来，是否当前的故事切片太大了？如果是，那么是时候切分他了。
步骤 2: 应用切分模式
模式 1: 工作流步骤
这是一个来自我们的客户创建的内容管理系统的故事:
作为一名内容经理，我可以在公司网站上发布一篇新闻。
这听起来并不太大，直到我们深入挖掘发布这个用户故事的工作流程。事实证明，仅仅是想要在公司网站上看到几句话的新闻报道这个用户故事，就需要编辑和法务的审批，以及在staging网站上的最终审查。不太可能在一次迭代中做6-10个这样的故事。
在这样的工作流中，最大的价值往往来自于开始和结束。中间的步骤会增加价值，但并不能独立存在。因此，先实现简单的端到端用例，然后再加入中间步骤和特殊案例，可以很好地解决这一问题。
新的用户故事包括如下内容:
…我可以直接在公司网站上发布新闻。
…我可以发表一篇由编辑审查后的新闻。
…我可以发表一篇经过法务审批后的新闻报道。
…我能够在staging站点上看到新闻故事。
…我能够将一个staging站点上的新闻故事发布到生产环境。
不过，有时候，整个工作流程都很重要，因此你不能只是掐头去尾来做。在这种情况下，请在整个工作流程中寻找一个涉及面最窄的业务部分。 也许它支持最常见的情况。 也许你对工作流程中最易理解的部分进行了硬编码或简化，以便你可以在以后探索更复杂的部分。
不管怎样，用“从头到尾一步一步地走”这样最显而易见的，按照步骤切分方式拆分是一种错误的方向。
模式 2: 操作 (例如：增删改查)
用户故事描述中的“管理”一词表明该描述包含多个操作。这提供了一种自然的方式来分割故事。例如:
作为一个用户，我能够管理我的账户。
变成
…我可以注册一个账户。
…我可以编辑我的账户设置。
…我可以注销我的账户。
模式 3: 不同的业务规则
这个故事中隐藏了一些同样复杂的故事，它们使用不同的业务规则完成相同的事情：
作为用户，我可以通过设定灵活的日期来搜索合适的航班信息。
深入研究“灵活的日期”可以发现几个不同的业务规则，每一个都可以是一个很好的故事:
…可以选择从第X到第Y天之间。
…可以选择12月的某个周末。
…可以选择从X天加减N天。
模式 4: 数据类型不同
故事中的复杂性可能来自处理数据的变化。例如，我们目前正在研究一种需要对运输提供商所服务的地理区域进行建模的系统。他可能复杂到我们只处理地理问题，就把整个项目预算都用尽。当我们讲这个故事的时候，
作为用户，我可以通过旅行出发地和目的地搜索运输供应商。
与产品负责人一起，我们发现，虽然我们不需要完整的GIS系统，但是地理建模仍然非常复杂。 我们停下脚步并且问客户：是否我们来决定“对地理模型进行建模的’足够好’的方法是什么，以便我们现在可以构建其他高价值功能？”
作为用户，我可以按旅行出发地和目的地(国家)搜索运输供应商。
这种做法在一段时间内是有效的，直到我们收集了更多的数据，发现一些供应商只服务于某些城市甚至社区。于是，一个新的故事出现了:
作为用户，我可以根据旅行出发地和目的地(县、市、镇或社区)搜索交通供应商。
查看新的供应商数据时，我们还发现，有些供应商支持从单个城市出发，但以任意数量的周边城市为终点的旅行。这就引出了一个故事:
供应商可以为旅行出发地和目的地服务不同的地理区域。
这三个故事都是从最初的地理故事中分离出来的。这里的不同之处在于，我们在构建最简单版本之后及时添加了故事。
但有时你事先就知道数据的变化。经典的例子是本地化:
作为一个网站管理员，我能够创建新闻故事。
…用英语。
…用日语。
…用阿拉伯语。
…等等。
模式 5: 不同界面
有时复杂性在于用户界面而不是功能本身。在这种情况下，将故事切分开来，用最简单的UI构建故事，然后再构建更可用或更漂亮的UI。当然，这些并不能孤立来看：如果你先做了一个故事，但是第二个故事实际上才是符合最初的需求。这种情况也是一个有用的切分。
作为一个用户，我可以在两个目的地之间选择航班。
可以切分成
…使用简单的日期输入。
…用一个花哨的日历UI。
模式 6: 主要工作
有时候，一个故事可以分为几个部分，大部分的工作量都是为了实现第一个部分。例如，这个信用卡处理的故事，
作为用户，我可以用VISA、万事达卡、大来卡或美国运通卡支付机票费用。
可以分为四个故事，每种卡片类型一个。 但是需要将建立信用卡处理基础功能作为第一个故事。之后添加更多的卡类型的工作量相对来说是微不足道的。 我们可以评估第一个故事要比其他三个故事大，但是如果产品负责人后来更改优先级，我们就必须记住要更改我们的评估。 相反，我们应该像这样推迟关于哪种卡类型先实现的决定：
…我可以用一种信用卡付款(VISA, MC, DC, AMEX)。
…我可以用所有四种信用卡类型(VISA、MC、DC、AMEX)付款(给定一种已经实现的信用卡类型作为参考)。
这两个新故事仍然不是独立的，但是与每种卡片类型一个的故事相比，其依赖性要明显得多。
模式 7: 简单/复杂
当你在计划会议上讨论一个故事时，这个故事似乎变得越来越大(“x怎么样?”;“你考虑过y吗?”)，然后停下来问，“这个最简单的版本是什么?” 一次来探寻一个简单的版本，作为它自己的故事。为了保持简单，你可能需要当场定义一些验收标准。然后，把所有的变化和复杂性融入到他们自己的故事中。例如，这个故事，
作为用户，我可以搜索两个目的地之间的航班。
通过分离变量来保持简单，比如，
…指定最大停靠次数。
…包括附近的机场。
…使用灵活的日期选择。
…等等。
这种模式实际上是关于寻找故事的核心并使之保持简单。 将每种情况放到自己的故事中。
模式 8: 延迟性能优化
有时，很大一部分工作是快速开发功能——最初的实现并不那么困难。 但是，你可以从缓慢的实施过程中学到很多东西，并且它对于无法以故事形式进行操作的用户具有一定的价值。 在这种情况下，将故事分为“让他工作起来”和“让他工作的更快速”：
作为用户，我可以搜索两个目的地之间的航班。
…(慢——只要能工作，显示一个“搜索”动画)。
…(不到5秒)。
这种方法可以满足任何非功能需求，而不仅仅是性能。你可以让它工作，然后让它安全。让它起作用，然后扩大规模。等等。
不过,要小心。人们很容易养成这样一个习惯，那就是把还没写完的故事称为已经写好了，积累了以后要偿还的债务。
模式 9: 拆出一个探针
一个故事可能很大，不是因为它一定很复杂，而是因为它的实现方式存在很多不确定性。在这种情况下，再多的谈论这个故事的业务需求部分也不会让你把它弄清楚。首先设定一个时限，以解决执行过程中的不确定性。然后，你就可以进行实现，或者更好地了解如何将其分解。不知道如何实现下面的故事吗？
作为用户，我可以用信用卡支付。
然后，把它分解成：
研究信用卡的处理过程。
实现信用卡的处理过程。
在“研究”故事中，验收标准应该是你需要回答的问题。做足够的研究来回答问题，然后停止；因为做研究很容易忘了你最初的目的。
探针切分是最后一个模式，因为它应该是你最后的手段。你可能知道的东西足够多构建你要的软件了。那就去做吧，在实践中会了解到更多知识。所以，在使用探针模式之前尽量先使用前八个模式中的一个。
元模式:找到复杂性并降低差异
当我们指导团队更有效地拆分故事时，我们发现了一个与这些模式相同的元模式:关注复杂性，并通过它减少差异。下面是如何直接使用元模式:
- 找出核心复杂性。 什么最有可能让你感到惊讶或出问题？这通常取决于人类的偏好或行为。有时，它是新的集成部分或外部依赖项。
- 识别差异。 差异可以有很多方面？业务规则，用户类型，接口，数据变体，实体等。
- 将所有变化减少到一个。 在复杂的部分中找到一个完整的切片。这可能是一个场景，也可能是通过单个业务规则变体产生的一系列场景。
大多数故事拆分模式只是识别差异的来源，并将其减少为一个示例。
这种方法对于新故事的最初的切片特别有效，因为它直接解决了核心复杂性，并且避免了其他任何事情都会使工作变得更大。
步骤 3: 评估切分
你经常会发现，你可以使用几种模式来切分一个用户故事。你应该选择哪一种切分方式呢？我们使用两条经验法则:
- 选择可以让你忽略或丢弃故事的拆分方式
80/20原则表明，用户故事的大部分价值都来自功能的一小部分。 当一个切分方式显示出低价值的功能，而另一切分显示不出来的时候，就表明后者在每个小故事中隐藏了浪费。选择能让你扔掉低价值东西的切分方式。 - 选择可以使您获得大小相等的小型用户故事的切分
将一个8点故事转换为四个2点故事的拆分比生成5点和3点的故事更有用。它为产品所有者提供了更大的自由，可以分别对功能的各个部分进行优先级排序。
你可能需要尝试几次才能找到最适合你的切分用故事的模式——实践出真知。
