本部分重点要掌握如何着手识别、编写和测试自己的故事。
第一章 概览
软件需求是一个沟通过程。一般情况下，我根据手头的信息来做决策。你们也经常这么干。不要在项目开始时做一套包罗万象的决策，我们要把各个决策分散在项目过程中。为此我们要确保有一个获取信息的过程，越早越好，越频繁越好。用户故事由此应运而生。
什么是用户故事
用户故事描述了对用户、系统或者软件购买者价值的功能。由三个方面组成：
1、一份书面的故事描述，用来做计划和作为提示。（卡片 Card）
2、有关故事的对话，用于就具体话故事细节。(对话 Conversation )
3、测试，用于表达和编档故事细节且可用于确定故事何时完成。（确认 Confirmation）
卡片包含故事的文字描述，然而需求细节要在”对话“中获得，并在”确认“部分得以记录。
细节在哪里？
多个小故事远胜于一个庞大的故事，理想的情况下是所写的故事能够让一两个程序员花半天到两周时间完成代码和测试。如果一个故事很大，我们称之为史诗故事（Epic）。史诗故事可以分成两个或者更多小故事。
客户团队
客户团队中，包括确保软件满足用户需求的所有人，这意味着包括测试人员、产品经理、实际用户和交互设计师。
使用故事的过程是怎么样？
故事驱动的项目，最引人注目的是客户和用户在项目整个过程中全程参与。由客户团队来编写故事，而不是开发人员来编写故事，有两个原因，首先故事须用商业语言来写，不是技术语言，客户团队可以排列优先级，放入迭代和发布；其次，作为产品的构想者，客户团队所处的位置最适合描述产品的行为。
规划迭代和发布
一个发布由一个或多个迭代组成。发布规划指的是确定项目时间表和预期功能集合之间达到平衡。迭代规划涉及选择迭代包含的故事。在进行发布规划时，首先从排列故事的优先级开始，排列优先级时考虑以下几点：
1、大部分用户和客户对待特定特性的渴望程度。
2、小部分重要用户和客户对特定特性的渴望程度。
3、故事之间的关系。
排列优先级时，坚持客户组织利益最大化的原则。排列优先级时需要考虑他们的成本，故事的成本由开发者给出，每个故事用故事点来估计，故事点表明一个故事相对于其他故事的大小和复杂度。速率是开发人员在一轮迭代中完成的工作量，放入一轮迭代的故事估计总和不能超过事先开发人员预计的速率。
什么是验收测试？
验收测试用来验证实现的用户故事是否符合客户团队的期望。
为什么要变？
每一个用户故事代表一个独立的功能，即用户在一个单一环境中可能做的事情。用户故事变化的理由如下：
1、强调对话交流而不是书面沟通
2、可以同时被客户和开发人员理解
3、故事大写适合做计划
4、适用于迭代
5、鼓励推迟考虑细节，直到你非常清楚了解真正需求
第二章 编写故事
本章节关注故事的六个特性，一个优秀的故事应该具备以下特点：
1、独立的（Independent）
2、可讨论的（Negotiable）
3、对用户或客户有价值的（Valuable to Purchasers Users）
4、可估计的（Estimatable）
5、小的（Small）
6、可测试的（Testable）
1、独立的
要避免故事见相互依赖，解决依赖的办法：
将相互依赖的故事合并成一个大的、独立的故事
用一个不通的方式去分割故事
2、可讨论的
故事是可以讨论的，故事卡应该包括以下信息：
一两句短语，用来提醒开发人员和客户进行对话
一些注释，用以表明在对话中亟待解决的问题
3、对用户或客户有价值的
用户和客户是不通的，用户是使用软件的用户，客户是购买软件的人。最好的办法就是让客户来编写故事。
4、可估计的
对开发人员来说，能够估算故事的大小，或者把故事变为可用代码的时间量非常重要。一般导致故事不可估计的情况有：
缺少领域知识
缺少技术知识
故事太小了
5、小的
合适的故事大小最终取决于团队、他的容量及所使用的技术。通常会进行故事的分割、合并。
史诗故事通常分为以下两种：
复合故事（多个小故事组成）
复杂故事（本身就很大且不容易分解）
6、可测试的
故事必须是可测试的，成功通过测试可以证明开发人员正确的实现了故事。
第三章 用户角色建模
以用户为中心的设计和交互设计的规则，在编写故事前识别用户角色和虚构人物有很多好处。用户角色是一组属性的集合，这些属性刻画了一群人的特征以及这群人与系统可能的交互。针对不同用户角色的故事之间会有些重复。
角色建模的过程：
1、通过头脑风暴，列出初始的用户角色集合
2、整理最初的角色集合
3、整合角色
4、提炼角色
1、通过头脑风暴，列出初始的用户角色集合
对项目角色进行头脑风暴时，要坚持“已确认的角色代表的是单一用户”的原则。
2、整理最初的角色集合
用户角色定义的是人而不是其他外部系统
3、整合角色
合并重叠的角色，丢弃对系统成功不太重要的角色
4、提炼角色
大部分小组只考虑单一的用户类型，这回导致忽略原本需要的一些用户类型。
为了避免从单一用户的角度编写所有的故事，要识别与软件交互的不通用户角色。对于有些用户角色而言，用代表人物来描述会很有帮助。虚构人物是假想出来的用户角色代表，极端人物可能有助于搜索原本遗漏的故事。
第四章 搜集故事
如何和用户一起工作，如何通过与他们沟通来发现故事。
这里介绍拖网捕鱼的三点描述和比喻：
拖网捕鱼是指拖网渔船捕捞鱼。
不同大小的网用来捕获不同大小的鱼，大网先捞取大鱼，比如需求，先得到大需求，形成整体感觉。
再用网眼稍小点的网得到中等大小的鱼，比如需求就是中等的需求。
渔网不可能捕获所有的鱼，会漏掉鱼，比如需求像鱼一样，会成长，会死亡。
捕鱼的时候还可能会捞到一些垃圾，在需求上比喻需求膨胀，范围蔓延。
拖网捕鱼的比喻是非常有用的，它说明了需求有不同的大小，需求会随着时间的推移变化，需要一些技巧来发现需求。
创建故事的最有效方法：
1、用户访谈
2、问卷调查
3、观察
4、故事编写工作坊
1、用户访谈
用户访谈是许多团队用来获取故事的默认方法，成功的关键是选择正确的受访者。获取用户的本质需求，最好的技巧是提问。（开放式问题和背景无关的问题）
2、问卷调查
问卷调查是一种有效的方法。
3、观察
观察用户实际使用软件的情况。
4、故事编写工作坊
故事编写工作坊是开发人员、用户、产品客户和其他对编写故事有帮助的人共同参加的会议。良好的故事编写工作坊结合了头脑风暴的最佳要素和简单原型法。
第五章 与用户的代理合作
我们期望尽可能多的接触用户，用户代表了产品的不同角度，当无法接触到他们时，就需要求助于用户代理。合适的用户代理对于项目的成功至关重要。
可能的用户代理：
用户的经理
开发经理
销售人员
领域专家
市场营销团队
以前的用户
客户
培训师和技术支持
业务分析师或系统分析师
本章学习不同类型的用户代理，讨论了编写用户故事时，为什么用户代理不如实际用户理想。除非用户的经理也是用户，否则他就不是合适的用户代理。开发经理会视图担任用户代理，因为他们已经参与到项目每天的细节中，而开发经理大多不是正在开发软件的用户，所以开发经理不是理想的用户代理。在产品公司里，客户经常来自于市场团队，他们是不错的用户代理，单他们通常关注软件的功能数目，而不是其质量，这点需要克服。销售人员是很好的开发项目客户，须要避免把重点放在那些可以重新赢得已失去订单的故事上。领域专家是很好的用户代理，需要避免把产品开发成只适合那些鱼他们有相同水平的人使用。客户能成为非常好的用户代理，如果客户是用户，那就是完美的组合。培训是和技术支持人员需避免仅仅关注产品中那些他们每天关心的方面。
和用户代理一起工作的方法：
- 用户顾问团队的使用，
- 使用多个用户代理，
- 分析竞争产品，
- 尽早发布软件来获取用户反馈。
第六章 用户故事验收测试
测试一个两步流程：
- 将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录到故事卡的背面；
- 将测试要点变成全面的测试，这些测试可以用来掩饰故事已正确、完整地实现。
开始编写故事代码之前，验收测试可以为程序员提供大量有用的信息。验收测试由客户来定义。测试是开发过程中的一部分，而不是在编码完成后要做的事。
- 验收测试可以用来记录客户和开发人员讨论的很多细节
- 验收测试记录了有关故事的一些假设，这些假设可能还没有和开发人员讨论过
- 验收测试提供了检查故事是否被完整实现的基本标准
- 验收测试应该有客户来写而不是开发人员
- 验收测试应在程序猿写代码之前就写好
- FIT和FITNesses 是写验收测试的优秀工具。
第七章 优秀用户故事准则
编写优秀故事的准则：
从目标故事开始
切蛋糕
编写封闭的故事
卡片约束
根据实现时间来确定故事规模
不要过早涉及用户界面
有些需求并不是故事
在故事里包括用户角色
只为一个用户编写
以主动语态编写
由客户编写
向故事卡编号说”不“
不要忘记意图
网友评论