用户故事(User Story)

一、什么是用户故事

用户故事描述了对用户、系统或软件购买者有价值的功能。一个好的用户故事包括三个要素：

1.角色：谁要使用这个功能。

2.功能：需要完成什么样的功能。

3.价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：

英文：As a , I want to , so that .

中文：作为一个<角色>, 我想要<功能>, 以便于<商业价值>

举例：“作为招聘网站注册用户，我想要查看最近3天发布的招聘信息，以便于我看到最新的招聘信息”。

由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries(2001)对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。

卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。

交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。

确认（Confirmation）：通过验收测试确认用户故事被正确完成。

 

二、如何编写用户故事

故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户团队来编写故事。客户团队应包括能确定软件最终用户需求的人，可能包括测试者，产品管理者，真实用户和交互设计师。因为他们处于描述需求的最佳位置，也因为随后他们需要和开发者一同设计出故事细节并确定故事优先级。

为了构造好的用户故事，我们关注六个特征。一个优秀的故事应该具备以下特点：

独立的（Independent）— 我们要尽量避免故事间的相互依赖。在对故事排列优先级时，或者使用故事做计划时，故事间的相互依赖会导致工作量估算变得更加困难。通常我们可以通过两种方法来减少依赖性：1.将相互依赖的故事合并成一个大的、独立的故事；2.用一个不同的方式去分割故事。

可讨论的（Negotiable）— 故事卡是功能的简短描述，细节将在客户团队和开发团队的讨论中产生。故事卡的作用是提醒开发人员和客户进行关于需求的对话，它并不是具体的需求本事。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。

对用户或客户有价值的（Valuable）— 用户故事应该很清晰地体现对用户或客户的价值，最好的做法是让客户编写故事。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。

可估算的（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：1.开发人员缺少领域知识；2.开发人员缺少技术知识；3.故事太大了。

小的（Small）— 一个好的故事在工作量上要尽量小，最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。

可测试的（Testable）— 故事必须是可测试的。成功通过测试可以证明开发人员正确地实现了故事。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：用户必须觉得软件很好用。

三、用户角色建模

在很多项目中，需求分析人员只是从一个角度编写用户故事，这样往往容易忽略一下需求(故事)。所以在编写用户故事前识别用户角色和虚拟人物(Persona)有很多好处。

以下是招聘网站可能出现的用户角色列表：

角色建模的步骤：

1.通过头脑风暴列出初始的用户角色集合：每个人要做的只是尽量在卡片上写出自己想到的角色。

2.整理最初的角色集合：对于有重叠的角色，把它们相应的卡片重叠在一起。

3.整合角色：在角色分组完成后，试着整合及浓缩角色。

4.提炼角色：一旦我们整合好角色，并且对角色之间的关系有了一个基本的了解，就有可能通过给每个角色定义一些特征来建立角色的模型。

虚拟人物，可以考虑一两个主要的用户角色写下虚拟人物定义，从虚拟人物的角度描述会使故事变得更加生动。

四、如何搜集故事

用户需求并不容易得到，因为用户并不知道所有的需求，所有不能单靠用户给我们解释需求。Robertson 和 Robertson(1999)引入了拖网(trawling)这个词来描述收集需求的过程，要像“拖网渔船捕捞鱼”那样来收集需求。

首先，不同大小的网用来捕获不同大小的需求。第一遍，我们可以用大网眼的渔网捞一遍需求池，以此得到所有的大需求。通过这些大需求，形成对软件的整体感觉。接下来，用网眼稍微小一些的渔网得到中等大小的需求。

其次，需求会像鱼一样，会成长，也可能会死亡。今天渔网可能会漏掉一个需求，因为这个需求对于系统来说不重要。但是，根据每轮迭代的反馈，系统会朝着事先不可预知的方向发展，有些需求会变得越来越重要。

第三，在某一区域拖网捕鱼不可能捕获到所有的鱼，我们也不可能捕获所有需求，也可能捞到一些废弃的货物或漂浮的残，这会使需求膨胀。

最后，技能也是发现需求的一个要素，一个熟练的需求分析人员知道要到哪里去找需求。

故事会随着项目的进展而演进，所以我们可以通过用户访谈、观察用户、问卷调查和举办故事编写工作坊来发现用户故事。另外通过开放式、与背景无关的提问更容易获得有用的答案，例如：“告诉我你想怎么搜索工作？”就胜于“你要通过职位名称来搜索工作吗？”

五、与用户代理合作

