用户故事驱动开发系列之一：初识用户故事

本文是用户故事驱动开发系列的第一篇，将简要的分享“什么是用户故事”。

用户故事驱动开发是敏捷开发的核心管理实践，本系列将从用户故事的来源，用户角色建模，用户故事的搜集，编写用户故事，用户故事的澄清与开发，用户故事的测试与验收等整个过程、多个维度进行探讨，力求给大家呈现出用户故事从“市场中来，到市场中去”的整个敏捷开发过程！

       既然是敏捷开发的实战篇，我们在整个历程中通过采用大家能够耳熟能详的“开发一个Android的Market市场Nearme网站”为例，为大家呈现出用户故事驱动开发的全貌。正如敏捷实践专家陈勇老师在探讨敏捷时所讲“无住于法，无住于空，非法，非非法”一样，本人的敏捷来源于对实践的思考，绝非普世之法，倘或能引起大家的思考，有一点点儿的收获，则善莫大焉！

 

一、什么是用户故事

       用户故事（User Story）是指敏捷开发中以站在用户角度，采用用户的语言编写的产品需求，它是一个简洁的、包含了对某类软件用户带来价值的书面描述。

 

二、用户故事的三要素：角色、功能、价值

     “作为……的角色，我希望……的功能，以便满足我……的需求（价值）。”这就是用户故事的三段论，也是“用户故事三要素”，初看似乎有些“八股”的味道，虽然不能对所有的故事开发人员一概而论，却是初期接触敏捷开发的用户故事需求编写人员的“良药”。

“用户角色，产品功能，价值”是用户故事简要三段内必须体现的三个要素。

【例 如】：作为一名游戏爱好者，我希望Nearme能够提供丰富的游戏供我下载，以便满足我在悠闲时光畅享游戏的乐趣。

 

三、用户故事的3C原则：卡片（Card）、对话（Conversation）和确认（Confirmation）

      “卡片“包含用户故事的一段书面文字描述，用来做计划或者开放的提示；而需求的细节要在”对话“中获得，就是精细化故事的细节是通过对话的澄清方式来实现的； “确认”部分记录了故事测试验收的细节，用于表达用户故事何时可以开发完成。我们知道，迭代开发中的用户故事通常是记录到一张卡片上的，这张卡片随着开发的进度进行方便的移动以体现出状态的转换，但是，正如上面那个Nearme的用户故事所讲，要理解游戏爱好者所希望的“丰富的游戏“，还需要开发人员与用户代表（UE人员）进行深度的沟通明确究竟有那些类别的游戏，通过哪些测试验收才达到可以发布的状态，也即是用户故事的确认开发完成。

 

四、用户故事的INVEST原则

          一个好的用户故事同时要符合INVEST原则，正如小时候写记叙文有“六要素“一样，INVEST原则分别是：

1. 独立（Independent）：用户故事必须彼此独立，低耦合；

 

2. 可协商（Negotiable）：故事卡必须用来提醒团队和干系人进行交谈而不是作为一个合同来使用；

 

3. 有价值（Valuable）：用户故事对用户或客户来讲必须是重要的，有价值的；

 

4. 可估算（Estimable）：开发团队必须能够估算创建用户故事所需的工作量；

 

5.规模适中（Small）：用户故事必须足够小以便可以在1轮（或最多2轮）迭代内完成；

 

6. 可测试（Testable）：用户故事必须写成可以被测试的(有足够的细节)。

 

     有关用户故事的INVEST原则会在后续的讨论中详细展开和举例，本文不做详细论述！