关于敏捷开发:学习敏捷用户故事拆分流程和方法-IDCF

用户故事拆分是麻利交付团队的日常做法。然而以我的教训，执行起来真的很艰难。在本文中，我将所学到的无关故事拆分的所有内容汇总在一起。

我认为用户故事是范畴的单位，是交付的单位。

重要的是，用户故事向别人传递了有用的（或有价值的）信息。在 IT 环境中，“别人”通常指的是应用零碎的人（只管有时是另一个利益相关者，想以某种形式限度用户，例如爱护零碎免受未经受权的拜访）。

因而，通常从用户角度以“作为……我能够……以便于……”格局形容用户故事，从而迫使交付团队始终专一于用户正在试图达成的指标及其起因。

留神：术语“用户故事”通常用于两个有奥妙差别的场景。

如上所述，我通常用它来示意要交付的范畴单位，例如“咱们曾经在此 Sprint 中交付了故事 X，Y 和 Z”。
然而，它也宽泛地被用来指代这些范畴单位的形容 -“尽可能……我能够……如此……”范式。

在本文中，我应用术语用户故事来指代范畴自身，而术语用户故事形容则指的是这些范畴单元的阐明。当我议论故事拆分时，我说的是将范畴项拆分为较小的范畴项，而不是将范畴项的形容拆分为较小的阐明！

依据 INVEST 准则，用户故事应为：

独立 – 不依赖其余故事
可协商 – 并非变化无穷，能够进行探讨
有价值 – 对某些利益相关者（通常是最终用户）
可预计的 – 足够清晰，交付团队能够很好地晓得它有多大
足够小 – 小到足以在一个 sprint / 迭代中传递多个故事
可测试 – 如果无奈测试，则显然对任何用户都杯水车薪

以我的教训，这通常没有那么简略 – 拆分故事以使它们“足够小”通常会在故事之间引入依赖关系，而单个故事往往自身并没有价值，只有肯定数量的相干故事一起，它们才有价值去交付。

因而，我偏向于将 INVEST 属性视为准则，而不是无可争议的法律。一些属性更实用于史诗（大故事），而另一些属性更实用于小故事。

对于所有故事而言，我的一条规定是：无论故事多大，它们都必须提供用户可见的内容。这等同于垂直故事切分，前面会具体介绍。

拆分故事最典型的起因是将它们分成几小块 – 足够小以在一次冲刺中交付其中的几个。你怎么吃大象？一次一小块。

我认为，还有另一个起因等同重要（如果不是更重要的话），并且可能不太为人了解，就是与帕累托原理（也称为 80:20 法令）无关。

80:20 法令根本是说你能够在 20%的工夫内实现 80%的工作。换句话说，实现最初 20%的工作须要 80%的工夫。它反映了一个事实，即大多数工作都波及许多“花哨的工作”，这些工作须要很长时间能力实现，因而只管感觉您快要实现了，但实际上并不是。

在软件交付畛域，工作的最初 20%通常代表代替流程 – 异样，意外或谬误状况。通常，这些高付出的“怪异碎片”中的相当局部都是价值很低的 – 它们解决的神秘场景通常会在蓝色月光下偶然呈现一次。

拆分故事使咱们有机会将高价值的货色与低价值（高付出）的货色离开。一旦故事被拆分，并且子故事被搁置在产品待办事项列表中，则在从新确定优先级的对话期间，低价值故事会天然地过滤到待办事项列表的底部。

这样做的益处是，我永远不须要与产品负责人就是否应该解决某个非凡状况争论不休。我能够将其放在待办事项列表上，并让他们相应地对其进行优先级排序。我的项目发起人迟早会破费工夫在我的项目工夫调配上，低价值的货色将永远无奈交付（也称为“修剪尾巴”）。

拆分故事时，我会尽量牢记这两个指标：将它们放大，而后剥离低价值的局部。

通常会将大型故事称为史诗。

我的教训是，可能有必要对史诗（大故事）进行屡次拆分，而后能力找到适宜开发团队的“大小适中”的故事。这取决于原始（史诗）故事的大小，开发团队心愿这些故事的大小，以及我须要拆分多少次能力拆散出所有低价值内容。

因而，我将故事拆分视为一种迭代流动 – 一个大故事拆分为两个或多个子故事，而后能够进一步将每个子故事拆分为多个子故事，依此类推，直到每个故事都变得足够小为止。这并不是说我须要当时拆分所有的故事。我只在适当的时候拆故事，当前在须要时再拆。要害是最终会有故事的层次结构，层次结构能够有很多层，并且并非所有分支都具备雷同的深度。例如：

