【翻译】工作故事为用户故事提供了可行的替代方案

【本文翻译自Mike Cohn的博客】

工作故事将重点从故事的执行者转移到故事发生的时间

尽管用户故事（User Stories）很有用，但它们并不适合每个团队。对于有些团队来说，一个激动人心的选择是工作故事（Job Story）。一个工作故事不太关注于用户执行哪些功能，而更多地关注该故事要完成的工作。工作故事起源于对讲机（Intercom），艾伦•克莱门特（Alan Klement）对此做出了最好的解释。

工作故事模板

要明白工作故事如何将重点从用户转移到要完成的工作，让我们看一下推荐的工作故事模板：

工作故事模板

与普通用户故事模板一样，工作故事模板也有三个部分需要完成。首先被称为情境（Situation），该部分紧随模板中的When一词，提供有关何时执行故事或触发故事原因的上下文（Context）。例如：

• 当提交订单后…
• 当通过邮政编码搜索时…
• 当找不到匹配项时...
• 当查看最近的订单时...

工作故事第二个元素的模板是I want to，该元素提供了故事的动机（motivation），动机可以当做用户的既定目标或首要目标。

例如，我想在今晚晚餐时吃披萨。为什么今晚要吃披萨呢？因为我今晚要跟一些朋友看足球比赛，披萨饼可以满足不同饮食需求和偏好的人。在工作故事的世界，容易提供一组被称为预期的结果（expected outcome），使之遵循工作故事第三个模板so I can。

把我对披萨的渴望变成一个工作故事会导致：

当今晚晚餐的时候，我想吃披萨，这样我就可以轻松喂饱我的朋友们。
When it’s dinner time tonight, I want to have pizza so I can easily feed my friends.

这不是一个特别完美的工作故事，但它说明了用户动机（motivation）与预期结果（expected outcome）之间的差异。

工作故事和用户故事对比

要找出工作故事可能比用户故事更好的使用场景，让我们看一些工作故事及其相应用户故事的示例。

提交订单时...

让我们从这个工作故事开始：

工作故事：

当提交订单后，我希望看到一条警告消息，以便避免重复提交订单。
When an order is submitted, I want to see a warning message so I can avoid resubmitting the order.

此故事描述了大多数电子商务网站上出现的行为，警告用户不要多次提交订单。

等效的用户故事：

用户故事：

作为客户，我希望显示一条消息，告诉我不要两次提交订单，这样我就不会重复下订单。
As a customer, I want to be shown a message telling me not to submit an order twice so that I don’t place a duplicate order.

在这种情况下，工作故事比较出色，有两个原因。首先，这个故事适用于在网站上购物的每个人。因此，知道执行此操作的人是客户并不重要。（实际上，称此人为客户（customer）可能会产生误导，因为在下订单之前，该人可能不是客户。）

其次，工作故事更好的原因是它提供了有关何时发生的上下文（Context）。正如工作故事告诉我们的那样，这种情况是在“订单已经提交后”发生的。仔细查看用户故事，您会发现它永远不会告诉我们何时显示此消息。团队可以通过在FAQ页面上添加一个条目来“成功”实施用户故事，警告不要重复提交订单，但这几乎肯定不是PO想要的。

订单已经提交后...

接下来，让我们看一下有关通过美国邮政编码搜索地址的工作故事。

工作故事：

当按美国邮政编码搜索时，我希望输入5或9位数字的邮政编码，这样我就不会浪费时间搜索明显无效的邮政编码。
When searching by US ZIP code, I want to be required to enter a 5- or 9-digit code so I don’t waste time searching for a clearly invalid postal code.

这个故事描述的是确保用户在允许搜索之前输入合适的邮政编码信息，美国邮政编码是5位或9位数字，这个故事明确说明应该避免输入两个字母也可以点击“搜索”。

等效的用户故事为：

用户故事：

作为一个用户，我希望被要求输入5或9位邮政编码，这样我就不会浪费时间搜索明显无效的邮政编码。
As a user, I want to be required to enter a 5- or 9-digit postal code so I don’t waste time searching for a clearly invalid postal code

