在本教程中，您将了解敏捷软件开发方法中的重要部分：用户故事。

我将带您了解什么是用户故事，创建用户故事时常见的问题以及用于验证您的用户故事是否“好”的框架。

以下是我们将涵盖的内容：

敏捷的起源

你可能听说过敏捷开发和用户故事。如果没有，让我们做一个简短的历史课：

用户故事是一个更大概念的一部分，称为敏捷方法论。

敏捷方法论自2001年起已经存在，当时17位受人尊敬的软件工程师在犹他州的一个滑雪胜地会面，并创建了现在臭名昭著的敏捷宣言。

如果罗伯特·马丁、马丁·福勒和肯特·贝克这些名字对你来说毫无意义，等你看完这篇文章后，去搜索一下他们。他们拥有丰富的知识，并且在软件世界中提供了一种更灵活的项目交付方式，称为敏捷。

什么是敏捷？

敏捷更多是一种思维方式，而不是一种规定的方法。虽然存在一些规定的方法，例如Scrum和看板，但敏捷是一种概念。

敏捷提倡协作、快速反馈，并且频繁地为用户提供价值。

敏捷思维方式鼓励项目规划的灵活性，这与当时的竞争者瀑布式项目规划形成鲜明对比，后者在交付内容和时间上非常严格。

敏捷方法论强调在项目开始时进行“足够”的研究，然后在整个项目中学习、迭代并根据需要更改设计和交付物，直到最终代码交付。这种“边走边学”的方法被称为“适应性规划”。

敏捷方法提倡快速且频繁地交付有价值的东西，通常是在每两周的“冲刺”结束时将代码交付到生产环境。这与传统的瀑布式规划非常不同，后者通常需要几个月的开发，才能将任何用户可见的更改交付到生产环境。

敏捷的另一个关键部分是关注利益相关者之间的紧密合作和频繁互动。产品、质量保证、工程和销售在项目生命周期内都有大量的输入和持续的反馈。

现在您对敏捷工作方式有了更多了解，让我们深入探讨如何验证用户的价值。

引入用户故事。

什么是用户故事？

用户故事是用简单明了的英语将工程师与软件的最终目标连接起来的一种方式。

它的设计使得非技术人员可以阅读并理解所交付的内容，同时工程师也可以查看并看到其价值以及如何验证您已交付该价值。

用户故事的结构

作为[用户类型]，当我[执行操作]时，[预期结果]

这就是最基本的结构。

您正在强调最终用户和您将提供的“价值”。

让我们深入了解输入：

  • 用户类型：没有一种适合所有人的“用户”。您有“管理员用户”，您有“已登录用户”，您有“具有权限X的用户”或“角色Y中的用户”。这就是具体说明谁在执行该操作

  • 执行操作：用户在做什么？点击“登录”按钮？删除记录？提交表单？

  • 预期结果：一旦用户执行了操作，应该发生什么？如果他们用正确的电子邮件地址和密码点击了“登录”，他们应该被引导到哪里？如果他们用错误的电子邮件地址和密码点击了“登录”，应该发生什么？

用户故事示例：

让我们来看一下登录页面的用户故事示例。

没有什么比示例更好的了。

让我们设定场景。你有一个登录页面，其中有一个输入框用于电子邮件地址，还有一个输入框用于密码。你有一个提交按钮。就这些。

从用户的角度来看，这个页面可能会发生哪些不同的情况呢？

作为一个已登录用户，当页面加载时，我会被重定向到已登录的主页。

如果我已经登录，我不想重新输入我的信息，只需将我重定向到已登录的主页。

作为一个未登录用户，当我输入正确的电子邮件地址但输入错误的密码并点击登录时，会出现错误信息。

我是一个尚未登录的用户，输入了错误的详细信息。我不应该被登录。

作为一个未登录用户，当我输入错误的电子邮件地址和密码并点击登录时，会出现错误信息。