一些团队 / 办法 / 工具定义了故事的分类法，在层次结构中具备固定数量的级别。例如：

第 1 级：史诗 Epic
第 2 级：性能 Feature
第 3 级：能力 Capability
第 4 级：故事 Story

我不喜爱这种形式。我的教训是，故事层次结构并不总是参差地落入固定的层级，因而团队须要花太多工夫思考，“这个故事是史诗级的还是仅仅是功能性？”事实上是哪个层级并没有关系。

我更喜爱听从迈克·科恩（Mike Cohn）的倡议：一切都是故事。如果我合成一个故事，我会失去……一些故事。如果我有一个故事，感觉有点大，能够拆分，或者曾经拆分了，能够将其称为史诗，但这依然是一个故事。

一个史诗是一个用户故事，感觉大到足以进行宰割，或曾经被宰割。

重要的是，如上所述，无论故事大小如何，它依然提供用户可见且对利益相关者有用的内容，因而我仍能够用“作为……我能够……这样……”的格局来编写其摘要。

您如何晓得故事“足够小”？

我的教训是，这取决于你的交付团队以及冲刺周期。最近，我始终在两周一个冲刺的团队中工作，开发人员心愿故事小到能够在每个冲刺中交付 8 -12 个故事。他们心愿可能最多用几天来公布一个故事。

较小的故事能够进步工作效率和能源 – 团队成员能够一次专一于一件小事，并很快实现它 – 每天回家时都能够实现某件事，或者是有心愿完结。小的故事还有助于更好地进行资源打算 – 故事能够更轻松地在团队成员之间调配，并且更容易解决团队成员的缺席 / 来到。

将故事拆到如此水平通常意味着将其合成到能够被视为或者是独立的，或者是对最终用户有价值的水平 – 用户价值通常只有在交付了许多相干的、相互依赖的故事时能力失去。正如我下面提到的，很难让一个故事同时具备所有 INVEST 属性。

在我工作的每个团队中，咱们都通过重复试验找到了现实的故事大小。办法如下：我会筹备一些故事（曾经有了 BDD 草案，并在适当的创立了一些线框或 HTML 原型）。我会安顿一次三方会议，与团队一起逐个地过故事。对于每个故事，在我要求他们进行估算之前，我先询问他们是否认为故事足够小。如果没有，咱们会去找一种拆分办法。通过几次这样的探讨后，我会感觉到什么是一个故事的“适合大小”，并且通常会以适当大小的故事进入三方谈判。具备讥刺象征的是，随着团队的成熟和工作效率的进步，他们有时会感觉当初的故事太小了，最终可能会合并以前拆开的故事！

对此的简略答案是：Just In Time。

我须要大小适中的故事来进入下一个冲刺 / 增量。或者，如果我正在用看板，则只须要大小适中的故事来让所有开发人员忙起来。

我按优先程序剖析故事，包含拆分。因而，如果故事的优先级较低，那么它可能依然很大，因为我尚未对其进行任何剖析。

因而，我心愿产品积压的顶部左近的故事很小，而底端左近的故事会较大。我的待办事项应如下所示：

（顺便感激 Ken Rubin 的图）

其实真实情况并非如此。请记住，我拆分故事的动机之一是拆分低价值的，并让它们过滤到待办事项的底部。每次我合成一个故事时，重要的是要将子故事与其余待办事项从新排序，请确保这种过滤成果的实在产生。因而，在我的待办列表底部可能还会有一些小故事 – 这些是我曾经合成的那些低优先级故事。

在合成故事之前，我首先须要做一些剖析工作来了解这个故事。否则，我对它的理解不足以撑持如何拆分它。

实际上，我有一个相当结构化的流程来进行剖析工作。实际上，它是如此结构化，我给它起了一个名字：Business Analysis Designer Method（BADM）。下图总结了这一过程：

不要受骗，BADM 不是瀑布办法。相同，每个阶段顺次针对要传递的单个故事执行。

