什么是用户故事？

什么是用户故事？

用户故事是一条记录，用于捕捉一个用户在工作过程中所做的事或需要做的事。每个用户故事都包含一段从用户视角出发、使用自然语言编写的简短描述。与传统的需要捕获方式不同，用户故事关注的是用户的需求，而非系统应交付的内容。这为解决方案的进一步讨论留下了空间，从而实现真正契合客户业务流程的系统，解决其运营问题，并最重要的是为组织创造价值。

3C原则

3C指的是良好用户故事的三个关键方面。这一概念由用户故事实践的共同发明者罗恩·杰弗里斯提出。如今，当我们谈论用户故事时，通常指的是由这三个方面构成的用户故事。

1. 卡片 – 用户故事以卡片形式书写。每张用户故事卡片包含一句简短的语句，内容足够提醒所有人该故事的主题。
2. 对话 – 需求通过客户与开发团队在整个软件项目期间持续不断的对话来发现和细化。重要想法和决策将在利益相关者会议中被发现并记录下来。
   
3. 确认 – 也称为用户故事的验收标准。在需求讨论过程中，客户不仅告诉分析师自己想要什么，还确认在何种条件和标准下，可工作的软件将被接受或拒绝。所定义的案例以确认形式记录下来。请注意，确认关注的是验证对应用户故事工作的正确性，而非集成测试。
   

如何识别用户故事？

用户故事应与利益相关者共同识别，最好通过面对面会议进行。用户故事是一种需求发现过程，而非预先的需求分析过程。在传统的需求数量捕获方法中，系统分析师试图理解客户的需求，然后详细制定系统的需求规格。而用户故事方法并非如此。与文档化过程不同，用户故事的识别更像是一种笔记记录过程。通过与用户的讨论，我们倾听并理解他们的问题和需求，同时将这些需求记录为用户故事。这些用户故事将成为需求的来源。细节可以在后续的开发过程中及时补充，为团队在整个项目开发过程中提供“恰到好处”的需求参考。

通过用户故事映射业务流程

BPMN是业务分析与建模中最强大的工具之一。我们不仅可以利用它进行流程优化，还可以通过以下步骤从计划自动化的流程中识别用户故事：

1. 简单地使用BPMN业务流程图来建模用户的流程。
2. 与用户一起走查流程模型。
3. 然后分析问题中的业务活动，识别与需要自动化的流程相关的用户故事，这也被称为业务流程到用户故事的映射。

如何编写用户故事？

编写用户故事时，尽量以用户的口吻来写，格式如下（或至少确保你所写的内容符合以下陈述）：

作为一个<角色>，我希望<业务目标>，以便<业务价值/原因>。

例如：作为一个客户，我希望在物品到达时收到一条短信以便我可以去取一下.

在哪里：

1. <角色>代表将与待实现系统进行交互以达成目标的个人、系统、子系统或任何其他实体。通过与系统的交互，他或她将获得价值。
2. <业务目标>代表用户通过与系统交互可以实现的期望。
3. <业务价值>代表与系统交互背后的真正价值。

这并非一条规则，而是一种指导方针，帮助你通过考虑以下几点来思考用户故事：

1. 用户故事将为某人或特定方（例如客户）带来价值。
2. 用户故事满足了用户的需求（例如，物品到达时收到短信）
3. 有理由支持实现这个用户故事（例如，客户可以去取她购买的商品）

每个用户故事都应为某人带来价值。但有时，仅通过阅读业务目标就能明显看出价值。将价值写入陈述中会显得繁琐。在这种情况下，我们将直接省略。以下是几个例子：

作为一名客户，我希望可以通过信用卡完成支付以便我可以在网上购物时使用信用卡.

作为一名用户，我希望可以通过输入朋友的名字进行搜索以便我可以通过名字找到我的朋友.

