拆分用户故事

IT帮学习资料，共1页

在我指导的Scrum团队中，一个常见的问题是用户故事太大。当用户故事太大时，很难理解，估计和实施。那么，对于用户故事而言，合适的大小是多少？我的指导是，应调整产品待办事项顶部的用户故事的大小，以便Scrum团队可以轻松地每周完成四到六个故事。

团队如何在产品待办事项列表中记录重要故事并将其分解为较小的故事？今天给大家分享4种用于拆分用户故事的技术，基本上可以应对您工作中面临的大部分故事了。

链接: https://pan.baidu.com/s/18uCc6Zw31e5qI0aUCTq1BQ 密码: 6wf3

当团队的用户故事较小时，他们会更频繁地完成故事。这在许多层面上都是不错的。每当故事完成时，团队便会交付价值，这就是企业支付给我们的事情。对于每个完成的故事，我们还会获得多种类型的反馈。我们可以更新发布（storypoint）燃尽图并获取重要的进度反馈，从而使我们能够检查和调整进度。每当我们完成一个故事时，我们也会获得产品反馈。我们有一些新东西可以向我们的利益相关者展示，他们可以给我们反馈和指导，以便我们可以调整产品计划，以更好地构建我们的利益相关者想要的产品。此外，我们还会获得技术和架构方面的反馈。直到我们有了有用的用户故事，我们才能看到我们所做出的技术和架构选择为我们服务的程度。如果我们的原始想法未能如期实现，那么我们将需要调整架构以更好地支持正在开发的功能。

好吧，较小的故事更好。团队如何在产品待办事项列表中记录重要故事并将其分解为较小的故事？我有4种用于拆分用户故事的技术，但到目前为止，我还没有遇到过至少不会采用这些方法之一的用户故事。总有一天我会找到这样的故事，希望我会学习第五种技巧。

在应用这些技术之前，请先以普通用户故事形式编写故事：

作为（利益相关者类型），
我想要（某个东西），
这样（会创造一些价值）。

这不是写好故事的唯一方法，但是任何形式良好的故事都可以用这种方式写。这样做的好处是，以这种格式编写故事可以捕获任何好故事的三个重要方面：

1.此功能适用谁？
第一行对此进行了描述：作为（利益相关者类型）。利益相关者越具体，故事就越好。
2.我们应该创造什么？
在第二行中对此进行了描述：我想要（某物）。
3.为什么对用户有价值？
是的，这是故事的第三行：这样（创造了一些价值）。

如果我们不知道“谁，什么以及为什么”，那么我们还不是很了解这个故事。如果我们不了解这个故事，那么我们可能无法将其拆分。有了传统格式的故事后，我们就可以开始拆分它了。

1. 通过连接词拆分用户故事

这是一种非常简单的技术，这就是为什么我总是从此开始。只需阅读故事即可找到连接词，例如：和、或者、如果，何时，但是，然后等等。不要忘记逗号经常用作连接器。当我看到这些连接词中的一个时，通常可以通过将连接词固定在一起的片段将故事分为两个故事。这是一个例子：

作为一对规划我们的家庭计划的夫妻，
我们希望有一个适合我们十岁孩子和夫妻伴侣的活动的度假胜地，
这样我们大家都可以享受假期。

注意中间的一行：
“我们希望有一个适合我们十岁孩子和夫妻伴侣的活动的度假胜地”

我们可以将其分解为十岁孩子以及夫妻的故事。

作为与家人度假的十岁孩子，
我想和其他孩子一起做活动，
这样我可以结识其他朋友，而不是一直被我l父母困住。

and

作为一对和家人一起旅行的夫妻，
我们希望夫妻之间有浪漫的活动，
这样才能重新点燃我们的爱情纽带。

注意故事随着变小而如何变化？通常情况是，当故事变小时，价值陈述变得更加具体。用户通常会变得更加具体，有时甚至会完全更改。妈妈确实希望孩子们玩得开心，但为了满足这个要求，从孩子们的角度写故事可能会更好。有时，故事的其他部分也会变得更加具体。这正是我们想要的，因为较小的故事不仅更易于实现，而且更详细地描述。这样可以更好地理解故事，从而可以更好地进行估算，并最终增加团队构建正确事物的可能性。

2. 用通用词拆分用户故事

像第一个故事拆分技术（“连接词”技术）一样，第二个技术（“通用词”方法）通过解析用户故事的文本来起作用。这次，我们正在寻找通用词，而不是寻找连接词。什么是通用词？任何不是专有名词的名词都是通用名词，许多动词、形容词和副词也是如此。我们正在寻找的是故事中的通用或通用术语，可以用几个更具体的术语代替，以创建许多较小的故事。也许有一个例子可以帮助解释这一点：

作为一对和家人一起旅行的夫妻，
我们希望夫妻之间有浪漫的活动，
这样才能重新点燃我们的爱情纽带。

在这个故事中，“活动”一词非常笼统。我们可以用更具体的词来代替“活动”，例如：情侣按摩，两人浪漫晚餐和日落情侣巡游。我们将获得这些故事。

作为夫妻，
我们想做个按摩，
这样我们就可以一起放松，重新联系。

and