在“申请”阶段，须要一个故事，然而在那个阶段，咱们还不晓得指标是什么，或者实现目标的最佳办法是什么。
在“定义”阶段，BA 业务分析师会辨认利益相关者，理解机会空间，提出倡议如何实现机会并与产品所有者 PO 和其余利益相关者达成共识。BA 还会在适当的状况下将故事拆分为子故事。
子故事将被增加到产品待办事项列表中，并对其进行优先级排序，该办法将在子故事上继续进行迭代，直到它们“足够小”为止。
最初，在“设计”阶段，BA 交付所需的更具体的剖析 – 承受规范和 / 或口头计划（又称用例），线框（或 UI 原型），数据模型等。

我并不是倡议每个人都应该应用 BADM，然而在拆分故事之前花一些工夫来了解故事的范畴相对是一个好主见。

如上所述，我仅有一个宰割故事的黄金法令。当我拆分故事，每个子故事都必须提供一些用户可见的内容。当我说“用户可见”时，我的意思是在零碎的一个用户或零碎界面上能够察看到（一个用户当然能够是另一个零碎）。

这才是问题所在。当呈现“太大”的用户故事时，开发团队的第一个直觉通常是依照体系结构划分，一名开发人员进行数据库架构更改，另一个编写中间层业务或控制器逻辑，第三个人变更用户界面。

这个故事被“程度地”切分到了架构的各个档次。这种办法存在一些问题：

在所有相干故事实现之前，你看不到显著的用户收益
在所有相干故事实现之前，咱们无奈测试零碎
在所有相干故事实现之前，咱们不会发现任何体系结构问题
咱们错过了将高强度，低价值的局部宰割进去留作将来交付的机会

因而，首选的办法是“垂直”宰割故事，每个故事通过每个（相干）架构层传递一小段变更。这样，咱们在每个故事交付后都有一些（较小的）用户收益，咱们能够测试每个故事，并且能够更快地确定任何体系架构问题。

垂直切片故事时，请留神：

某些故事可能仅影响表示层（例如，更改字段或按钮标签），而不是对所有架构层进行切片。
有些故事会更改零碎界面，而不是用户界面。它们依然是“用户可见的”，然而在这种状况下，零碎的用户是另一个零碎，而不是人类用户。
一些故事是无性能的，例如性能或安全性加强。没关系，响应工夫的改善是用户可见的。
有些故事是事件触发的（批处理）过程，它们会影响零碎状态（即它们会更改数据库中的数据），但在产生时却无奈通过任何用户或零碎界面看到（只管稍后会看到其成果，下次查问数据）。这是“用户可见”规定的一个非凡例外，容许用户佩戴 X 射线眼镜以察看零碎状态的变动！同样，故事是能够测试的，然而测试人员须要在数据库中探测一下能力看到更改。

还要留神，一旦故事“足够小”，开发团队可能仍会决定将其分为“程度”局部：数据库变更，UI 批改等。这齐全没问题，将故事合成为工作（特地是开发工作），有些团队会在冲刺打算时这样做，以帮忙他们估算故事的工作量和 / 或在团队成员之间调配工作。不同之处在于，你须要了解并且有预期，除非所有开发工作都实现，故事才算实现（甚至能力进行测试）。范畴或交付的单位是故事，而不是工作。

我只在这里提供了垂直故事切片的摘要。有很多十分好的文章更具体地进行了介绍，例如 Ned Kremic 撰写的这篇文章。

如上所述，垂直故事切片就是将故事分成越来越小的用户可见的更改。每个故事，无论如许小，都会为用户带来有价值的货色，这有助于他们实现某些指标。垂直故事切片的另一种办法是用户指标合成。通过拆分故事，我将用户指标拆分为子目标。

咱们用一个例子来阐明。假如我有一个用户故事，如下所示：

注册
作为不须要的货色的所有者，
我能够注册在线拍卖网站
，以便能够发售不须要的货色

该故事的用户指标是注册在线拍卖网站。益处是卖掉我的货色。然而这个故事太大了，我想把它离开。所以我这样宰割它：

注册–输出详细信息
作为不须要的物品的所有者，
我能够输出我的注册详细信息（姓名，电子邮件地址等）
以便能够注册在线拍卖网站
注册–提交详细信息
作为不须要的物品的所有者，
我能够提交我的注册详细信息
，以便能够注册在线拍卖网站

我创立了两个子目标– 输出我的注册详细信息并提交我的注册详细信息。在这种状况下，后者取决于前者 - 我必须输出我的详细信息，而后能力提交它们。更重要的是，一旦我同时达到了两个子目标，我就实现了我的初衷– 注册在线拍卖网站。而后，我能够进一步细分子故事，直到我的故事“足够小”为止。我最终会失去故事的层次结构和指标的层次结构。

