用户故事如何改变我的开发流程

所有开发人员在职业生涯中都会遇到敏捷开发流程。根据公司实施敏捷的程度，开发人员会形成（呵呵）自己对敏捷的喜好。有很多方法可以开始使用敏捷流程，但并非所有方法都很好。但敏捷的某些组成部分，例如用户故事，确实非常有用。

学习如何正确应用敏捷流程来创建用户故事，改变了我对开发的看法。即使我所在的公司没有任何敏捷流程，我也总是尝试引入用户故事。以下是用户故事如何改进我的开发流程的几个例子。

它们让我专注于用户

撰写用户故事不同于编写任务清单。值得庆幸的是，产品负责人或其他更接近业务部门的人员通常会创建初始用户故事。他们直接听取了目标用户的意见，因此他们能够准确地告诉你用户的期望。

当开发人员编写任务列表时，这个关键部分很容易被忽略。用户故事为这些任务提供了重要的背景信息，让我知道完成这些任务后用户应该做什么。作为一名 Web 开发人员，以用户为中心是一项非常宝贵的技能，因为你编写的所有代码最终都会面对一些你不认识的用户。

通过在编写代码时考虑用户，我能够想出比任务列表更多的测试场景。任务列表很棒，但它们应该在用户故事编写完成后才出现。当你能将任务与故事联系起来时，你就能看到它对用户体验的真正影响。

他们帮助我弄清楚如何设置权限

我接触过的大多数应用程序都涉及不同的用户权限。有些用户拥有管理员权限，而有些用户则拥有应用程序特定部分的只读权限。如果没有用户故事，我就很难确定应该向不同用户展示什么内容、何时展示以及如何展示。

用户故事的魅力在于，你可以从不同的用户视角（称为角色）来编写它们。因此，你可以为管理员用户、只读用户、受限访问权限用户以及所有其他与应用程序交互的用户分别创建一个角色。大多数用户故事都采用以下格式：作为[用户角色]，我[想要]，[以便]。这种格式允许开发人员使用多个角色来了解如何为不同的用户完成相同的任务。

他们建立了所需的框架，让您能够轻松地站在多位用户的立场上思考。大多数用户故事都是通过对话创建的，因此您可以与其他开发人员或产品经理交流，并就特定类型的用户应该看到什么或能够做什么提出更多问题。

他们让我和我的团队保持一致

当你和其他三位开发人员一起查看同一份没有用户故事的任务列表时，很容易忘记最初执行任务的初衷。用户故事提供的宝贵背景信息可以防止这种情况发生。当任务被分解成用户故事后，每个人都能明白自己执行任务的原因。

很多时候，任务背后的“为什么”会被遗忘，开发团队会将其移除。然后，当用户尝试执行某项操作时，每个人都会记得为什么会有这个任务。用户故事可以帮助你避免这种情况。当答案只是一句简短的句子，解释用户需要做什么时，就不会再问“为什么”。

这将节省您大量的时间来筛选每个开发人员的所有解释，并且它将节省您的脑力，让您不必不断地试图记住为什么你们一开始都要做这些事情。

它们比需求文档更容易理解

我最喜欢用户故事的地方在于它没有任何专业术语。就像一个用户走到你面前，告诉你他们想要做什么以及它能实现什么一样。正因如此，它比那些充斥着各种专业术语、甚至连作者都无法理解的十多页文档更容易处理。用户故事是用非正式的句子来描述用户想要做的事情。

接下来，开发团队将决定如何将这句话分解成技术术语。用户故事或许无法完全取代需求文档，但它无疑能让需求文档更清晰易懂。当你需要理解所有术语背后的逻辑时，用户故事会非常有帮助。

它们让我开心

自从我开始从事 Web 开发以来，我的幽默感就……更新了。你会惊讶于用户故事里潜藏着什么，或者用户那些疯狂的期望。你不会每天都能找到它们，但用户故事本身就能带来娱乐感。有时，开发人员会钻研一些奇思妙想，最终会得到一些令人匪夷所思、挥之不去的用户故事。

这并非用户故事的真正功能，但它能让一天过得更快一些。你甚至可以在团队内部发挥创意。它能让冲刺过程轻松一些，也能让开发团队开怀大笑。何不从中得到些许乐趣呢？

用户故事确实应该成为任何敏捷流程的重要组成部分，因为它们定义了你真正需要的东西，以及用户在下一个版本中会期待什么。深入探讨用户想要做什么以及为什么这么做，可以在问题真正到达用户面前之前就将其揭示出来。这也能让你和你的同事有充分的理由去完成分配给你们的工作。

你觉得用户故事怎么样？我觉得它们很棒，而且很简单。你以前见过什么奇葩的用户故事吗？

嘿！你应该在 Twitter 上关注我，理由如下：https://twitter.com/FlippedCoding