用户故事地图（3）：故事与卡片

“用户故事”在交互设计中，常常用于分析用户遇到的问题、所在的场景，帮助设计师增强对用户的同理心，将焦点收敛于问题本身。在用户故事地图中，“用户故事”的内含和使用方法是否相同？它是体现于哪种形式，从而被团队更好的使用？它需要如何被组织，从而形成“地图”？这一篇文章，将会解决以上问题——开始认识“用户故事”。

一、用户故事

是指用户来描述用户渴望获得的功能，是具有一定价值的端到端交付。它包括三个部分：角色、用户需求、产品价值。我们常常使用一句话来描述用户故事，某<角色>，通过完成<用户需求>，实现<产品价值>。

“用户故事”源于1996年Kent Beck提出的极限编方法（《Agile Development》，中译名《敏捷开发的艺术》）。在2004年，敏捷大师Mile Cohn在《User Stories Applied For Agile Software Development》(中译名：《用户故事与敏捷方法》)一书中，正式定义“用户故事”这一概念，并提出著名的“INVEST”特点。而本系列文章，则是来自于2014年出版的的又一著作《用户故事地图》。今天，无论是Scrum还是看板，用户故事都作为需求的基本形态被广泛运用。

传统需求中，只描述具体要做的内容，如果遇到想得多的产品人员，还会直接罗列出详细方案。这对于项目团队（不同知识结构、不同思维方式）而言，在短期内搞清楚要做什么是很困难的。用户故事除了需求内容外，还加入了“谁”、“为什么”，这样便于成员在同一频道内对话——大家都从用户角度沟通，利于对内容达成共识。

值得一提的是，用户故事还是敏捷开发的前提和基础。我曾遇到过的项目，将长周期切分为短周期，以此来加快进度，但这并不是敏捷。压力最终还是落在团队上，而每个阶段没有成型的交付物，也无法阶段性查验方案的适用性，最终最还是全部上线后验证效果。我曾疑惑其中的关节，通过对用户故事的学习，我有了深刻的了解：

1. 如果不是基于用户故事开发，简单地把项目的长周期拆分成短周期并不是真正的迭代，因为每个周期都没有可体验、可交付的东西，依然像瀑布一样在不断堆积半成品；

2. 如果不是基于用户故事开发，测试驱动开发（TDD）和行为驱动开发（BDD）很难开展，因为缺乏具体用户场景的描述，很难写出具体、简明的测试用例，因而很难累积足够的自动化测试提高系统的可改性，内部质量、重构、持续优化便无从谈起；

3. 如果不是基于用户故事开发，持续集成（CI）也意义不大，因为提交的代码并没有构成可交付的产品，其实并没有真的在集成。

——《把项目拆分成用户故事才是硬本领》

二、用户故事的标准原则

《用户故事地图》中，介绍了一个好的用户故事所应该具备的特性：3C原则。

3C原则

3C原则是由Ron Jeffries提出的。它包括三个部分：

卡片（Card）

用卡片（Card）来简要描述软件特性或改进点。

• 描述的内容简洁、词汇含义统一，项目成员不会对同一内容有差异性理解；

• 这些卡片用于后续的沟通、对需求内容的组织和排列优先级；

交谈（Conversation）

与Product Owner（或客户）交谈来明确细节。

• 卡片的内容是由团队在沟通中获得，而非由同一个人输出或更新的，不然它与传统的需求分析方法无异；

• 项目成员需要一起就卡片内容进行讨论。在复杂逻辑中，梳理出清晰的需求脉络，并在这一过程中，达到共识和理解的统一。

确认（Confirmation）

每个故事应具有验收标准（验收条件），能够确认被正确完成。

• 以始为终，先行确认以怎样的结果，来判断开发任务的完成；

• 它保证每个故事都是独立的、完整的逻辑，可以单独交付；

• 它为驱动测试驱动开发、行为驱动开发和持续集成提供可能。

INVEST原则

INVEST是另外一项好的用户故事的标准，在敏捷社区中广为人知。INVEST的出现早于3C原则。《用户故事地图》中并非介绍这一原则，此处做为补充写在此处。

INVEST是六个单词的缩写，即：

• 独立性（Independent）：最好用户故事不要彼此依赖。

• 可协商（Negotiable）：故事卡片是一种提醒，团队成员应该基于此对话，而不是把故事卡片看做确定性的需求。

• 具有外部价值（Valuable）：避免仅仅对开发人员有价值的故事。

• 可估计（Estimatable）：用户故事规模适中，对应的业务知识和技术知识得到澄清，从而可以估计用户故事的规模。

• 小（Small）：即将开发的用户故事应该足够小，从而能便于迭代、便于调整优先级，便于需求澄清，等等。

• 可测试（Testable）：可测试的故事意味着需求是清晰、可验证的。

三、用户故事卡片

用户故事的实际截体是卡片，那么一张小小的卡片（物体、电子），在项目的不同阶段记载的内容是否异同？针对不同体量、复杂度的项目，卡片上的内容和作用是否相同？

需求讨论前期

项目开始阶段，用户故事卡片主要作用在于引导讨论，从复杂的需求逻辑中找到清晰的脉络，并在项目中形成共识。因此，此时的用户卡片讲求表述简单，具体如下：

1. 形式上，以动词开头的简短标题

用户故事一般为一句话，以动词开头，主语默认是用户A。用户A的信息，会在用户故事地图中统一标识。用户故事以为讨论中可以轻松说出为准，内容要准确，不能让疑惑。

2. 内容上，包含3W信息

• who：满足谁的需求

• what：用户会用产品做什么

• why：用户期待从中获得什么收益

需要注意的是，切忌从自己的角度来写故事；用户故事是一句长长的话，啰哩啰嗦。

需求讨论后期

项目讨论的后期阶段，项目成员以就需求达成共识，并且各自评估出难标准、时间、优先级后，可以需求中补充以下内容：

序号	内容	说明
1	需求索引编号	帮助与详细的需求说明文档关联起来，便于按图（卡片）索骥（需求）
2	开发周期	估算值
3	优先级	可用数字表达，也可以用“高/中/低”表达
4	验证指标	已在上文中说明
5	依赖	依赖或需要一起发布的其他故事
6	状态	可以包括“未启动/进行中/已完成”等
7	日期	创建、启动、完成的日期

在这里说明一点，在大型、高复杂度的项目中，故事卡只是索引，详细内容是录入系统中的，故事卡帮助我们更好的的找到这些内容。用户故事地图并不是在驳斥需求文档，二者并非是二选一的关系。需求文档的“无大局视角”、“信息传递成本高”等缺点，可以使用用户故事地图来解决。若项目相对较小、内容不多。那么使用用户故事地图直接来补充详细的需求内容，也是可以的。

—— end ——