尤其要留神的是，子故事的“so that”陈说（利益）就是原始故事的“I can”陈说（指标）。换句话说，收益的确是更高层次的指标。一旦意识到这一点，编写子故事的“so that”局部就变得容易得多，它们只是父故事（即父指标）的“I Can”局部。

最好这样解释用户故事形容模板：

作为 < 用户 >，
我能够 < 指标 >
，以便 < 更高级别的指标 >

也能够得出结论，我最后指标的利益– 销售我的货色 –实际上只是一个更高级别的指标。反过来，这又是更高级别指标的子目标，能够赚钱。反过来又是购买食物的一个子目标，而后是供养我的家人，再而后让我的家人活着。依此类推，直到您最终陷入上一级指标的有限循环，或者陷入诸如“咱们存在的意义是什么”这样的哲学问题中……

因为用户指标的层次结构可能是有限的（向上和向下），因而的确存在迷失的危险。Alistair Cockburn 在其最出色的著述《写作无效用例》中很好地解释了指标合成，尤其是他通过辨认和命名三个特定的指标等级来建设了隐喻锚。他在书中谈的是用例，但该实践同样实用于用户故事。

最重要的指标级别是用户指标级别，也称为海平面或蓝色。在此级别上，一个用户能够在单个流动中实现（或未能实现）繁多指标，例如“列出要发售的商品”。您能够通过询问指标是否通过“咖啡工夫测试”来查看这个指标是否为用户指标：实现目标后，您是否有足够的理由来劳动一下喝杯咖啡？
高于用户指标级别的是摘要级别，也称为云 / 风筝级别或红色。摘要级别的用户指标是相干用户级别指标的汇合，例如“治理窗口小部件”细分为“创立窗口小部件”，“视图窗口小部件”，“编辑窗口小部件”和“删除窗口小部件”。
低于用户指标级别的是子性能级别，也称为水下级别或靛蓝。子性能级别的指标自身对用户无间接的价值，它们是实现用户级别指标的步骤，例如，“输出商品名称”是“列出待售商品”的子目标。“登录”是常见的子性能级别指标，登录自身并不能实现任何目标，它通常是实现其余指标的前提。

Cockburn 十分无意地抉择了海平面 / 云层 / 水下隐喻。天空很高，陆地很深，相应地有许多嵌套级别的云层指标和水下指标（并且有许多红色暗影和许多靛蓝暗影）。然而只有一个海平面——用户指标是用户指标，应该十分清晰地定义。须要廓清的是，我并不是在提倡三层固定的用户故事层次结构，我早些时候曾经对此示意了拥护。我只是说，辨认海平面在用户故事层次结构中的地位对于跟踪交付用户价值很有用。

有许多久经考验的形式来垂直分析故事。多年来，我留神到我偏向于按特定程序利用各种技术。有些技术实用于较大的故事，而其余技术一旦当故事变小就变得更加趁手。因而，我将按通常利用它们的程序来介绍各种技术。请留神，这不是变化无穷的规定。对于给定的故事，并非所有技术都实用，并且不肯定以雷同的程序应用。我可能还会屡次应用某一种技术。

开始了…

对于任何给定的故事，我想做的第一件事就是将其分为两局部：一部分交付性能自身，另一部分交付该性能的 NFR（非性能需要）。

拆分的次要目标是使团队专一于交付性能，而不会被 NFR 扩散注意力。在我的项目晚期尤其重要，此时有很多尚未解决的架构问题，当时让他们都一一解答会让事件变慢。

以下是您能够思考推延来关注的 NFR 列表：

性能：提早使其疾速
可扩展性：推延使其反对大量并发用户或大量数据
并发：推延使其反对多个并发用户（数据锁定，竞争条件等）
可用性：推延使其具备高可用性和容错能力
安全性：推延爱护其免受攻打
可用性 / 可拜访性：推延使其易于应用（实用于所有人）
UX：推延使其好看
跨浏览器 / 平台：推延使其实用于各种客户端设施
国际化：推延反对多种语言 / 本地约定

所有这些事件都具备扩散团队注意力的可能，使他们无奈疾速交付简略的货色（刚好能够失常工作），并且能够随后基于（重构）这些货色以在适当的时候交付各种 NFR。拆分 NFR 并对团队说：“咱们将钻研 NFR，但当初不用放心它们”。兴许咱们甚至能够在不（正式地）思考所有 NFR 的状况下提供 MVP。这取决于我的 MVP 是公开发行还是无限定向用户组的私人 Beta 版。

