第一部分 起步
第一章 概览
什么是用户故事
用户故事描述了对用户、系统或软件购买者有价值的功能。
- 一份书面的故事描述，用来做计划和作为提示。（Card）
- 有关故事的对话，用于具体化故事细节。（Conversation）
- 测试，用户表达和编档故事细节且可用于确定故事何时完成。（Confirmation）
用户故事代表对用户有价值的功能。
例如，一个用户故事雏形是“写在卡片上的用户故事雏形”，那么对应的示例故事可能包括如下几个：
- 用户可以搜索职业。
- 用户可以发布新职位。
- 用户可以限制浏览其简历的人。
- 这个软件将用C++语言来编写。
- 程序将通过连接池连接到数据库。
故事1、2、3就是比较理想的用户故事，因为他们对用户是有价值的。
而故事4、5就不是理想的用户故事，因为用户不关心系统是用什么语言编写的，也不关心应用程序如何连接数据库之类的技术细节。这2个故事都是开发人员才需要关心的技术问题。
客户为什么要编写故事？
1、首先，每个故事必须用商业语言来写，不是用技术术语，这样一来，客户团队可以排列故事的优先级，放入迭代和发布。
2、其次，作为主要的产品构想者，客户端团队所处的位置最适合描述产品行为。
规划发布和迭代
发布规划指的是确定项目时间表和预期功能集合之间达到平衡。
假设开发团队每轮迭代的速率是13个故事点：
| 故事 | 故事点数 |
|---|---|
| 故事A | 3 |
| 故事B | 5 |
| 故事C | 5 |
| 故事D | 3 |
| 故事E | 1 |
| 故事F | 8 |
| 故事G | 5 |
| 故事H | 5 |
| 故事I | 5 |
| 故事J | 2 |
用户故事的发布计划：
| 迭代 | 故事 | 故事点数 |
|---|---|---|
| 迭代 | A、B、C | 13 |
| 迭代 | D、E、F | 12 |
| 迭代 | G、H、J | 12 |
| 迭代 | I | 5 |
分割故事，做更好的发布计划：把故事I分成故事Y（3个点）和故事Z（2个点）
| 迭代 | 故事 | 故事点数 |
|---|---|---|
| 迭代 | A、B、C | 13 |
| 迭代 | D、E、F | 12 |
| 迭代 | G、H、Y | 13 |
| 迭代 | J、Z | 4 |
什么是验收测试？
验收测试用来验证实现的用户故事是否符合客户团队的期望。
测试应该尽早的在迭代中编写，早期编写测试是非常有用的，因为这样一来，客户团队的假设和预期会更早与开发人员沟通。
假设写下故事“用户可以用信用卡为购物车中的物品付款”。然后再故事卡背面写下测试描述：
- 用Visa信用卡、万事达信用卡测试（通过）。
- 用大来卡测试（失败）
- 用Visa借记卡测试（通过）
- 用有效、无效和反面丢失卡ID号的信用卡测试
- 用过期卡测试。
- 用不同购买金额测试（包括超出信用卡额度）
这些测试捕获了这样的预期：系统将可以处理Visa卡、万事达卡和美国运输卡，不允许用其他卡购买。尽早把这些测试交给开发人员，客户团队不仅澄清了他们的预期，他们可能也同时提醒了程序员可能会忘记的情形。
为什么要变？
- 用户故事强调对话交流而不是书面沟通。
- 用户故事可以同时被你和开发人员理解。
- 用户故事的大小适合于做计划。
- 用户故事适用于迭代开发。
- 用户故事鼓励推迟考虑细节，直到你非常清楚地了解自己的真正需求。
每个用户故事代表一个独立的功能，即用户在一个单一环境中可能做的事情。
迭代过程是一个逐步求精的过程。
推迟细节很重要，因为这样一来，我们在不确定是否真正需要某个新特性时，可以不花过多时间来考虑它。使用故事，我们不必假装可以事先知道并写下所有东西。以客户团队和开发人员的讨论为基础，不断地精炼我们的需求。
小结
- 故事卡包含对用户或者客户有价值的功能的简短描述。
- 故事卡是故事的可见部分，但客户团队和开发人员关于故事的对话更重要。
- 客户团队包括那些确保软件符合潜在用户需求的人，可以包括测试人员、产品经理、实际用户和交互设计师。
- 故事卡由客户团队编写，因为他们最了解如何表达需要实现的需求，也因为他们会在后期于开发人员共同确定故事细节并安排故事的优先级。
- 按照故事对客户的价值来安排故事的优先级。
- 将各个故事放入迭代，进行发布与迭代规划。
- 速率是开发人员可以在一轮迭代中完成的工作量。
- 放入一轮迭代的故事估计总和不能超过事先开发人员预计的速率。
- 如果故事太大以至于无法在一轮迭代中完成，可以考虑把它分成两个或更多的小故事。
- 验收测试用于验证实现的故事是否开发成符合客户团队的设想。
- 用户故事是很有意义的，因为它们强调口头交流，你和开发人员都可以理解，可以用于进行迭代计划，在迭代开发中能很好地工作，而且因为它们鼓励推迟细节。
