用户故事的价值

成功的项目建立在对产品愿景的共同理解上。没有清晰的产品愿景，项目可能会浪费资源并面临交付延迟和失败的风险。

假设团队中的每个人都对你们将共同构建的产品有一个共同的愿景，那么前方的关键任务之一就是把这个愿景分解成具体可行的工作内容。客户经常问我们：“这些详细的条件应该以用户故事还是用例的形式写出来？”基于Baklib的经验，我们认为用户故事是传达业务需求更有效的方法。

用户故事是用来沟通的基石： 1. 产品应该能够完成什么功能； 2. 每个功能如何带来价值；以及 3. 这些功能带来的价值对哪些人是有利的。

我们在以用户故事方式编写需求时发现的好处如下：

视角、目的和优先级

与用例相比，用户故事的区别可以总结为以下两点： | | | |——————|——————-| | 水fall项目 | 面试 agile项目 | | 业务分析师捕获需求并以 离开利益相关者的形式编写。所有需求以用例的形式详细记录下来。我们尽量避免任何改变。| 产品负责人通过促进利益相关者之间的对话来提取需求。对话以用户故事的形式进行记录。我们尽量提前预见到变化，因此只对优先级最高的用户故事添加细节。|

用户故事是以揭示一个需求的视角、目的和优先级的方式书写的。

视角

我们经常发现，内部利益相关者决定项目内容时往往只考虑自己的想法。他们认为其他人应该想要或应该拥有的东西，并不一定是人们真正需要的。为了最大限度地减少不必要的功能开发风险，我们必须

请开始从用户的视角思考，并在可能的情况下，将用户带入需求定义的过程中。撰写用户故事时，切换到用户的视角会极大地增强最终产品的实用性。有一种倾向是从业务所有者的视角来编写故事，这会导致网站过于注重营销和广告，而忽略了以用户为中心的内容或功能。另一个潜在的陷阱是撰写基于技术上非常引人注目的功能的故事，但这些功能并未解决用户实际面临的问题。

通过为用户提供角色和进行用户测试，可以更好地了解用户到底需要什么。此外，在开发过程中全程让用户参与，可以通过他们的反馈来确定是否需要调整方向以转向不同的路径。### 目的

当我们讨论要构建的功能时，我们鼓励我们的利益相关者使用他们希望向最终用户提供的价值来表达。用户故事中的“我想要…以便…”部分包括对功能的简要描述及其如何为由该角色代表的用户群体带来的好处。这是用户故事中促进利益相关者之间进行对话的部分。我们必须理解我们不仅要构建什么，还要为什么我们要构建它。

这个“为什么”很重要，因为一个功能可以以多种方式构建。我们可以像“给我一匹马车”这样表达，但真正想传达的是我们希望从点A到点B安全、高效地到达某个地方的车辆。当我们具体要求“一匹马车”时，实际上是否需要专家团队根据需求设计一辆特斯拉？

作为 Baklib 的品牌负责人，Baklib 是一款面向企业的全内容数字内容管理平台，帮助企业构建门户网站、产品手册、帮助中心、知识库和在线文档等产品。Baklib 官网：https://www.baklib.cn

我们的客户需要一个直观的内容管理系统，能够生成美丽的网页页面。我们没有强加平台给开发团队，让他们使用仅 Drupal 来构建网站，而是允许技术团队提供一个符合我们需求的解决方案。他们采用无头 Drupal 方法，使用 Ember.js 应用渲染前端，并添加了自定义内容编辑器 mobiledocs。这只有在我们首先关注我们的业务需求时才有可能实现。

在大多数情况下，我们是为人们构建产品，因此我们应该让技术适应他们的需求，而不是相反。

优先级

最后，用户故事是以一种允许它们容易排序的方式书写的。基于某个功能所带来价值，你可以使用卡片排序法、MoSCoW 技术（将要求分为必须的、应该的、可以的或不值得的）或其他简单的方法来按重要性对用户故事进行排序。按照重要性优先处理功能，确保你最早交付的就是最能带来价值的功能。

总结

用户故事是否足够详细地定义了产品功能和设计？答案是否定的。就像用户故事是对话的结果一样，它们也会引发关于用户需求的持续对话。为了让一个故事准备好开始开发，你仍然需要：

• 添加接受准则

测试人员将使用哪些标准来确保产品是正确构建的： * 定义开发任务，这些任务将指导团队编码应用；以及 * 根据需要补充用户故事、过程流程图、表格、草图和设计对比，以便清楚地向开发团队传达期望。

定义和沟通需求是一项团队合作的工作，用户故事可以帮助团队共同实现这一目标。如果你还不知道从哪里开始，可以参考Baklib的敏捷 coaching, facilitated 和工作坊，它能为你指明方向。