我通常一开始将 NFR 合成为一个繁多的故事，称为“Project X NFR”或“Feature X NFR”。在适当的时候，当咱们的确须要更具体地钻研 NFR 时，我才可能将这个 NFR 故事进一步细分为各个 NFR 类别（性能，可用性，安全性等），并一一列举，当然是按严格的优先级程序。

最终，对于每个后续故事，咱们可能会将相干的 NFR 纳入“实现的定义”中。但这是另一篇文章要阐明的事件。

恰好在“适当时候”产生，是一个很好的均衡。咱们不想太早地在体系架构上受挫，然而咱们也不想太晚去思考它，否则咱们可能会承当过多的技术债权，而且还要承当体系架构危险。同样的，判断是随同教训而来的，从来不会有一个惟一简略的答案，多年来，我见到的适度设计的零碎和设计不欠缺的零碎一样多。

这是拆分 NFR 的非凡状况。我下面提到的 NFR 之一是跨浏览器 / 平台的反对，如果我的零碎具备用户界面，并且打算反对多个渠道（例如，台式机，平板电脑，挪动设施）或多个平台（例如，Windows，Mac，iOS，Android，各种智能电视），那么首先集中精力在这些渠道 / 平台其中的一个是更有意义的，不言而喻应该抉择咱们认为大多数用户领有的渠道 / 平台。

然而，与其余 NFR 一样，这又是一个均衡：在我的项目中的什么时候开始思考其余平台？当然，没有正确的答案，这取决于具体情况。

我从事的一些我的项目具备公司（或政府）规范的 UI 框架，该框架曾经被设计为可响应的（即在多个平台 / 设施上工作）。显然，从一开始就应用规范框架是有意义的，前提是它绝对稳固并且不会减少过多的开销或学习曲线。即便咱们不抉择这样做，咱们依然能够抉择推延正式开始跨平台的合规性。这里有一个轻微的差别：推延正式合规，是说咱们还不会进行跨平台零碎测试。跨平台测试可能会十分消耗人力，通常最好在公布前不久进行一次，而不是在每个故事中都做一遍。咱们的测试人员当初能够专一于功能测试，并且咱们能够更快地停顿。

一些故事服务于多样化的用户社群。我在这里没有太多议论国际化，而是在思考用户类别。

例如，在最近的我的项目中，咱们的用户分为以下几类：

英国用户
欧盟用户（但不包含英国）
欧盟以外的用户（也称为“第三国”用户）

不要让我开始聊英国脱欧，这是另一个故事（呵呵）。

要点是，这三个类别的性能都不雷同。英国用户必须采纳一种办法进行注册，欧盟用户采纳第二种办法进行注册，第三国用户则采纳另一种办法进行注册。

因而，咱们决定首先关注英国用户。而后咱们发现了另一个分类：

英国集体
英国组织

同样，每个类别的性能都不同。因而，咱们决定首先关注英国组织。而后咱们发现了另一个分类：

英国注册公司
英国非法人公司
英国伙伴关系

信不信由你，这些子类别的注册规定又再次不同。咱们首先关注英国注册公司，并为他们提供了残缺的注册过程（只管咱们用稍后将介绍的其余技术进一步简化了注册过程）。而后，咱们开始依照业务优先级程序增加其余用户类型。再次回到英国脱欧——如果英国很快退出欧盟，咱们将不会辨别欧盟还是第三国用户，因而咱们将欧盟用户放在优先级较低的地位。

最初，咱们将用户群细分为大概 15 个用户类型，并针对大概 8 个独特的用户旅程进行注册。为第一种用户类型交付性能须要大量工作，随后增加的每种额定用户类型变得越来越容易。然而，如果咱们尝试一次全副实现这些工作，我认为工作将是无奈达成的。

到目前为止，咱们曾经拆分了各种 NFR，因而咱们能够先关注性能，而后再按用户类型进行拆分，以便专一于为单个用户组提供服务。

在接下来的拆分中，咱们回到后面探讨的“三个命名的指标级别”的概念。具体来说，咱们心愿将故事分解成能够通过“咖啡工夫测试”的单个用户指标（“海平面”指标），这些指标能够由一个用户一次流动就能够实现，而实现后则能够享受咖啡工夫。

一个十分常见的例子是将数据保护故事分为其 CRUD 组件，例如：