对于一个项目来说，客户团队里包括一个或多个真实用户是极其重要的。但是但我们无法接触到他们时，我们就需要求助于用户代理(User Proxy)，选择合适的用户代理对于项目的成功至关重要。

用户的经理：如果用户的经理不是软件的实际用户，并从中干预产品功能的开发。这种情况下，务必小心，不要得罪该用户经理，在部分围绕她的同时，想办法接触终端用户。

开发经理：让开发经理担任用户代理，是最坏的选择之一，除非你们开发的软件就是给开发经理用的。

销售人员：让销售人员充当用户代理是危险的，这会让大家对正在开发的产品没有一个全面的蓝图。然而，销售人员是非常好的中转站，应该让他们通过电话或销售拜访把你介绍给客户。

领域专家：领域专家很适合做用户代理，但要避免最终开发出来的软件仅仅针对那些与领域专家有类似水平的用户。

市场营销团队：他们可能更关注软件特性的数量而不是质量。他们可以为相关故事的优先级提供高层次的指导意见，但他们往往不具备很好的洞察力，无法给提供故事的具体细节。

以前的用户：应谨慎考虑她的目标和动机是否与实际用户的完全一致。

客户：考虑客户的期望是很重要的，因为开支票买软件的人是他们，而不是用户。

培训师和技术支持：由培训师和技术支持人员来充当用户代理看似是合乎逻辑的，不幸的是，他们做用户代理，你的系统最终将只成为一个易于培训系统或只是使得技术支持工作变得较为容易，而不是功能最大化服务于最终用户。

业务分析师或系统分析师：许多业务和系统分析师是很好的用户代理。他们唯一缺点是遇到问题喜欢空想，偶尔会在项目前期花太多时间做产品计划。

与用户代理合作时，做些什么？

1.能接触到用户但访问受限时：最好可以申请由部分用户组成一个用户顾问团队。

2.实在不能接触到用户时：必须求助于用户代理；如果有竞争产品，也可以用其做一些故事的来源。

3.避免陷入思维的误区：知道用户的想法，所以不需要或可以忽略用户代理。

六、用户故事验收测试

编写验收测试有很多好处，其一就是很多客户和开发人员讨论的细节可以通过验收测试记录下来。测试的要点记录了客户提出的一些假设，也提供了确认故事是否被完整实现的基本标准。

在写代码之前写测试

考虑每个故事，然后问类似下面的一些问题：

1.关于这个故事，程序员还需要知道什么？

2.对怎么实现这个故事，我的想法是什么？

3.有没有一些特殊情况会使这个故事有不一样的行为？

4.这个故事在什么情况会出错？

客户定义测试

客户可以和程序员与测试人员合作创建测试，但客户至少应该给我们详细指出一些测试，用以验证故事的实现是正确的。

测试是过程的一部分

测试时开发过程中的一部分，这点对使用用户故事非常重要。一般情况下，产品经理和测试人员共同负责列出详细的测试。产品经理带来驱动项目的公司目标的知识；测试人员则带来怀疑的心态。

多少测试才算多？

只要这些测试还在继续为故事增加价值和使它更加清晰，客户就应该继续写测试。同时，一个优秀的开发团队会为很多详细的用例编写单元测试。

集成测试框架

客户负责引领系统的开发。同时，在每轮迭代时都执行以往迭代的所有测试时非常重要的，开发团队应该自动化部分或全部验收测试。FIT和FitNesse是写验收测试的优秀工具。

测试类型

测试类型有很多，故事测试主要是功能性的测试，用来确定应用程序是如期运行的。

七、优秀的用户故事准则

优秀用户故事的一些准则：

1.试着让故事的大小能够在使用后让用户感到可以去喝杯咖啡休息一下；

2.不要让故事过早涉及用户界面；

3.实际编写故事时，要包括用户角色；

4.用主动语态编写故事；

5.为单个用户编写故事；

6.让客户编写故事，而不是开发人员；

7.用户故事要简短，它们只是提醒开发人员和客户进行对话；

8.不要给故事卡添加编号。

八、用户故事的估算

以故事点估算

用户故事通常用故事点来估算，故事点表明一个故事相对于其他故事的大小和复杂度。通常以理想工作日作为故事点的单位：相较于用连续时间估算，它更简单；相较于用完全模糊单位，它可使我们的估算拥有更好的依据。

以团队估算

故事估算应该由整个团队集体完成，团队大部分成员都参加估算是非常重要的。客户也可以参加，但是他不能提出他个人的估算或者在听到自己不赞成的估算时发表意见。