再一次。我不是一个已登录的用户。我输入了错误的详细信息，我不应该被登录。

作为一个未登录用户，当我输入正确的电子邮件地址和密码并点击登录时，我会被重定向到已登录的主页。

这一次，我还没有登录，输入了正确的详细信息并点击登录。我成功登录系统。

你能看到这些都是围绕用户展开的吗？

你可能会注意到，上述“预期行为”中的某些内容并没有完全定义。我们稍后将在接受标准中讨论这一点。

如何编写好的用户故事

有一个很好的模型叫做INVEST模型，它简单明了地展示了如何判断你的用户故事是否优秀。

INVEST模型:

  • I独立性：可以单独开发。

  • N可协商性：开放讨论和更改。

  • V有价值：为用户提供价值。

  • E可估算性：可以估算所需的工作量。

  • S小型：适合在一个冲刺中完成。

  • T可测试性：具有明确的验收标准。

让我们将这个INVEST模型应用于上面提到的一个用户故事示例：

作为一个未登录用户，当我输入正确的电子邮件地址和密码并点击登录时，我将被重定向到已登录的主页。

(我在这里做了一些假设，因为这是一个理论上的代码库和理论项目)

这个故事是独立的吗？我会这么说，是的。这是一个涉及只有几个可能已经存在的组件的小故事。如果数据库尚未为项目创建，那么这会导致依赖性。这将不再是独立的。

它是可协商的吗？同样，是的。这个故事很容易更改为重定向到用户的个人资料页面而不是他们的首页。

这个故事绝对是有价值的。一旦实施，用户可以登录。如果这个故事是：

作为未登录用户，当我输入正确的电子邮件地址和密码并点击登录时，没有任何反应

这将没有任何价值。用户将得不到任何回报。

这个故事是可估算的吗？同样，我们必须在这个虚构的场景中做一些假设，但我肯定希望这个能够很容易被估算。这是一个简洁的故事，在大家都熟悉的领域中，涉及少量组件，并且有明确的验收标准。

这个故事肯定是小的。需要做的事情几乎没有歧义，只有一条用户路径和明确的结果。让我们看一个太大的故事：

作为未登录用户，登录页面应该按预期工作。

正如在本文前面讨论的，登录页面可以和应该以许多方式工作。“应该按预期工作”似乎涵盖了所有这些可能性。这将太大，无法有效地作为一个故事进行估算，可能太大而无法在一个迭代中完成。

这个故事绝对是可测试的。 有明确的用户操作以及清晰的结果。这个用户故事可以通过单元测试、集成测试和手动测试来覆盖。

看起来我们创建了一个好的用户故事！

如果使用我上面定义的结构，并且故事满足INVEST模型的标准，那它很可能是一个好的故事。

创建用户故事中的常见陷阱

我见过用户故事出错的情况，往往是因为人们忽略了一些关键方面：

关注技术方面

正如我上面的例子所示，用户故事是非技术性的。

不应该提及服务名称、数据库名称，或基于用户无法看到的任何内容的验证。

一旦你的故事不再能够被最终用户理解，你就出错了。

关注用户将要做的事情，以及用户将要看到的内容。

让我们来看一个技术性集中故事的例子：

作为一个未登录用户，当我点击带有正确电子邮件地址的忘记密码链接时，数据库表中会记录一条记录，说明密码重置链接已发送。

这个故事无法被用户验证，非技术用户可能无法理解它的意思。

让我们来修正它：

作为一个未登录用户，当我点击带有正确电子邮件地址的忘记密码链接时，将向提供的电子邮件地址发送一封包含密码重置链接的电子邮件。

非技术用户能够理解这一点，并将重点放在用户而非产品上。

利益相关者协作

敏捷是协作的。

用户故事需要来自产品、业务分析、质量保证、工程师，最重要的是用户的输入。

这将确保您提供用户所需的内容。众人拾柴火焰高。

例如，如果仅有工程团队提出用户故事，它们可能如下所示：