保护小部件

变成

创立小部件
查看小部件
更新小部件
删除小部件

另一个常见的例子是一个波及多个角色的故事。例如：

作为博客作者，我能够发表文章

可能成为：

作为博客作者，我能够要求公布我的文章
作为编辑，我能够批准发表文章

摘要级别指标还有有数其余类型，能够细分为用户指标。

子故事通常遵循逻辑程序，你必须可能创立一个小控件能力查看它，并且您可能想先查看一个小控件，而后再对其进行更新或删除。您必须先申请发表文章能力取得批准。但这并不一定意味着故事必须按程序交付，齐全有可能通过后门来创立窗口小控件（通过间接数据库加载），因而，如果查看窗口小控件是价值最高的子故事，则能够这样做。

到目前为止，咱们的故事处于用户指标级别：能够由一个用户一次流动就能够实现。作为美妙的一天，对咱们的用户来说所有都会很美妙。他们将执行操作、输出数据并实现他们的指标。这就是咱们所说的 Happy Path 计划。会有许多办法来实现目标，因而可能会有多条高兴的门路。

然而事件可能不会那么顺利，他们可能输出了有效数据，或者他们执行了不适当的操作，或者他们找不到正在搜寻的数据，并且他们可能未达到目标。在任何状况下，事件都可能会出错，因而咱们将其称为代替流程。

例如，

创立小部件

可能成为

创立小部件–胜利
创立小部件–小部件名称已存在

另一个例子：

登入

可能成为

这里的关键点是，某些代替流程的优先级可能较低。例如，解决有效的用户 ID 或明码是高优先级，然而在三次失败尝试后锁定帐户可能不是很高。

对于给定的用户级别故事，并非总是很分明所有代替流程是什么。为了找到它们，为次要的欢畅门路写出相应的步骤是一个十分好的主见。例如：

用户要求登录
零碎询问用户其登录详细信息（用户标识和明码）
用户输出登录详细信息
系统验证登录详细信息对现有帐户无效
系统验证帐户未锁定
零碎登录用户并显示主页

步骤 4 提出了一个问题：如果登录详细信息有效，该怎么办？咱们找到了代替流程。

步骤 5 提出了一个问题：如果账户被锁定怎么办？咱们找到了另一种代替流程。

如果您在想拆分代替流程时大刀阔斧，相对应该浏览 Alistair Cockburn 的书。

在技巧 5 中，我将故事分为集体流程 – 欢畅门路和代替流程。咱们很可能会先专一于交付次要的欢畅门路。然而在咱们这样做之前，我将先看一下它，看看是否有我能够先做的更简略的版本。

例如，假如咱们正在构建一个注册性能，而咱们想要捕捉的一个信息就是用户的生日。咱们能够将其实现为日期选择器，并弹出一个丑陋的日历。然而咱们也能够将其作为一个简略的文本输出字段来实现，这可能会更快，更容易构建。从而：

寄存器

变成

我有时称其为“铜镀层”，而不是“金镀层”，对于 MVP 来说曾经足够了。当然咱们能够做得更好，如同前文论述的，在待办事项优先级的驱动下，是否以及何时使它变得更好，取决于与其余的待办事项相比，咱们对日期选择器的器重水平。

这是解决团队外部争执于如何精确交付特定性能的一个好技巧。您将流程合成为“最低限度的最低要求”（即 MVP），而后为每个档次的要求别离建设一个故事。（产品负责人）可能会认为某些性能要求是必不可少的 – 没问题，咱们在 MVP 故事之后不久就做。其他人会将其放进待办列表，以待日后实现，兴许永远不做。乏味的是，我被屡次告知某项性能“必不可少”，仅仅是因为发现该性能在待办列表的底部停留了六个月之久。显然，它下面的所有内容都更重要。

这是您能够应用的其余一些镀铜技巧：

手动与主动。能够很容易地假如，因为您正在构建 IT 零碎，所以所有都必须齐全自动化，而有时手动解决能够用于解决大量工作或在 MVP 中应用。例如，除了 webops 团队运行的手动数据库脚本外，我以后正在应用的零碎无奈创立新的管理员用户。这是一种苦楚，但这种状况不会常常产生。
硬编码与可配置。兴许用户必须抉择他们的题目（学生，太太等）。现实状况下，选项列表应该能够从可配置列表填充，该列表可由管理员用户轻松保护。但作为捷径，该列表能够在页面中硬编码。
假如与要求。与其容许用户在你的博客利用自行抉择头像，你能够在第一个实例中主动为他们调配随机模式，自定义头像稍后再公布。
简略与简单的体系架构。函数的某些局部可能须要简单的体系架构解决方案。例如，地址查找性能须要与第三方软件集成，因而是否有一个更简略的选项能够防止应用它，例如手动输出地址？然而要小心，有时你想尽早解决架构危险，因而，如果该概念行不通，您能够“疾速失败”（请参阅上面的技术 999）。当然这个问题没有对立的答案。

