“用户故事”在交互设计中，常常用于分析用户遇到的问题、所在的场景，帮助设计师增强对用户的同理心，将焦点收敛于问题本身。在用户故事地图中，“用户故事”的内含和使用方法是否相同？它是体现于哪种形式，从而被团队更好的使用？它需要如何被组织，从而形成“地图”？这一篇文章，将会解决以上问题——开始认识“用户故事”。
一、用户故事
是指用户来描述用户渴望获得的功能，是具有一定价值的端到端交付。它包括三个部分：角色、用户需求、产品价值。我们常常使用一句话来描述用户故事，某<角色>，通过完成<用户需求>，实现<产品价值>。
“用户故事”源于1996年Kent Beck提出的极限编方法（《Agile Development》，中译名《敏捷开发的艺术》）。在2004年，敏捷大师Mile Cohn在《User Stories Applied For Agile Software Development》(中译名：《用户故事与敏捷方法》)一书中，正式定义“用户故事”这一概念，并提出著名的“INVEST”特点。而本系列文章，则是来自于2014年出版的的又一著作《用户故事地图》。今天，无论是Scrum还是看板，用户故事都作为需求的基本形态被广泛运用。
传统需求中，只描述具体要做的内容，如果遇到想得多的产品人员，还会直接罗列出详细方案。这对于项目团队（不同知识结构、不同思维方式）而言，在短期内搞清楚要做什么是很困难的。用户故事除了需求内容外，还加入了“谁”、“为什么”，这样便于成员在同一频道内对话——大家都从用户角度沟通，利于对内容达成共识。
值得一提的是，用户故事还是敏捷开发的前提和基础。我曾遇到过的项目，将长周期切分为短周期，以此来加快进度，但这并不是敏捷。压力最终还是落在团队上，而每个阶段没有成型的交付物，也无法阶段性查验方案的适用性，最终最还是全部上线后验证效果。我曾疑惑其中的关节，通过对用户故事的学习，我有了深刻的了解：
- 如果不是基于用户故事开发，简单地把项目的长周期拆分成短周期并不是真正的迭代，因为每个周期都没有可体验、可交付的东西，依然像瀑布一样在不断堆积半成品；
- 如果不是基于用户故事开发，测试驱动开发（TDD）和行为驱动开发（BDD）很难开展，因为缺乏具体用户场景的描述，很难写出具体、简明的测试用例，因而很难累积足够的自动化测试提高系统的可改性，内部质量、重构、持续优化便无从谈起；
- 如果不是基于用户故事开发，持续集成（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
下一篇内容，用户故事地图的创建方法。
网友评论