- 1.1 什么是用户故事4
- 1.3 “必须多长时間完成？
- 1.5 使用故事的过程是怎么样的
- 1.6 规划发布和迭代
- 1.7 什么是验收测试？…
- 第 2 章编写故事15
- 2.3 对用户或客户有价值的 18
- 2.8 开发人员职责。25
- 3.4 如果有现场用户该如何？.35
- 3.6 开发人员职责35
- 4.1 引出和捕捉是不合用的 37
- 4.2 够用就行，不昰吗.38
- 第 5 章与用户代理合作
- 5.5 市场营销团队50
- 5.8 培训师和技术支持 52
- 5.9 业务分析师或系统分析师 52
- 5.10 与用户代理合作时，做些什么..52
- 能接触到用户但访问受限时。52
- 实在不能接触到用户时 53
- 第 6 章用户故事验收测试 57
- 6.1 在写代码之前写测试58
- 6.2 客户定义测试。59
- 6.3 测试是过程的一部分.59
- 6.4 哆少测试才算多？
- 6.5 集成测试框架60
- 6.8 开发人员职责。62
- 第 7 章优秀用户故事准则 63
- 7.3 编写封闭的故事。.64
- 7.5 根据实现时间来确定故事规模.65
- 7.6 不要过早涉及用户界面。,66
- 7.7 有些需求并不是故事67
- 7.8 在故事里包括用户角色。67
- 7.9 只为一个用户编写.68
- 7.12 向故事卡编号说“不”。68
- 第 8 章估算用户故事.3
- 8.6 如果用结对编程呢？77
- 9.1 我们想在什么时候发布 8
- 9.2 希望在发布中包含哪些功能..82
- 9.6 根据架构需要安排优先级。85
- 9.8 从故事点到预计工期86
1.1 什么是鼡户故事？4
用户故事描述了对用户、系统或软件购买者有价值的功能用户故事由以下三方面组成
- 一份书面的故事描述，用来做计划和作為提示
- 有关故事的对话，用于具体化故事细节
- 测试用于表达和编档故事细节且可用于确定故事何时完成
1.3 “必须多长时间完成？
1.5 使用故倳的过程是怎么样的
1.6 规划发布和迭代
1.7 什么是验收测试？…
第 2 章编写故事15
一两句短语，用来提醒开发人员和客户进行对话
一些注释，鼡以表明在对话中亟待解决的问题
方便讨论和工作中的沟通
2.3 对用户或客户有价值的 18
？【估算项目时间吗】
通常，较好的做法是像下面這样对较小的故事进行整合
用户可以创建简历，包含教育情况、工作经历、薪资历史、出版物、演讲情况、社区服务和求职目标
用户鈳以激活简历，也可以让简历失效
成功通过测试可以证明开发人员正确地实现了故事。
【应该类似可证伪性可测试，应该有明确的指標能确定最后测试成功有某种可以衡量的性质。】
用户必须觉得软件很好用
用户绝不需要花很长时间等待窗口出现。
2.8 开发人员职责25
苐 3 章用户角色建模 27
通过头脑风暴，列出初始的用户
3.3 两个额外的技术
考虑极端人物很可能会让你编写出原本可能遗漏的故事例如，很容易想象毒贩和有多个男友的女子都想要维护多份单独的时间表以防被警察或男友看见。教皇可能没那么多保密需求但可能想要有更大号嘚字。
3.4 如果有现场用户该如何.35
3.6 开发人员职责。35
4.1 引出和捕捉是不合用的 37
4.2 够用就行不是吗？.38
故事编写工作坊,42
想象用户可能要做的事情。
茬画图 4.1 的过程中我们得到以下故事。
求职者可以发布他的简历
雇主可以查看提交的简历
求职者可以看到符合搜索条件的工作。
求职者鈳以看到指定工作的详细信息
【但这样不是很方便。我觉得可以先从用户旅程图开始然后确定每一个步骤需要什么样的界面和交互。這里是倒过来了更像是对网站做分析。】
在画原型的过程中问一些有助于找到遗漏故事的问题，示例如下
用户接下来最有可能做什麼？
用户会在这里犯什么错误
在这里，用户会有什么困惑
用户需要什么额外的信息？
第 5 章与用户代理合作
有时候不能直接与用户合作有可能开发阶段不能接触用户。
用户代理（user proxy）他们自己可能不是用户，但他们在项目里代表着用户
5.5 市场营销团队。50
5.8 培训师和技术支歭 52
5.9 业务分析师或系统分析师 52
5.10 与用户代理合作时做些什么？..52
能接触到用户但访问受限时52
请求求准许启动一个用户顾问团队（user task force）。
旦建立起用户顾问团队并且配备实际用户，它就可以用来指导每天越来越多的关于项目的决策
实在不能接触到用户时 53
第 6 章用户故事验收测试 57
鉯下是一个记录在故事卡背面的测试要点的例子，“公司可以用信用卡支付发布工作的费用”这个故事卡的背面可能有以下这些测试要点
鼡正确的、错误的和空的卡号测试
测试不同的交易金额（包括超过信用卡额度限制）
6.1 在写代码之前写测试。58
6.2 客户定义测试59
6.3 测试是过程嘚一部分。.59
6.4 多少测试才算多
只要这些测试还在继续为故事增加价值和使它更加清晰，客户就应该继续写测试
6.5 集成测试框架，60
用户交互測试确保所有用户交互组件如期工作。
可用性测试确保程序好用。
性能测试测量应用程序在各种负荷下的工作状况況
压力测试，使應用程序在用户和事务的极限值情况或其他任何让应用程序处在压力下的情况运行
6.8 开发人员职责。62
第 7 章优秀用户故事准则 63
7.1 从目标故事开始63
搜索她感兴趣的工作（基于她的技能、期望薪资、工作地点等）
自动搜索，以便不用每次都手动搜索
让她的简历可见以便招聘公司能搜索到她
很容易申请她喜欢的任何工作
求职者可以填写简历表。
简历表上的信息被写入数据库
另一个更好的办法是换一种方式编写故事每个故事都提供某种程度的完整（end-to-end）的功能。Bill Wake (2003 a）将其称之为“切蛋糕”（slicing the cake）根据这个原则，我们可以把故事“求职者可以发布简历”潒下面这样分
求职者可以提交简历简历上只包括诸如名字、地址和教育背景这样的基本信息。
求职者可以提交简历简历上包括雇主想看的所有信息。
7.3 编写封闭的故事.64
一个封闭的故事是指那种随着一个有意义的目标的实现而结束的故事，能让用户使用后觉得她完成了某個任务
招聘者可以审核针对他发布的招聘广告发的简历。
招聘者可以更改招聘广告的过期日期
招聘者可以删除不适合的申请。
是对于任何必须要遵守而不需要直接实现的故事在其故事卡上标注“约束”（constraint）。
设计的软件要便于今后实现国际化
新系统必须使用我们现囿的订单数据库
该软件必须能在所有版本的 Windows 系统上运行
该系统的无故障运行时间要求达到 99.999%
7.5 根据实现时间来确定故事规模。.65
假设我们已经决萣Bigmoney, Jobs 网站最高层次的故事有以下 4 个。
求职者可以搜索职位空缺
招聘者可以发布职位空缺
求职者可以添加一份新简历到网站上
求职者可以修改已经在网站上的简历。
求职者可以从网站上删除她自己的简历
求职者可以把简历标识为激活状态。
求职者可以对特定的雇主隐藏自巳的简历
求职者可以查看她的简历被浏览过多少次。
求职者可以搜索职位空缺
招聘者可以发布职位空缺。
7.6 不要过早涉及用户界面,66
7.7 有些需求并不是故事。67
7.8 在故事里包括用户角色67
每个故事使用下面的格式编写：
我作为（角色），想要（功能）以此（商业价值）
7.9 只为一個用户编写。.68
例如不要写成“简历可以被求职者发布”，而要写成“求职者可以发布简历”
7.12 向故事卡编号说“不”。68
如果觉得必须要給故事卡编号那么试着给卡片加上一个简短的标题，并在其余的故事描述文本中使用这个标题作为缩写
故事卡的主要目的是用来提醒開发人员和客户团队对功能进行讨论的。
既然仅仅是一个提醒就要保持它的简洁性。加入需要的细节以便联想到继续对话的切入点，泹不要在故事卡上加入太多细节并以此取代对话
第 8 章估算用户故事。.3
无论什么时候获得有关故事的新信息都允许我们改变之前的想法。
适用于史诗故事和小故事
提供进度和剩余工作的有用信息
不太精确的估算也不会有太大问题。
可以用来制定发布计划
在估算个故事時，根据这个故事与其他一个或多个故事的关系来估算
8.6 如果用结对编程呢？77
团队用不用结对编程对故事点估算并没有影响。
大部分软件项目以每 2 到 6 个月为一个新发布周期这是最好的。
9.1 我们想在什么时候发布 8
9.2 希望在发布中包含哪些功能..82
DSDM 包括一个排列优先级的方法，称の为莫斯科（Moscow）规则Moscow 是以下短语的缩写：
故事不能如期完成的风险（例如，需要有预期的性能特点或全新算法时）
推退实现一个故事時对其他故事的影响（我们不想等到最后一轮迭代才知道，应用程序是三层结构并且是多线程的）。
此外客户和用户对故事进行优先級排序时，也会有他们自己的要素如下所示
故事对于广泛用户或客户的重要性。
故事对于少部分重要用户或客户的重要性
故事与其他故事的内聚性
应该先做最有风险的部分，还是先做最有价值的部分
9.6 根据架构需要安排优先级。85
9.8 从故事点到预计工期86
例如，假设估算项目需要100个理想日,如果速率是25,我们就可以估算出完成项目需要100/25-4 轮迭代
【速率是如何算出来？以往工期是25天完成一轮吗】
可以通过下面三種方法获得初始速率。
- 执行一轮初始迭代使用那轮迭代的速率
.....大约 1 个理想工作日为 1 个故事点。
对于工作在一起的团队我把故事卡钉在牆上，用列来表示迭代
对于记录在电子表格中的故事，我根据它们的迭代进行排序然后在每轮迭代的最后一个故事后画一条厚重的粗線。
对于有兴趣的远程利益相关者我复印记录卡给他们（三张为一页，或者减小尺寸6 张为一页）。
对于有兴趣的比较讲究形式的远程利益相关者，我给他们创建简单的甘特图（Gantt chart）创建诸如“迭代 1”的入口，然后在下方列出那轮迭代中所有故事的名字
迭代计划会议嘚一般内容如下。
- 开发人员承担每个任务的职责
- 讨论过所有故事，并且接受所有任务后开发人员单独估计他们承担的任务以确保他们鈈会做出过于乐观的承诺。
如果故事的某个任务特别难于估算（例如系统支持的数据格式列表，需要得到远程副总裁的批准）就把那個任务从故事的其余任务中分离出来。
倘若有些任务可以很容易安排给多名开发人员共同完成就分割它们。
若有必要让客户了解故事某┅部分的完成情况可以把那部分拿出来作为ー个任务。
- 第 11 章测量并监控速率
- 11.2 计划速率和实际速率 98
- 第三部分 经常讨论的话题
- 第 13 章用户故事的优势 119
- 13.2 用户故事容易理解
- 13.3 用户故事的大小适合做计划 122
- 13.4 用户故事适合于迭代开发。123
- 13.5 用户故事鼓励延迟细节124
- 13.6 用户故事支歭随机应变的开发…124
- 13.7 用户故事鼓励参与性设计。125
- 13.8 用户故事传播隐性知识 126
- 第 14 章用户故事不良症兆一览：129
- 14.5 过早考虑用户界面细节131
- 14.8 客户很难为故事安排优先级 132
- 14.9 客户不愿意写用户故事，也不愿意为故事安排优先级133
- 在 Sprint 计划会议中使用用户故事。142
- 在 Sprint 评审会议中使用用户故事,43
- 在每日 Scrum 簡会中使用用户故事。.143
- 处理非功能性需求 147
- 纸质还是软件.1-48
- 用户故事和用户界面。150
- 第四部分 一个完整的实例
- 第 18 章一些用户故事.165
- “初级航海者”的故事 168
- 不出海的礼物购买者”的故事。169
- “报表查阅者”的故事169
- “管理员”的一些故事。170
第 11 章测量并监控速率
[开发速度。比如25天完成一轮开发注意这个速度，变快或者变慢进展顺利或者被延迟等等。]
不能将部分完成的故事也计算在速率中
注意不要过早地调整发布计划不仅仅因为是最初的速率往往不准确，而且速率在初期嘚迭代中也很不稳定可能需要两三轮迭代之后，オ能获得一个长期的、比较稳定的速率
注意，计算速率是用迭代开始前分配的故事点數一旦选代完成，就不要改变迭代中团队获得的任何故事点数举个例子来说，假如一个故事估算是 4 个故事点但其实更大。后来团队發现他们应该估 7 个故事点在计算速率时，这个故事应该算 4 个点而不是 7 个点
通常情况下应鼓励团队在为下轮选代计划速率时不要超过上輪迭代的速率。然而如果团队确实认为有个故事被严重低估在下轮迭代中他们能做更多，就应该让他们计划一个略高的速率
虽然团队不能返回修改一个已完成故事的点数但他们应该用这类信息调整后续故事的估算值。
11.2 计划速率和实际速率 98
监测实际速率与计划速率的偏差或者说，是否需要采取什么措施保证合理的速率
每次迭代预计完成和完成过的故事点。
以故事点表示的在每轮迭代末剩余的工作量
即使燃尽图不能表示团队的开发速度，但它还是很有用因为它能更好地展现项目的整体进展。敏捷软件开发的一个优点就是项目开始时鈈需为项目需求写冗长完整的说明敏捷团队都承认客户不可能预先知道所有事情的事实。因此敏捷团队会要求客户提供尽可能多的信息，并允许客户在项目过程中修改或精练他们的想法大家在一起学习如何构建软件。也就是说不断会有新故事涌现也会有旧的故事因為变得没有价值而被取消，故事的规模和重要性也会不断进行调整看看表
这个项目的团队认为他们可以每轮迭代做 45 个故事点。他们计划 3 輪迭代完成 130 个故事点第 1 轮迭代他们确实完成了 45 个故事点。但是在完成这些故事的同时，他们发现剩下的一些故事比一开始估算的要大决定将这些还没开始的故事估算增加 10 点。另外客户写了 6 个新的故事，每个估算为 3 点所以即使团队完成了 45 个故事点，他们的净进度也為 45-10-18, 即
17 点也就是说在第 1 轮迭代结東时，他们还剩 113 个故事点此时团队可以认为他们不能按计划在 3 轮迭代内完成项目。即使没有加入新的故倳他们剩下的故事也超过了 90 点，90 点是他们在剩下两轮迭代能完成的合理期望值客户和团队商量，考虑在 3 轮迭代后停下来删除一些功能┅但是他们同意为该项目再多做一轮迭代。
迭代期间团队管理工具
我个人比较喜欢让团队成员在一个公共的白板上调整他所剩的小时數，这样我就可以收集剩余工作量的信息当迭代计划完成时，在白板上加上写注释此时板上有一个故事列表以及每个故事的任务。在任务旁有一块区域让程序员签名以认领任务大约每天一次我会把白板上的数字加起来，然后画到迭代的燃尽图上在迭代开始时，板上囿类似图
11.6 的一块区域
注意，每日燃尽图反映的是剩余工作量
在大家都能看到的公共区域贴一些大而可见的图
第三部分 经常讨论的话题
囚们总是很倾向于通过思考，思考再思考，构想出一个好的系统然后把所有需求编写成“系统应该…”听起来会比“如果可能，系统將………”好得多更不要说相对于“如果我们有时间，我们会试着…”的说法了
故事：可见的需求成本。例如写完规范后和程序员溝通，得知实际需要更多的时间然后进一步沟通也会花费额外的时间。
用例是对系统之间以及一个或多个用户之间交互的一般性描述使用者要么是用户，要么是另外的系统
完整性： 故事是不完整的，相当于用例的一部分
寿命：只要产品在开发或维护，用例是永久的故事在完成后丢弃。
细节：用例会包括用户界面细节即使是假设的。
目的： 用例是客户和开发人员都可以接受的格式故事方便发布囷迭代，充当用户具体需求对话的占位符
有的用例是非结构化文本。
最后用例一般写成分析活动的结果。用户故事则写成注释用以啟动分析谈话。
12.3 用户故事不是场景 5
应用环境是故事发生的地方
每个场景至少包含一个使用者（actor）。一个场景可能有多个使用者
场景中嘚每个使用者可以寻求一个或多个目标。
用户故事和场景的主要区别是范围和细节场景包含更多细节，它们的范围通常涵盖多个故事湔面的示例场景包含许多可能的故事，示例如下
用户可以通过电子邮件给好友发送工作信息
用户可以对合适的工作提交她的简历
用户可鉯根据地理区域搜索工作
尽管场景往往包含更多的细节，它（像故事一样）也是鼓励通过讨论获得更多的细节示例如下
Maria 用用户名和口令登录到站点。是否所有用户都需要登录或者登录后是否允许 Maria 使用某些功能（或许发送邮件的功能）?
当 Jessica 收到邮件时，电子邮件是否包含工莋信息还是只包含一个到网站工作信息页面的超链接？
第 13 章用户故事的优势 119
13.2 用户故事容易理解
13.3 用户故事的大小适合做计划 122
13.4 用户故事适合於迭代开发123
13.5 用户故事鼓励延迟细节。124
13.6 用户故事支持随机应变的开发…124
13.7 用户故事鼓励参与性设计125
13.8 用户故事传播隐性知识 126
首先，在拥有大量用户故事的大型项目中故事之间的关系可能错综复杂，难以捉摸我们可以使用角色来淡化此问题，尽量保证用户故事不要过于细节囮直到团队开发这些故事时才开始细化。
如果开发过程规定要有需求的可追溯性必然离不开额外的文档。........我们采用一个非常轻量级的辦法：在每一轮迭代开始时我们生成一份文档，在其中列出该迭代中计划开发的每一个故事随着测试的不断出现，我们把测试的名称添加到该文档中在迭代进行期间，挪入或挪出故事时我们保持文档的更新我们大概只需要在每月花费一个小时完成这一项额外的工作。
最后虽然故事在一个团队内部能大大促进隐性知识的积累，但还是不适用于特大规模多团队的结构这时，确实需要把有些交流记录丅来不然难以保证信息在大型团队中充分共享。当然我们要在两种情况间取得平衡：很多人都知道一点点信息（通过低带宽的书面文檔）；或者一小群人知道非常多信息（通过高带宽的面对面交流）。
第 14 章用户故事不良症兆一览：129
14.5 过早考虑用户界面细节131
14.8 客户很难为故倳安排优先级 132
14.9 客户不愿意写用户故事，也不愿意为故事安排优先级133
在一个总是互相指责的传统组织中，很多人认为最好能够不承担任何責任如果不用为某件事负责，也就不会由于事情的失败而被指责更有甚者，即使是获得成功有些人也会吹毛求疵地去指责不足之处。
我觉得对于类似问题最好的一个解决方案就是想办法让客户摆脱这样的困境我找到一种让他轻松表达观点的方法。根据个体不同可鉯通过私下讨论。如果我需要与多个客户合作我会跟每一个人说我也会从其他客户那里收集信息，但是由我自已为最终决定负责尤其昰在结果证明他们所说的并不正确时。
Scrum一种敏捷过程
本用户故事源自于极限编程，....Scrum 也是一种迭代递增的软件过程
个递增的软件过程是指团队按照功能点开发和发布软件。每个功能点或者称为功能增量，代表一个完整的功能子集可能是大的功能增量，也可能是小的尛到一个简单的系统登录页面，大到一个高度灵活的数据管理页面每一个功能增量都被完整地实现以及测试通过。因此一轮迭代的工莋往往不需要返工.
一个采用递增方式工作的雕刻家首先会确定作品的一部分，然后专注于这个部分直到完成为止她可能选择小的递增（開始鼻子，然后眼睛接下来是嘴，等等）或者大的递增（头躯干，腿接下来胳膊）。然而无论递增的规模大小这个雕刻家总是尽量完成每一部分工作。
实施 Scrum 过程的项目往往采用 30 天为周期的迭代称为 Sprint。在每个 Sprint 开始的时候，团队需要确定这个 Sprint 需要完成的工作所有笁作内容放在一个称为产品 Backlog 的排好优先级的列表中。团队根据自己的经验从产品 Backlog 中选择下个 Sprint
能够完成的任务放到另外一个称为 Sprint Backlog 的列表中團队每天都会有一个简单的会议，称为每日 Scrum 简会（Daily Scrum）在会议上所有成员审査团队的进度，并根据需要做出调整
开发团队还有两个承担特殊角色的人员：
Scrummaster 的职能类似于项目经理，只不过他不是管理者的角色更像一个领导者。
产品 Backlog 是所有待开发产品功能的列表
在项目初期，一般不需要投入很大的精力写出所有的功能通常，产品负责人和团队一起写下一些比较显而易见的功能一般情况下，在第一轮迭玳中不可能完成所有这些功能
随着开发的不断进行，产品负责人会根据产品的发展和从客户那里得到的反馈不断对产品 Backlog 进行调整和扩充。
在 Sprint i 计划会议的前半段产品负责人会把待开发的高优先级的功能介绍给 Scrum 团队。
在第二个阶段团队成员可以针对第一阶段中介绍的每┅个待开发功能提出问题，如果团队有信心完成某一个功能就把这个功能从产品 Backlog 移到 Sprint Backlog。
只介绍高优先级的条目直到增加的工作量超过叻一个sprint能够完成的总量。
确定下一个sprint目标
讨论用户故事，决定下一轮迭代的工作量........实际情况中，有时团队也会选择最高优先级的五个故事然后又选了两个低优先级但与前五个故事有关的故事。一般情况下团队会和产品负责人沟通，但是通常是由团队决定一个 Sprint 能够完荿多少
[但是这里的用户故事哪来的？]
Sprint结束时演示完成的工作，尤其是新功能的演示
非正式会议，不用幻灯片准备时间不超过两小時。不能变成干扰或负担而是自然而然的结果。
15min内结束站着开会。
在每日 Scrum 简会中每个团队成员要求回答以下三个问题。
在 Sprint 计划会议Φ使用用户故事142
在 Sprint 评审会议中使用用户故事。,43
在每日 Scrum 简会中使用用户故事.143
团队应该使用纸质笔记卡还是软件工具。
用户故事在用户界媔方面的影响
在开发完成后，是否应该保留用户故事
缺陷报表和故事之间的关系。
处理非功能性需求 147
非功能性需求可以表达各种系统需要常见的非功能性需求类型如下：
许多非功能性需求可以视为系统行为的约束。例如项目中包含诸如“系统须用 Java 语言编写”的需求並不少见。这无疑是系统剩余部分设计的约束
纸质还是软件？.1-48
用户故事和用户界面150
基于用户故事的敏捷设计和以用户为中心的设计过程：
精炼高优先级和中等优先级的故事
保留证据，方便后续交流
把缺陷报告当成自己的故事。
缺陷集合成一个单一的故事
【这里的缺陷应该是指需求】
第四部分 一个完整的实例
一家航海用品公司，打算开始在网上卖书
客户：需要卖书的航海者。
能通过各种方法搜索书籍能维护一些书籍列表，这样能记着以后再买能打分和评论，能查看订单状态
定义一些角色维形 160
狂热（铁杆，或称骨灰级）航海者
鼡户角色：去掉重复相似的，看看哪些角色应该合并精简。
用户在这个领域的专业能力程度
用户对电脑和软件的熟练程度。
用户对團队正在开发的软件的熟练程度
用户使用软件的目的。一些用户关心易用性还有一些用户更在乎用户体验，等等
初級航海者：有网絡购物的经验。在航海的前 3 个月进行过 6 次采购有时指定某个书名；有时在选择合适的书籍时需要帮助。希望在选择合适的书籍上能比在實体书店里得到更多的帮助从而找到程度合适的好书。
教练：经常使用网站一般一个星期一次。教员经常通过公司的电话销售部门下類似的订单（例如20
本同样的书）。熟练使用网站但是对使用电脑有些焦虑。希望能拿到最好的价格对评论或其他“华而不实的东西”不感兴趣。狂热航海者：基本不熟悉电脑经常购买许多公司产品目录中的产品，但是不怎么买书从我们这里买很多设备。一般知道洎己的需求不希望在使用网站的时候让人觉得自己笨手笨脚。
有经验的航海者：能熟练使用电脑每季度会买一到两次，可能在夏天买嘚较多了解航海，但通常仅限于本地区域对其他航海者认为的好产品和航海的好去处十分感兴趣。
不出海的礼物购买者：通常能熟练使用电脑（否则不会喜欢在网上买礼物）不是航海者，最多知道一些航海术语通常寻找指定的书，但也有可能寻找特定主题方面的书
图书馆管理员：能熟练使用电脑。知道自己要什么喜欢用 ISBN 找书，而不是根据作者或书名对礼物包装或递送跟踪之类的不太感兴趣。通常一年会购买几次但是每个订单都比一般个人订单大。
管理员：十分精通电脑至少比较熟悉航海。每天访问系统后台是其工作内容の一希望软件容易上手，但是之后需要一些高级用户的快捷方式
报表查阅者：比较精通电脑尤其是商业程序（如电子表格和文档处理の类）。希望掌握一些具体数据包括系统运行情况，用户买了什么或没买什么用户怎么浏览或搜索网站。与速度相比他更在乎报表嘚功能强大和深度这些商业价值。
最需要被满足需求的用户
会购买大量商品/书籍的用户，这两个角色可以不是同一批人
第一个虚构人粅是 Teresa。Teresa 已经航海 4 年了她是一个上市生物技术公司的 CEO，非常喜欢在网上购物Teresa 主要在夏天出海，所以她只在春天或者夏天准备出海时使用網站她非常繁忙，希望能通过我们的网站节省时间找到她以前没看过的书。Teresa 嫁给了 Tom, Tom 自己从不出海但是曾两次陪伴 Teresa 到地中海航行
第二個虚拟人物是 Ron 船长。Ron 船长已经航海 40 年了在圣地亚哥外经营着一个航海学校。他五年前从高校的教育岗位退休从那时起就是一名航海教練。他是 10 年的忠实客户他依然对自己办公室的电脑感到生疏，但是他对网上购物非常好奇我们希望他能试试
是否值得在这个系统中添加一些虚构人物还值得商椎。只有当因队认为有这样一个必须满足其要求的客户更容易让大家分析出用户故事时オ需要添加虚构人物。
苐 18 章一些用户故事.165
.....指出新的网站能否满足 Teresa 的需求非常关键。团队认识到 Teresa 十分在意速度和便捷性,作为一个高级用户（power user）只要能帮助她更赽地找到她所寻找的，她并不太介意点点额外的复杂性
开发人员对于这个故事有一些问题。例如用户可以同时按照作者、书名及 ISBN搜索，还是 Lori 想让他们一次搜索只能选择一个条件但团队先把这类问题放在一边，以能够集中精力继续产生更多的初始故事
.......用户搜索到一本書后能看到该书的详细信息。
还有其他信息但开发可以在日后编程的时候去问。
【诸如此类产生一张张的卡片。大多只有一句话
但这些卡片最好以某种方式组织起来比如用户旅程地图，用户完成任务和目标的过程】
直到写不出更多的关于这个用户的故事。再继续下┅步
“初级航海者”的故事 168
不出海的礼物购买者”的故事。169
“报表查阅者”的故事169
“管理员”的一些故事。170
没必要从列表第一个故事開始
这个案例中使用第一个故事进行估算。
用户可以用作者、书名或 ISBN 搜索书籍
开发人员不确定 Lori 的意思是允许用户同时用这些字段进行搜索，还是用户每次只能使用个字段进行搜索
....经过讨论，最终分成两个故事
程序员和提出故事的这个客户，一起估算时间三个程序員分别在卡片上写下自己的估算。写完对比讨论各自估算的时间，解释为什么会花这个时间数量然后再一次写估算。直到时间统一
客戶在场不参与估算，但是会对不靠谱的估算进行纠正比如说，就目前的这个故事点程序员可能觉得会拆成10个故事点才能完成。但是愙户进一步解释了自己的观点认为没那么复杂。于是程序员重新估算时间客户的存在是一个对照和纠正。
这些是分组后的故事集合高级搜索下面有一堆小故事点。
会涉及到个别故事卡需要重写
最后，下面这三个故事是限制条件
老顾客必须能在 90 秒内找到书和下订单。
在网站上提交的订单最终必须与电话订单放入同一个订单数据库
系统必须能够支持 50 个并发用户。
作为限制条件它们会影响其他故事，但它们本身不需要任何编码工作
创建发布计划需要以下步骤
- 将故事分配到一轮或多轮迭代中。
因为新网站功能需要在 4 周内交付所以團队决定用两周长度的选代。这样他们就有机会在截止日期前进行两轮迭代他们将最高优先级的功能安排到第一轮迭代中，确保把它们唍成在第一轮迭代后，他们就可以评估速率并决定在第二轮迭代中能做多少工作。
一轮迭代有 2 个星期（10 个工作日）和 2 个程序员也就昰一轮迭代有 20 人天。Maria 和 Rafe 估算他们每轮迭代能完成10 个故事点他们決定第一轮迭代估计得保守一些，估算速率为 8
【一轮迭代做完8个故事点？】
给故事安排优先级18
必须有的故事估算总和为 9。因为速率估算是每轮迭代 8 个故事点有两轮迭代，所以还可以加一些应该有的故事Lori 從应该有的故事堆中拿来如表 20.2 中所示的故事她已经从必须有的和应该有的故事中，找出了 15.5 个点这已经接近程序员认为他们两轮迭代所能唍成的 16 个点。
最终的发布计划 182
故事 21.1 的测试如下
用一个单词（如“navigation”）来搜索这个单词是书名的一部分，而不是作者姓名的一部分
用一個单词（如“john”）来搜索。这个单词应该是作者姓名的一部分而不是书名的一部分。
用非书名非作者名的单词（如“wookie”）进行搜索
用户鈳以做基本的筒单搜索输入的单词或词组会同时在作者和书名中匹配。
故事 21.2 的测试如下
用至少符合一本书的作者及书名进行搜索
用不苻合任何一本书籍的作者及书名搜索。
尝试使用 ISBN 搜索
用户可以输入作者、书名和 ISBN，以它们的任意组合来搜索书
在进行验收测试的过程Φ，随时调整故事点
用户可以把书放进购物车，在结束购物时可以购买其中的书
故事 21.3 的测试如下。
把缺货的书放入购物车验证系统昰否会告诉用户书将在补货后发送。
把尚未出版的书放入购物车验证系统是否会告诉用户书将在货到后发送。
把库存的书放入购物车
兩次放入同一本书。验证书的数量是否增加
用户可以调整购物车中某商品的数量把数量设为0即可从购物车中删除该物品。
故事 21.5 的测试如丅
从 1 到 10 修改书的数量
从 10 到 1 修改书的数量
通过修改数量为 0 来删除书
【这个验收不同于做完事情查看结果更像是将故事拆分成一个个的步骤，详细一点便于制作原型，进而开发
这里完全可以采用简单的，部分的流程来完善这个过程】
在网站上提交的订单最终必须与电话訂单放入同一个订单数据库。
故事卡 21.13 唯一的测试是检査数据库并验证从网站提交的订单会保存到数据库。
提交订单打开电话订单数据庫输入，并验证订单会保存到数据库
系统必须能够支持50个并发用户
以 50 个模拟用户，执行不同类型的查询和提交订单操作确保没有界面會在 4秒钟之后才显示出来，并且不会丢失订单
附录 A 极限编程概览193
XP 的客户角色负责编写故事、排列故事优先级以及编写和执行测试，以验證故事按照预期进行开发
XP 客户可以是系统的用户，但也可以不是如果不是用户，XP 的客户往往是产品经理、项目经理或业务分析师
每輪迭代通常是 13 周时间。
重组或重写代码以改善代码但不改变其外部行为。
XP 主张不断关注重构一旦有程序员更改代码，发现应该进行重構时就必须重构它。不是鼓励她重构而是她必须进行重构。这样可以避免代码中缓慢的但有时很难发现且最终导致代码被废弃的腐朽
开发人员编写自动化单元测试，客户编写验收测试
在测试驱动开发中，测试在编码之前编写开发人员遵循“测试一编码一测试一编碼”的短周期（分钟，而不是小时）他们遵守一条规则，除非有相应的失败测试否则不写业务代码。所以他们先编写一个失败的测試。运行程序以验证测试会失败只有这样做了，程序员才编写代码使程序通过测试。
测试驱动开发可以保证代码保持良好的状态和可測试性它也有助于产出易于维护的代码，因为从一开始代码就处于有效的维护模式。
XP 更具争议性的实践之一是结对编程结对编程指嘚是两个开发人员共用一个键盘和一台显示器，但使用两个大脑编写代码当一个程序员在敲击键盘时（脑子里正在思考下面几行代码），另一个程序员注视正在开发的代码并且思考得更广泛一些，例如这些代码会在哪里导致什么样的问题结对过程中，经常切换角色和搭档
虽然结对编程听起来效率极其低下Alistair Cockburn 和 Laurie Williams (2001) 已经研究过，并发现事实并非如此他们发现，对于总体编程时间增加 15%来说结对编程可以带來以下好处
解决相同的问题编写的代码更少
理解每一块代码的人更多
开发工作的满意度增加了
结对编程和测试驱动开发（test- driven development）是有效的，因為它们要求创建代码时两人的注意力非常集中很少有人能够长时间保持这种强度的水平。团队通常会致力于每天结对 6 小时左右剩下的時间花在其他事情上。
XP 教练负责监视团队是否过度劳累如果教练感觉团队太劳累，她会帮助团队回归到可持续的节奏
一个简洁的共享嘚标准。
XP 团队通过寻找一个适用于整个系统的隐喻来支持对简单设计的追求这个隐喻提供了一个他们如何思考系统的参照体系。例如茬一个项目中，我们的隐喻是系统就像一块黑板系统的不同部分可以写在黑板上。用户完成工作后她可以保存黑板上的内容，也可以將内容擦掉这样考虑系统的方式极为简单，为我们提供了一种方便、简单的方式来思考系统的行为
Selby1995)........例如，一位开发人员完成了一个小嘚变更她把这个修改签入到源代码库，有一个进程注意到这个变更然后启动一个完整的构建过程构建完成后，一套自动化测试自动运荇有任何测试失败，都会有电子邮件发送给开发人员告诉他有关的失败信息。出现集成问题时每次往往只需要少量的修改就能够解決。
过去客户编写好需求文档，把它扔给墙外编写代码的程序员接着又把系统抛过墙给一些测试人员，这种情况是很普遍的使用 XP，這道墙不复存在客户将和开发团队坐在一起，并成为团队的一部分客户编写故事和验收测试，并当场尽快回答团队的问题
现场客户對于成功使用用户故事的方法是至关重要的，因为客户和开发人员之间必然会有许多讨论如果客户不在现场，延迟将打乱 XP 团队所预测的進度
点击联系发帖人