因而，到目前为止，我曾经为单个性能确定了一条高兴门路，并且将其缩减为对 MVP 有意义的最低限度……

…然而我的开发团队依然心愿将其分解成较小的性能进行交付，以便他们能够疾速实现故事并查看进度。

这里的一种抉择是通知开发人员，在持续具备商业价值的同时，无奈正当地合成故事。另一个抉择是将其进一步合成，以使有价值的故事一次累积一点。

重要的是，咱们依然心愿垂直宰割故事，以便每个子故事都提供用户可见的内容。咱们不想程度地宰割故事，因为这只会给咱们开发工作，而不是故事。

不言而喻的事件是将性能合成为各个步骤。在第一种状况下，如果该性能波及用户遍历多个屏幕，则能够在每个屏幕上拆分一个故事。而后，您能够将其拆分，以便逐渐交付每一个屏幕。您的工作量取决于开发团队的偏好。我常常发现当团队还年老时心愿故事很小，而随着他们的成熟，能够应答更大的故事。

逐个步骤的一种变体是为该性能构建一个“骨架”。你从具备终点和起点但两头没有任何货色的性能开始。例如，一个“注册”按钮可通过“提交”按钮将用户带到空白页。当用户单击“提交”时，他们会收到一条音讯，告知他们已胜利注册。然而实际上什么也没产生。而后，一一故事地填补空白，收集各种数据并理论创立注册。要害是您能够采纳多种不同的形式对其进行合成，而不用按程序进行。

骨架办法的另一个变体是先构建前端用户流，但不建设后端 – 所有后端调用都被插桩。这样的益处是，它能够让您尽早看到残缺的用户流，并在不起作用时对其进行调整（只管另一种办法是构建简略的 HTML 原型）。

顺便说一句，此技巧的另一种用处是将故事从用户指标级别（海平面）拆分为子性能级别（水下立体）。

Spike 探针是一个旨在传递常识而不是交付生产的故事。当遇到大小和 / 或架构不确定的故事时，团队通常会“尝试 Spike”并花一些工夫进行根本的钻研，或者更可能是进行理论编码，以便更好地理解大小或办法。

从外表上看，这仿佛是个好主见，然而以下是我遇到过的探针问题：

指标不明确 – 与商业故事相比，探针故事不太可能具备明确的承受规范。
时间尺度不明确 – 实践上讲，应该对探针进行工夫限度，然而如果工作未知，那么最简略的就是说“好吧，让咱们看看它如何倒退”。

范畴不确定和工夫无限的联合，对于开发人员来说，这是一个随机摸索并看看会产生什么的机会。即便是纪律严明的开发人员，也有被带走的重大危险。

例如，假如咱们的团队正在构建 API，并且咱们决定应用 RAML 来阐明那些 API（RAML 是目前十分风行的 API 标记语言）。咱们心愿在咱们的网站上公布 API 文档，并且咱们决定一种较好的办法是构建一个 RAML 到 HTML 的转换工具。

因而，咱们进行探针，构建了一个 RAML 到 HTML 的转换工具。一个开发人员被调配到这个探针，而后开始。他们每天在站会上报告停顿，应该很快可能实现。几周后，停顿顺利，而且是个好消息 – 它完全符合 RAML 1.0，并且能够从任何无效的 RAML 文件生成 HTML！

然而，当咱们查看理论想要构建的 API 时，咱们发现咱们只须要应用 RAML 1.0 的子集，他结构的一半是节约的精力。

这个例子基于一个实在的故事，但实际上并没有那么蹩脚。在构建的过程中，咱们更改了办法。咱们没有持续“RAML 到 HTML 转换器工具”的介绍，而是开始定义面向业务的故事，为实在的 API 提供理论文档，而咱们专一于一次建设一点点 RAML 到 HTML 的转换，仅构建咱们理论须要的。通过这种办法，咱们防止了解决方案的适度设计，并且还更快地交付了一些理论的业务价值。