作为夫妻，
我们想要一顿浪漫的晚餐，
这样我们就可以有一个比第一次约会更浪漫的约会了

and

作为夫妻，
我们想在日落时进行一次双人巡游，
这样我们就可以享受没有孩子的浪漫时光

3. 使用验收条件拆分用户故事

验收条件是什么？验收条件是一个通过/失败可测试条件的列表，帮助我们确定故事是否按预期实现。每个用户故事应该有4到12个验收条件。产品负责人与团队合作，在每个用户故事进入sprint之前，为每个用户故事创建、商定并记录验收条件。

让我们看一个例子。下面是一个用户故事：

作为夫妻，
我们想要一顿浪漫的晚餐，
这样我们就可以有一个比第一次约会更浪漫的约会了

以下是这个故事的一些接受标准：

每张桌子上有两支点燃的蜡烛和鲜花
主菜包括牛排、鱼和至少一种素食
至少有2种红酒和2种白葡萄酒，还有香槟
有弦乐四重奏或钢琴演奏者演奏柔和的器乐
服务员穿着燕尾服

如果我们检查每个验收条件，我们可以问“谁想要这个？” 该问题的答案成为“作为（利益相关者的一种）类型”中的用户。接下来，我们问“他们为什么要那样？” 该问题的答案在“以便（创建了一些价值）”中标识了价值。接受条件的正文提供了“我想要（某事）”部分，现在，我们为新用户故事提供了所有三个部分：

作为（利益相关者类型），
我想要（某物），
因此（创造了一些价值）。

下面是可以从上面的验收条件派生出的用户故事。

作为一对在晚餐约会的情侣，
我们希望桌上有蜡烛，
这样心情才会更浪漫。

and

作为餐厅的食客，
我想从牛排、鱼和至少一种素食选择，
这样我可以点一些符合我的饮食和口味的食物。

and

作为一个葡萄酒爱好者
我要至少两种红酒，两种白葡萄酒和两种香槟，
这样我就可以选择一种与我的晚餐相配的葡萄酒。

and

作为一对在晚餐约会的情侣，
我想听听弦乐四重奏或钢琴演奏者的器乐，
这样气氛会更浪漫，我还能和我的约会对象交谈。

and

作为一对浪漫晚餐约会的情侣，
我要穿燕尾服的服务员，
这样我们就可以感觉像是在一家高级餐厅。

使用验收条件来识别较小的子故事是非常方便和强大的，因为它是递归的。每个故事都需要接受标准，许多接受标准可以成为自己的小故事。当然，每一个新的小故事都需要有一个接受标准。而且，我们可以使用这些接受标准来再次分解这些故事。

4. 使用时间轴分析拆分用户故事

偶尔，我会发现一个无法使用连词、通用词或接受标准拆分的用户故事。当这种情况发生时，我使用时间轴分析。

使用这种技术，我让我的利益相关者假装用户故事已经完成，然后我问“当功能被使用时会发生什么？“然后他们将描述一系列事件。即使是那些不确定发生的事情，或者可能同时发生的事情，他们仍然会按顺序描述；这就是我们的大脑和语言的工作方式。然后确定时间表中可验证的步骤。例如，如果我们从这个故事开始：

作为餐厅的食客，
我想从牛排、鱼和至少一种素食选择，
所以我可以点一些符合我的饮食和口味的食物。

如果我问用餐者从菜单中选择他们的饭菜时会发生什么，有人可能会描述以下情况：

我想决定在餐馆点什么。首先我浏览菜单。我喜欢看食物的图片，阅读描述。我关心的是卡路里，所以我会检查我正在考虑订购的商品的卡路里，然后再检查价格。我还想让服务员来告诉我那天有什么特别的东西。我真的很喜欢服务员详细地描述这些菜式，甚至还讲了一个为什么这道菜是今天的特色菜的故事。服务员会离开一会儿，这样我就可以考虑我的选择了。服务员回来后，我来点菜。

从这个时间轴，我们可以确定几个用户故事。

作为餐厅的食客，
我要一份菜单，上面列出每一项的说明、价格、卡路里和图片，
这样我就可以决定要订购哪些商品

and

作为餐厅的食客，
我想每天都有特别的东西，
这样我就可以尝尝菜单上不常见的独特菜肴。

and

作为一个食客，
我想在点餐前花点时间考虑一下日常的特色菜和普通菜，
这样我对我的最终选择感到高兴。

现在，您已经掌握了这四种将用户故事分解为更小故事的工具，您可能会问“我应该何时使用它们？”？“在产品待办事项列表的顶部拆分故事，直到它们足够小，团队每周可以轻松地完成其中的4到6个故事。当你把Backlog看得越来越远时，故事越来越大也没关系。你想要的是从产品Backlog底部的大型史诗故事逐渐过渡到顶部的那些漂亮的小故事。

拆分故事还有另一个很好的理由，那就是捕捉早期价值。想象一下，我们有一个用户故事，在度假区的任何地方都可以无线上网。这可能需要很长时间才能实现，而且要花很多钱。我们可以分解一个关于仅在大厅有无线访问权限的故事。这个故事将需要更少的时间、精力和成本来实现，但它将为那些需要在度假时偶尔访问互联网的用户带来价值。稍后，我们可以实现无线互联网的其余部分。