作为一个已登录的用户，当页面加载时，我被重定向到已登录的主页

作为一个未登录的用户，当我输入正确的电子邮件地址但密码错误并点击登录时，出现错误信息

作为一个未登录的用户，当我输入错误的电子邮件地址和密码并点击登录时，出现错误信息。

这很好。但现在让我们邀请质量保证团队参与，他们从不同的角度出发，因为他们在软件方面有不同的经验：

作为一个未登录的用户，当我用希伯来语输入正确的电子邮件地址和正确的密码时，我被重定向到主页

作为一个未登录的用户，当我输入正确的电子邮件地址和密码并多次点击登录时，我被重定向到主页

很好。我们现在得到了更全面的用户故事，涵盖了更多的情况。但如果我们让产品团队参与会发生什么呢？

作为一个未登录的用户，当页面加载时，我的密码管理器应该预填我的用户名和密码，当我点击登录时，我被重定向到主页。

产品团队了解用户。他们知道人们确实在使用密码管理器。我们应该确保当用户实际上没有输入任何内容时（因为文本是由密码管理器加载的），登录仍然能够正常工作。

模糊的用户故事

一个好的用户故事的想法是，无论专业知识如何，每个人都能理解它。

如果你写的用户故事可以被10个不同的人以10种不同的方式解读，那你就有点偏离方向了。

我在上面提到过我会谈到验收标准，现在是时候来讨论这个问题了。

让我们重新审视以下用户故事：

作为一个未登录的用户，当我输入错误的电子邮件地址和密码并点击登录时，会出现一条错误信息。

这里存在模糊性。

应该出现什么信息？在无效登录尝试后页面重新加载时，用户名文本框应该清空，还是预填上之前输入的值？“错误的电子邮件地址”是什么意思？是从未见过的电子邮件地址，还是目前无效的电子邮件地址（未支付订阅、取消订阅等）？

所以你可以看到，细节很重要。

这个用户故事是一个相当人为的简单示例，我发现了很多相关问题。

让我们来解决这个问题：

作为一个未登录的用户，当我输入一个未在系统中注册的电子邮件地址时，点击登录会出现一条错误信息。

这消除了关于用户操作的问题，但尚未解决有关预期错误消息的问题。

输入验收标准。

在用户故事中，您需要有一组验收标准，以定义用户故事的实现是否符合预期。

例如：

  • 错误消息：“无效的电子邮件地址或密码”

  • 电子邮件地址和密码文本框在重新加载时重置为空

  • 用户无法访问需要登录的页面

  • 用户会看到“忘记密码”的建议。

验收标准说明了实现的预期效果。

如何开始编写用户故事

从小开始。

您在开始时不会完美地提炼和创建用户故事。

创建用户故事既是一门艺术，也是一门科学。实践才能完美。

用户故事的创建应作为一个团队进行。通常，这会通过“3个好友”的方法进行，工程师、产品人员和质量保证（QA）一起坐下来，头脑风暴您需要支持的不同情况。

一旦您交付了项目，请进行回顾。回头看看您的用户故事中存在哪些漏洞。用户发现的错误，QA和UAT发现的错误，这些错误要么是由于用户故事中的漏洞，要么是由于测试中的漏洞。无论哪种情况，您都应该从中吸取教训，以便下次做得更好。

结论

敏捷开发是协作的。Scrum是协作的。创建用户故事是协作的。请记住这一点。

参与不同专业领域的人员共同进行用户故事创作，这样您覆盖全套工作流程的可能性就越大。

用户是重点。如果您在用户故事中包含用户不理解的术语，请重新考虑用户故事。

一开始您可能做得不太完美，但随着经验的积累，您会变得更快更有效。请相信一个从事这项工作已超过10年的人。与10年前相比，我今天创建用户故事的速度和质量完全不同。

请查看我的网站上的博客文章，Just Another Tech Lead，或者订阅我的每周电子邮件新闻简报这里。