第11章 测量并监控速率
我们将项目分成一系列迭代来做发布计划，每轮迭代中安排一定故事点的任务。一轮迭代完成的故事点就是项目的速率。因为速率是非常重要的度量，所以怎么测量它变得很重要，而且速率在初期的迭代可能很不稳定，经过两三轮迭代后，才能获得一个长期的、比较稳定的速率。注意：对于尚未完成的故事，不应该把它算在速率里。
通常，我们可以通过对比计划速率和实际速率，检测团队的速率。
第12章 故事不是什么
用户故事不是IEEE830软件需求规格
一段典型的IEE830需求规格如下：
此刻，你的脑子里大概是一台汽车。IEEE830样式的需求已经使许多项目误入歧途，因为它侧重于关注需求的检查清单，而不是用户的目标。需求清单不会像故事那样给读者一个对产品的整体理解。而用户如果没有安装IEEE830的标准编写需求，而是告诉我们他对产品的目标：
此时，我们认识到客户实际上想要的是一个割草机，而不是汽车。
用户故事不是用例
用例是对一个或多个用户之间交互的一般性描述。
用例的示例
故事与用例之间最明显的区别是他们的范围，故事的范围更小，因为我们对他们的大小有限制，通常不超过10个开发工作日。故事通常对应用例的主要成功场景，而故事测试对应于用例的扩展场景。
故事与用例的另一个区别在于他们的寿命。用例通常永久性存在，而故事在迭代完成后，即可以撕毁。
另外的区别是用例比较容易包括界面的细节，包含界面细节会导致问题，尤其是在项目早期，显然为主的想法往往会使得用户界面设计更加困难。
用户故事不是交互设计场景
场景是用户与计算机交互的详细描述。实际上，交互场景通常比用例更大更全面。
场景示例
场景包括了一下几个元素：
- 应用环境：故事发生的地方，和简单的背景
- 角色：每个场景至少包含一个角色。与用例不同，交互场景中的角色总是人，而不是系统。
- 目标：每个角色可以寻求一个或多个目标。
- 行动：故事情节。
故事和场景的主要区别是范围和细节。场景包含更多细节，他们通常涵盖了多个故事，例如上面的场景可以拆分成多个故事：
第13章 故事的优势
- 用户故事强调口头沟通
- 人人都可以理解用户故事
- 用户故事的大小适合做计划
- 用户故事适合用于迭代开发
- 用户故事鼓励延迟细节
- 用户故事支持随机应变的开发
- 用户故事鼓励参与性设计
- 用户故事传播隐性知识
用户故事的不足：拥有大量用户故事的项目中，故事之间的关系可能错综复杂，难以捉摸。我们可以使用角色来淡化此问题，尽量保证用户故事不要过于细节化，直到团队开发这些故事时才开始细化。
第14章 故事的不良征兆
- 故事太小：经常需要调整估算，可能是因为故事太小。例如“编辑结果可以保持XML文件”和“编辑结果可以保持HTML文件”，显然这两个故事在很大程度上共享一部分实现，在计划时，应将这样的故事合并起来。
- 故事相互依赖：由于故事之间有依赖，所以很难做迭代计划。
- 镀金：开发人员在迭代中实现了计划外的功能，一个有效的解决方法是通过每日会议提高项目中每个人任务的可见性。
- 细节太多：花太多的时间去写故事，而不是去讨论故事。
- 过早考虑用户界面细节：在项目早期阶段编写的故事已经包含用户界面细节。
- 故事划分太过频繁：为了确保工作量而频繁的划分故事。
- 客户很难为故事安排优先级：故事太大或者无法体现出商业价值时很难排列优先级。