用户故事指南

用户故事的目标不仅是记录需求，还要提供客户在生产中使用的工作软件。用户故事提供了一种机制，用于记录客户和开发人员之间关于软件功能的讨论。

定义

“用户故事代表卡中的客户要求，导致对话和确认。” 〜罗恩杰弗里斯

模板

以下是用于定义用户故事和验收标准的众所周知的模板。

价值陈述：作为（用户角色），我想（活动），以便（业务价值）

接受标准：给定（上下文），何时（执行行动），然后（可观察的后果）

一般准则

以下是编写用户故事时要考虑的一些通用准则：

• 用户故事有三个方面：卡片，对话和确认（Ron Jeffries 2001）
• 用户故事应表示对用户或系统所有者有价值的功能。
• 用户故事应描述单个功能。
• 用户故事应该有一个注释部分，其中记录了有关用户故事详细信息的对话。
• 用户故事应该在故事点中具有估计（成本），其表示大小和复杂性。
• 用户故事应根据其对客户的价值进行优先排序。

良好用户故事的属性（INVEST）

Mike Cohn在他的“用户故事应用”一书中指出了一个好的用户故事的六个基本属性。这些是：

独立的（Independent）

• 用户故事应该不依赖于其他用户故事。
• 用户故事应该是自包含的。
• 用户故事应按任何顺序完成和发布。
• 当发生依赖关系时，应该以不同的方式组合或拆分用户故事。

可面议（Negotiable）

• 用户故事不应该是合同义务，因为它们是可以协商的。
• 用户故事应该是客户，开发人员和测试人员之间的协作谈判。

有价值的（Valuable）

• 用户故事应该对软件的用户或所有者有价值。
• 用户故事不仅仅对开发人员有价值。
• 用户故事应明确定义客户/用户的利益，以帮助确定优先级。
• 用户故事应由客户编写，以确保其对客户/用户有价值。

可估计（Estimable）

• 用户故事应根据故事点进行估算。
• 在开发团队估计用户故事之前，应该清楚地理解用户故事。
• 在开发团队估算之前，用户故事应包含足够的详细信息。
• 当开发团队缺乏领域知识时，用户故事可能无法估计。
• 当开发团队缺乏技术知识时，用户故事可能无法估计。
• 当用户故事太大时，用户故事可能无法估计。

小的（Small）

• 用户故事应该尽可能小，同时仍然提供用户价值。
• 用户故事应该能够适合一次迭代。
• 对于大的用户故事将难以理解和估计。

可测试的（Testable）

• 应通过测试验证用户故事，以证明它们已正确实施。
• 用户故事应包含指导测试的故事接受标准。
• 用户故事应该很容易进行单元测试。（技术实施）
• 用户故事应该很容易接受测试。（行为的）
• 用户故事应尽可能以自动方式进行测试。

故事点规划

• 改进的Fibonacci（0,1 / 2,1,2,3,5,8,13,20,40,100）
• T恤（xxs，xs，s，m，l，xl，xxl，）

完成（DoD）的定义

团队可以使用许多标准来定义他们的“完成定义”。这可确保团队提供在功能和质量方面完成的功能。Done的定义是可审核的核对表。以下是国防部的一系列可能标准和活动：

• 单位测试通过
• 接受标准达成
• 代码已审核
• 通过功能测试
• 非功能性要求
• 产品负责人接受用户故事

用户故事示例

以下是用户故事的示例。

参考

• 科恩，迈克。用户故事应用：敏捷软件开发。第1版，Addison-Wesley Professional，2004年。
• Wake，William C. Extreme Programming Explored。Addison Wesley，2002。