这两个故事强调了用户故事和工作故事之间的区别在于模板的第一部分：When…和As…子句不同。在此示例中，每个故事的其余部分在用户故事和工作故事格式上都是相同的。

与第一个示例一样，这里的工作故事更好，因为它在执行故事时提供了更多上下文。谁来执行操作（在这种情况下为搜索）并不重要。

何时使用工作故事

在决定何时使用工作故事时，我认为重要的是要承认用户故事和工作故事都具有独特的优势。

我仍然坚持认为用户故事对于产品用户差异很大且需要深刻理解这些用户的场景是非常重要的。这就是为什么用户故事以As a...作为开头的原因。我们以这种方式开始用户故事的原因是，这样可以使用户置身事前。随着用户故事的展开，谁（Who）会做的故事也许一样是他们（They）都会做的事情。（译者注：即用户故事可以描述一类人共同的需求）

相反，在工作故事中，谁在做故事并不一定重要。当您的产品有明确的用户，但他们的需求不是很明显时，这使工作故事成为更好的选择。

如果您曾经写过冗长的用户故事集，并且每个故事都以“作为一个用户（As a user）...”开头，那么您就遇到了这个问题。当大量用户故事都以“作为一个用户（As a user）...”开始时，您会获得一组对于这个用户而言不是很重要的故事。（译者注：注意这里的作为一个用户，就是用户故事的开头，可以参照刚才的用户故事。）

将这些内容写为工作故事而不是用户故事会很有帮助。这样做可以使故事包含执行故事的其他上下文。在某些情况下，知道故事何时可能发生比知道谁来执行故事更为重要。

结合工作故事和用户故事的优势

因此，虽然工作故事和用户故事各自具有自己的优势，但可以通过将它们合并在一个故事中获得两种好处。让我们重温一下邮政编码故事，看看如何做到这一点。首先，我们有工作故事：

工作故事：

当按邮政编码搜索时，我希望输入一个有效的代码，这样我就不会浪费时间搜索明显无效的邮政编码。

目前尚不清楚谁来执行这个故事。是普通用户吗？网站管理员？还是其他人？我们未被告知。如果我们认为知道谁在进行此操作很重要，则可以通过在故事中添加角色代替我（I）来扩大工作故事。这会将我们的故事更改为以下内容：

工作故事：

当按邮政编码搜索时，买家希望被要求输入有效的代码，以使买家不会浪费时间搜索明显无效的邮政编码。

更改以粗体显示。您可以看到我刚刚从“我想要...”更改为“买家想要...”，然后在故事的后面进行了相应的更改。

我们可以对用户故事做类似的事情。我们最初未修改的故事是：

用户故事：

作为用户，我希望被要求输入有效的邮政编码，这样我就不会浪费时间搜索明显无效的邮政编码。

为了提供其他上下文，我们添加了一个短语来说明用户何时进行此操作。我们修改后的用户故事将变为：

用户故事：

作为要按邮政编码搜索的用户，我希望被要求输入有效的邮政编码，这样我就不会浪费时间搜索明显无效的邮政编码。

修改后的用户故事和工作故事在语义上是相同的。您选择哪种完全取决于您。我个人更喜欢修改的用户故事而不是修改的工作故事，因为它可以使故事保持第一人称。我在其他地方写过用第一人称故事的好处。

何时使用工作故事

那么，用户故事或工作故事都要在什么时候使用呢？

首先，每种故事都是伟大的，都有自己的优势。在每周的工作中，我都会写一些用户故事和一些工作故事。两种技术完全兼容，没有理由将它们视为互斥的。

如果您的产品有用户，并且这些用户的需求在重要方面有所不同，则建议使用用户故事。用户故事对执行该操作的人员的额外强调可能会引出对用户行为的更多见解。

但是，如果您产品的用户没有明显不同，则工作故事可能会是更好的方法。

一个好的起点是将用户故事和工作故事混入同一Product Backlog中。任何时候，如果您想编写一批以“作为一个用户（As a user）...”开头的故事，就从撰写工作故事开始。

您的经验是什么？

您如何看待工作故事？它们对您的Product Backlog有帮助吗？您以前有使用过它吗？他们有帮助吗？请在下面的评论中分享您的想法。