我的母亲总是通知我不要用尖利的铅笔到处走动，起因是如果我绊着而摔倒，可能会导致重大的事变并最终住院。换一种说法：

小心探针。

通常，我会尽量避免探针。相同，我花工夫与开发人员一起理解架构不确定性所在的地位，并尝试将一个故事合成为一些子故事，这些故事使他们能够一次理解一点儿架构，同时仍能始终提供业务价值。

将这项技巧编号为 999，有两个起因。首先，这是不得已的办法，必须在所有其余技术之后应用；其次，（在英国）这是您拨打的呼叫救护车的电话号码，这仿佛很适宜应用具备潜在危险性的技术！

当我着手撰写本文时，我并没有意识到会须要多长时间。具备讥刺象征的是，我写了一篇无关将史诗分解成故事的自身就是史诗的文章。

这篇文章的长度能够阐明问题 – 故事拆分很简单，以我的教训来说，做起来很难。我曾经做了很多年了，但我仍在学习新的技巧。这是通过实际和教训而能变得更好的技能之一，因而，如果您在挣扎中，请不要放弃！

自从您开始浏览本文以来，可能曾经过来了几十年，值得疾速回顾一下：

拆分故事不仅是要使故事变小，而且还要拆分低价值、高投入的局部，以便它们能够沉在待办事项底部。
拆分故事是迭代的，并且没有固定的迭代次数，因而定义固定的层次结构“史诗 / 性能 / 故事 / 其余”是没有意义的。
你编写的故事多小取决于你的团队是否称心。
故事应“及时”拆分，但只有在进行足够的剖析以便充沛了解故事后，能力进行。定期从新确定优先级，以确保低价值的事项的确压在舱底。
故事应垂直宰割，行将用户指标合成为子目标。
Cockburn 的三个命名指标级别对于跟踪你的指标十分有用，尤其是“海平面”指标，这能够由单个用户在单个会话中实现，因而能够在尔后喝咖啡庆贺。
有许多故事合成技术，而且我发现能够有一个统一的程序来利用它们 – 随着故事从大到小。
故事拆解很难！

比尔·韦克（Bill Wake）的文章，其中有很多对于如何拆分故事的想法，是为数不多的几篇文章之一让你意识到次要是为了将高价值的货色与低价值的货色离开。http://xp123.com/articles/twe…
理查德·劳伦斯（Richard Lawrence）的这篇文章也赞成 80:20 规定 – 并且它也有一些很好的模式来拆分故事。http://agileforall.com/patter…
迈克·科恩（Mike Cohn）对于故事就是故事这一事实的文章。https://www.mountaingoatsoftw…
Rachel Davies 的一些更杰出的模式，他还谈到了推延高价故事的想法。http://agilecoach.typepad.com…
由 Alistair Cockburn 撰写的无效用例 – 形容了三个命名的指标级别，并列出了代替流程的停滞。
麻利和业务剖析：Lynda Girvan 和 Debra Paul 撰写的 IT 业余人员实用指南 – 特地是第 8 章，它探讨了指标合成，也感激 Lyn 提供了对于指标合成的更多见解。
对故事拆分技术的很好形容，以及很好的深刻解释 Christiaan Verwijs 的垂直故事切片。http://blog.agilistic.nl/10-u…

原文地址：http://www.its-all-design.com…
译者：姚冬

玩乐高，学麻利，规模化麻利联合作战沙盘之「乌托邦打算」，2022 年 3 月 5 - 6 日登陆深圳，将“多团队麻利协同”基因内化在研发流程中，为规模化晋升研发效力保驾护航！!🏰⛴公众号回复“乌托邦”可加入

关于敏捷开发:学习敏捷用户故事拆分流程和方法-IDCF

一、什么是用户故事

1.1 用户故事的属性和 INVEST 准则

二、为什么要拆分故事？

三、故事档次和史诗

四、要拆多小

五、何时拆分故事

5.1 首先做一些剖析

六、垂直故事切片

七、用户指标合成

八、三个命名的指标级别

九、故事宰割程序

十、拆分用户故事的技术

技术 1：拆分 NFRs

技术 2：按用户界面通道拆分

技术 3：按用户类型拆分

技术 4：将摘要指标分为用户指标

技术 5：按场景 / 流程划分

技术 6：镀铜与镀金

技术 7：分步进行

技巧 999

十一、故事拆分很难

十二、论断

参考文献