用户故事摘要：3Cs 和 INVEST

本文旨在制定产品待办事项项目的“用户故事”方法，以及如何通过促进以用户为中心的开发方法来实现用户价值和产品整体质量的沟通。

用户故事摘要

用户故事的起源可追溯到极限编程（eXtreme Programming），这是另一种与Scrum有许多相似之处的敏捷方法。Scrum团队经常使用极限编程的各个方面，包括用户故事以及工程实践，例如重构，测试驱动开发（TDD）和结对编程等。在该计划的未来模块中，您将有机会熟悉其中一些实践，以了解它们在提供优质产品方面的重要性以及如何鼓励您的团队开发它们。目前，我们将专注于撰写优秀用户故事的能力。

用户故事 - 3C

用户故事有三个主要组件，每个组件以字母“C”开头：

卡 (Card)

卡片或用户故事的书面文字最好被理解为对话邀请。这是一个重要的概念，因为它有助于理解在Scrum中，在将它们带到团队之前，您不必将所有产品Backlog项目完全“预先”写出来。它承认客户和团队将在他们开展工作时发现所需的基础业务/系统。这一发现通过围绕用户故事的对话和协作来实现。
卡通常遵循类似于下面的格式

作为产品的< 用户角色 >，

我可以< 动作>

这样< 好处 > 。

换句话说，故事的书面文本，即对话的邀请，必须解决故事的“ 谁 ”，“ 什么”和“ 为什么 ”。
请注意，<benefit>应该是谁有两种思想流派。交互式设计专家（如Alan Cooper）告诉我们，一切都需要面向用户，而不仅仅是面向名称，照片，生物等的用户Persona。其他专家更关注业务解决方案的可测试性（如Gojko Adzic）说，这个好处应该直接解决明确的业务目标。想象一下，如果你能同时做到这两件事！您可以，这将在更高级的模块中进一步讨论。

会话

由产品负责人促成的协作对话涉及所有利益相关者和团队。
这是一次面对面的交谈。
对话是故事的真正价值所在，并且应该调整书面卡片以反映当前对该对话的共同理解。
这种对话大多是口头的，但最常见的是文档和理想的各种自动测试）。

确认

产品负责人必须确认故事已完成才能被视为“完成”
团队和产品负责人根据团队目前对“完成”的定义检查每个故事的“完成度”
可以为个别故事确定与当前“完成”定义不同的具体接受标准，但是团队必须很好地理解并同意当前的标准。所有相关的验收测试应处于通过状态。

INVEST

这个测试用于确定一个故事是否被很好地理解并准备让团队开始研究它是INVEST的首字母缩略词：

Independent - 独立

该解决方案可由团队独立于其他故事实施。应该期望团队尽可能地打破技术依赖 - 这可能需要一些创造性思维和问题解决以及重构等敏捷技术实践。

Negoiation - 面议

工作范围应该有一些灵活性，而不是像传统的要求规范那样固定下来。同样，该故事的解决方案并未由故事规定，并且对讨论和协作持开放态度，最终决定为开发团队保留技术实施。

Valuable - 有价值

所有人都应该清楚地理解故事的商业价值，即“为什么”。注意，“为什么”不一定需要从用户的角度来看。“为什么”可以满足客户的业务需求，而无需向最终用户提供直接，有价值的结果。所有故事都应与明确的业务目标相关联。这并不意味着单个用户故事本身就需要成为可销售的功能。

Estimable - 估计

团队应该很好地理解这个故事，以便能够估计工作的复杂性以及将故事作为潜在的可交付功能增量所需的努力。这并不意味着团队需要了解所有实施细节以便估计用户故事。

Small - 小

该项目应该足够小，以便团队可以在单个Sprint中提供潜在的可交付功能增量。实际上，这应该被视为任何Product Backlog Item允许的最大大小，因为它接近Product Backlog的顶部。这是产品Backlog改进概念的一部分，这是Scrum团队工作的一个持续方面。

Testable - 可测试

每个人都应该理解并同意如何验证故事的完成情况。“完成”的定义是建立这一点的一种方式。如果每个人都同意故事可以以满足单个Sprint中“完成”的当前定义的方式实现，并且“完成”的这个定义包括某种用户验收测试，那么故事可以被认为是可测试的。

注意：INVEST标准可以应用于任何产品Backlog项目，甚至是那些未写为User Stories的产品Backlog项目。

拆分故事：

有时用户故事太大而无法融入Sprint。分裂故事的一些方法包括：

按流程步骤拆分
按I / O通道拆分
按用户选项拆分
按角色/角色分割
按数据范围拆分

警告：不要按系统，组件，架构层或开发过程拆分故事，因为这会与团队对“完成”的定义发生冲突，并破坏团队在每个Sprint中提供可能可交付软件的能力。

人物角色

与用户故事一样，角色也是交互式设计的工具。人物角色的目的是为我们的用户提供精确的描述，以便我们可以开发描述他希望实现的内容的故事。换句话说，角色是我们故事中更加发达和具体的“谁”。我们制作人物角色越具体，它们作为设计工具就越有效。

我们每个虚构但具体的用户都应该拥有以下信息：

名称
占用
与产品的关系
兴趣和个性
照片

只有一个角色应该是主要角色，我们应该始终为主要角色建立。使用角色的用户故事卡将用户角色替换为角色：

< persona >

可以< 动作>

这样< 好处 > 。

Learning Visual Paradigm