文章摘要
用户故事是用于软件开发的简单且有益的工具，专注于满足用户需求，同时提供最大的商业价值。它们通过促进一致和有效的沟通，为具有详细要求的传统软件开发计划提供了替代方案。
用户故事是用于软件开发的简单且有益的工具，专注于满足用户需求，同时提供最大的商业价值。它们通过促进一致和有效的沟通，为具有详细要求的传统软件开发计划提供了替代方案。学习编写好的用户故事可以帮助您的团队在整个开发过程中保持与产品所有者的透明度，并为最终用户提供最大的价值。
什么是用户故事？
用户故事是通过利益相关者之间使用敏捷方法进行软件开发的对话来扩展用户需求的表达。故事以对用户、他或她的愿望以及最终目标或利益的书面描述开始。用户故事最初用 1-2 句话写在索引卡或便利贴上。它遵循以下格式：
作为[特定用户]，我想要[需要]以便[利益/奖励]。
用户故事示例：
作为一名学生，我希望我的个人资料列出我的课程并包含指向每个课程主页的链接，以便我可以访问日常作业。
作为网站访问者，我想每天在主页上阅读一篇新文章，以便及时了解最新事件。
作为网站访问者，我想阅读隐私政策，以便了解哪些信息将保持私密。
一个好的用户故事简单明了。使用技术语言会在团队和产品负责人之间造成障碍，过多的细节没有什么可讨论的。故事应该是讨论的提示，而不是详细标准的文件。Ron Jeffries使用 3C 描述了该过程：卡片、对话和确认。在像 Scrum 这样的敏捷框架中，用户故事是在迭代或冲刺期间开发的，并通过实施来自对话的反馈来改进。
用户故事应该包括什么？
用户故事应该包括用户[谁]、他或她需要[什么]和最终目标[为什么]。格式很简单，但某些品质将好的用户故事与坏的用户故事区分开来。Bill Wake 在Extreme Programming Explored中使用首字母缩略词 INVEST来解释编写良好的用户故事的特征。
独立的。一个用户故事不应依赖于另一个用户故事来完成。
面议。故事是一个简短的对话提示，并不那么详细，以至于没有什么可以讨论的。
有价值的。故事的结构是为了突出特定软件将为其用户提供的价值
估计。故事的完成时间应该可以根据其复杂性 进行衡量，并在迭代中分配。
小的。一个故事应该足够易于管理，可以在几天内完成。
可测试。一个故事的成功完成可以通过预先确定的验收测试来衡量。
如何编写用户故事
了解您的用户。首先，弄清楚用户的范围和目标，以避免为每种类型的用户开发用户故事。也许任何人都想使用您的网站或应用程序。也许只有特定区域内的人会受益于它的功能。创建准确的用户故事的最佳方法是与潜在用户交谈并在开发过程中接收他们的反馈。
定义您的用户。在卡片上乱写名字是不够的。名称不提供有关用户的任何信息。相反，给出一个标题（站点管理员）或简要说明（新用户）。您不需要注意您的用户喜欢足球、住在克利夫兰、只在星期六使用该应用程序，并且喜欢 Lay 的薯片，但您可能想要这样做。创建用户角色可能会令人兴奋，并让您深入了解用户的需求。用户角色包括用户的姓名、描述和目标。
写故事描述。保持简短（1-2 句话）和非正式的。您可能希望从更大的史诗故事开始，并在规划过程中将它们分解为更小的部分。不要使用与用户角色不匹配且开发团队以外的人不易理解的技术术语。
与团队成员和产品负责人交谈。细节在讨论过程中被揭示，不应该在迭代规划过程中被仔细检查。
完善故事卡。所有好的故事都要经过修改。用户故事是流动的，不是契约性的，实施反馈对于他们的完成至关重要。
将验收测试添加到故事卡。验收测试保证故事满足用户的需求，以及开发团队的任何详细标准。
创建敏捷用户故事
用户故事在敏捷框架中经历了不同的开发阶段：
写作
产品积压
迭代计划
发展
测试
确认
谁编写用户故事？
客户团队或产品负责人编写用户故事。开发人员通常不会编写故事，但会在规划过程中进行协作。他们估计完成每个故事需要多长时间，根据复杂性为每个故事分配一定数量的点，然后确定每次迭代可以完成多少故事点。
什么时候应该写用户故事？
用户故事可以在项目期间的任何时候编写并添加到产品待办事项中。故事优先考虑最大的用户和商业价值。它们是从积压中选出的，并根据优先级分类成堆。每 1-2 周的 sprint 平均包含 10 个故事。一个用户故事不应该跨越多个冲刺。相反，它应该被分成更小的故事或保存在积压中。包括客户团队、开发人员和产品负责人在内的对话应该在迭代或冲刺计划期间以及每个 3-6 个月的发布之后进行。
如何为用户故事添加细节？
验收测试证明所有细节都已成功处理并确保完成用户故事。如果一个故事太宽泛，它可以分成更小的故事。项目工作开始后，在对话期间添加细节，而不是在故事写作阶段。
用户故事的类型
1. 史诗：一个更大、更广泛的用户故事，旨在在开发之前分成更小的故事。史诗可以以用户故事格式或简单的短语形式编写。
示例：用户个人资料
2. 功能性：描述为最终用户带来直接价值的功能的高级故事。这种类型的故事遵循标准的用户、需求、利益格式。
示例：作为网站成员，我希望我的个人资料显示我的工作经验，以便吸引潜在雇主。
3. 技术：支持功能性用户故事的可选子故事，以提高清晰度和组织性。技术用户故事由开发人员或其他了解技术后果的人编写。这些故事是为开发团队的利益而编写的，而不是呈现给产品所有者。它们可用于错误修复、重构和开发基础设施。
示例：为了建立用户档案，我们必须允许用户通过 LinkedIn 社交登录按钮与他们的 LinkedIn 帐户同步，以将他们的工作历史直接拉入数据库。
用户故事与用例
用户故事和用例相似，但在编写时考虑了不同的目标。用例优先考虑文本，而用户故事优先考虑对话。用例一开始就关注技术细节，在整个开发过程中提供较少的讨论空间。它提供了一个更永久的文档，包括扩展的场景和扩展的详细信息。
用户故事与需求：编写需求，但讨论用户故事。需求文档类似于“待办事项”列表，但故事充当需求的来源。
用户故事与任务：任务是可以独立完成的一项工作。用户故事永远不会作为一个单独的项目来完成。协作和对话保证了成功的用户故事。
好的用户故事的好处
确保您的团队始终如一地提供为用户带来直接价值的功能
防止在项目开始时浪费时间开发大量功能，而不考虑糟糕的用户体验并减少用户流失
在项目开始时消除详细的合同协议，这些协议会限制创造力并阻止基于经验的决策
允许产品负责人参与开发过程
能够创造性地解决问题
通过透明度和一致的沟通帮助与产品所有者建立牢固的关系
允许在整个项目中进行调整
移动应用的用户故事
创建应用程序用户故事会引发关于您的应用程序成功之处、用户对您的应用程序的需求以及您的应用程序在参与度和体验方面缺乏什么的反馈和讨论。在为您的移动应用编写用户故事时，请注意不要假设每个用户都想要某个特定功能。如果你的应用有太多的功能，你可能需要回到绘图板来处理那些为用户提供最大价值的最基本的功能。
为确保您创建最适合用户需求的应用用户故事，请询问：
谁在使用该应用程序？
谁不太可能使用该应用程序？
他们的愿望、需求和期望是什么？
这个应用程序提供了您的网站无法提供的或竞争对手无法提供的功能？
我们将如何确保适当的反馈和指标来跟踪这些信息？
应用程序开发的用户故事示例
作为一个典型的用户，我想要简单的导航，因为在应用程序上有很多事情要做。
作为一个罕见的用户，我想要重新沉浸式参与，以便我可以轻松地重新熟悉应用程序的工作方式。
作为一个持怀疑态度的用户，我想轻松控制我的隐私设置并知道使用了哪些安全协议，这样我才能感到安全。
确保根据实际应用使用情况和体验应用来自真实用户的反馈。不要总是假设您的团队对您的最终用户了如指掌。他们的愿望、行为和偏好各不相同。并且不要仅仅依赖于应用程序开发中的用户故事。利用其他方法，如细分分析、客户映射和跟踪用户流，有助于更好地了解用户行为。
为什么要写用户故事？
开发良好的应用程序或其他软件应该以某种方式改善用户的生活，或者根据他们的使用情况提供奖励。用户故事可帮助您的团队在应用体验和应用奖励之间取得平衡，并帮助确保功能满足并超出用户期望。如果使用某项功能的回报很大，但体验却是压倒性的，或者如果体验很有趣但回报不足，则用户不太可能返回。用户故事允许在整个开发过程中不断审查和修改，团队成员开始项目时知道每个功能将提供的价值。
公安备案：皖公网安备34019102000119号