无论你如何撰写用户故事，都必须牢记两点：第一，用户故事必须从用户的角度出发撰写；第二，保持描述“恰到好处”。在软件项目初期避免添加过多细节。之后你将有机会对用户故事进行细化和完善，使其成为开发人员在设计和实现过程中可以使用的具体内容。

用户故事的生命周期

从广义上讲，每个用户故事在整个软件项目中会经历六个主要状态：

1. 待办 – 通过用户与项目团队之间的沟通，发现用户故事。在此状态下，用户故事仅包含对用户需求的简短描述。尚未进行详细的需求讨论，没有系统逻辑，也没有界面设计。事实上，目前用户故事的唯一作用，只是提醒各方在未来讨论该用户故事（卡片）中所写的需求。未来有可能会放弃该用户故事。
2. 待办 – 通过不同利益相关方之间的讨论，决定接下来几周需要处理的用户故事，并将其放入一个称为“冲刺”的时间箱中。这些用户故事被称为处于“待办”状态。在此状态下尚未进行详细讨论。
3. 讨论中 – 当用户故事处于“讨论中”状态时，最终用户将与开发团队沟通，以确认需求并定义验收标准。开发团队会将需求或任何决策以对话记录的形式记录下来。用户体验专家可能会创建线框图或故事板，让用户通过视觉原型预览所提议的功能，并感受其效果。这一过程被称为用户体验设计（UX设计）。
   
4. 开发中 – 在需求明确后，开发团队将设计并实现功能以满足用户的需求。
5. 确认中 – 开发团队完成用户故事后，将由最终用户进行确认。用户将获得测试环境或半成品软件产品（有时称为 alpha 版本）的访问权限，以确认该功能。确认将基于编写用户故事时列出的确认项进行。在确认完成之前，该用户故事被视为处于确认中状态。
6. 已完成 – 最终，功能被确认已完成，该用户故事被视为已完成状态。通常，这是用户故事的终点。如果用户有新的需求，无论是关于新功能，还是对已完成用户故事的改进，团队将在下一次迭代中创建新的用户故事。

编写用户故事——何时以及为何？

使用户故事区别于传统需求收集方法的一个关键点是，用户故事方法将问题和解决方案的识别分为两个步骤，分别在软件项目的不同阶段进行。虽然问题和对用户需求的初步理解在软件项目初期就被发现，但系统需求的详细内容仅在设计和实现开始前才确定。这种安排具有以下优势：

1. 能够及时响应最新的用户需求，因为需求是在实施前才详细确定，而不是在项目初期就全部确定。
2. 更容易识别正确的需求，因为问题和解决方案都将经过详细讨论。在传统方法中，由于所有需求的细节必须在项目初期就确定，而“前期需求”可能随时间发生变化，导致大量分析工作被浪费。
3. – 另一方面，发现无效的用户故事可以轻松丢弃，你不会在前期研究和文档编写上浪费太多时间。

如何有效使用用户故事？

与许多其他软件开发方法类似，如果你在软件项目中正确应用用户故事，将能够交付高质量的软件系统，并赢得客户的信任与满意。使用用户故事时，需要注意以下几点：

1. 保持用户故事描述简短。
2. 编写用户故事时，要从最终用户的角度思考。
3. 一个（UML）用例代表一个业务目标。将用户故事归类到用例下，可以确保每个用户故事满足一个业务目标，换句话说，它们共享相同系统目标。它作为占位符，帮助你更有效地管理、安排和优先处理用户故事。
4. 确认项必须在开发开始前定义
5. 在实施前估算用户故事，以确保团队的工作量在可控范围内。
6. 需求应与最终用户共同确定，而不是由最终用户或开发团队单独决定。与最终用户保持良好关系，对双方都是双赢。
7. 沟通在理解最终用户需求方面始终至关重要。

Visual Paradigm 提供您在 敏捷软件开发 中所需的所有工具，包括 UML 用例图工具 , （敏捷） 用户故事 , 迭代 , 故事板 和 线框图 用于用户体验设计，任务管理工具，等等