Wideband Delphi估算方法

与采用迭代方式进行开发软件的极限编程类似。最终目的是要为故事得到一个统一的估算值，这个迭代过程很少超过3轮。

三角测量

三角测试是帮助团队验证他们没有逐渐改变一个故事点含义的有效方法。

九、团队的速率

速率是每一轮迭代开发中能完成的工作量。一旦知道团队速率，就可以用它将理想日转换变成日历日。总故事点 / 团队的速率 = 需要的迭代次数。

初始速率

可以通过三种方法获得初始速率：

1.使用历史值

2.执行一轮初始迭代，使用那轮迭代的速率

3.猜测

测试速率

团队在在一轮迭代完成的故事点数的总和就是团队速率，不能将部分完成的故事也计算在速率中。用集中全部力量完成一个故事的方法会提高团队的意识：大家一起先完成一些故事比所有故事都只能完成一部分更有价值。

计划速率和实际速率

计算速率是用迭代开始前分配的故事点数，实际速率是迭代中实际完成的故事点书。计划速率与实际速率可能会出现偏差。

三、怎么拆分故事

当故事非常大时，我们将很难对它进行估计。如果故事预计在N次迭代后才进行，那么大的故事很正常。但如果估计预计在接下来的迭代中进行，那么我们就可能会对大的故事进行拆分。很大的故事基本上都能进行拆分，只要确定每个小故事都可以交付业务价值就行。注意在这里不要把故事拆分到任务，故事是可以交付的东西，是产品负责人所关心的，而任务是不可交付的东西，产品负责人对它并不关心，任务是在sprint计划会议上拆分的。

分割用户故事：

1. 按照用户故事所支持数据的边界来分割大型用户故事（例如导入GBQ文件、Excel等）。

2. 从主用户故事中除去对例外或错误条件的处理（相当于用户的基本路径和扩展路径），从而把一个大型用户故事变小许多。

3. 按照操作边界分割，把大型用户故事分割成独立的建立、读取、更新和删除操作（例如预算二次导入，或者新增时需要向导、规则而比较复杂时也可以单独成一个故事来描述）。

4. 考虑去除横切考虑（例如安全处理、日志记录、错误处理等），为用户故事建立两个版本：一个具备对横切考虑的支持，另一个不具备这种支持。

5. 考虑功能性需求和非功能性需求隔离到不同的用户故事，从而分割大型用户故事（性能）。

在拆分故事时，我们有时也需要考虑组合故事的场景，如把bug列入产品backlog时，可以把多个类似的bug组合成一个故事。

四、怎么评定优先级

最简单的方法就是问问客户最希望在下一个迭代中最想看到的是哪一些功能。从考虑的因素来看，我们可以从以下4个因素来考虑：

1. 获取这些功能带来的经济价值，价值越高的优先级越高。

2. 开发成本带来的影响。例如可能2个月后由于使用新技术只需要2周，而现在做需要2个月，这时可以考虑把优先级放低一些。

3. 获取新知识的重要性。在开发中会不断的产生一些项目和产品的新知识，及早了解和开发这些新知识可以减少不确定性，所以这类功能优先级会高些。

4. 故事之间会存在依赖关系，这时候被依赖的优先级会更高，需要先完成。

5. 开发这些功能所减少的风险。在开发过程中，会出现进度风险、成本风险、技术风险等，对于风险越高价值越大的我们需要首先处理，对风险高价值低的要尽量避免，可以通过以下图查看确定功能优先级时综合考虑风险和价值的关系。

五、怎么进行初始评估

对每个故事进行初始估计后就可以知道项目的规模。一般采用故事点来进行这类初始评估，可以通过扑克牌来进行，扑克牌点数一般有0、1/2、1、2、3、5、8、13、20、40、100、？、咖啡。首先由产品负责人对product backlog进行讲解，然后由Scrum master负责协调进行初始评估工作。敏捷估算中不是要估计绝对的时间，而是尽量确保故事之间的相对估计是准确的。由于估计是相对的，所以需要首先找打 一个基准，我们可以先找一个不是最小的，也不是最大的来作为一个基准，可以先找出一个大家认为适合分配为2点的故事。在找2点的故事时，很可能会出现大家 意见不一致的情况，这时就需要大家都分别说明自己的见解后再重新找。有了2点基准后，就可以对每个故事进行评估了，而后面的故事都可以基于以前的故事来进 行相对估计了。在估计过程中，有可能会出现大家对故事理解不一致，这时就需要返回去修改故事，确保大家理解一致。