用户故事与敏捷开发（第一章导图）

第1章 概览

软件需求实际上是一个沟通问题，在这个沟通过程中一旦任 一方在沟通中把持绝对地位，项目就会遭受一定的损失，那么就需要一种协同方法：让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。这种方法就是敏捷开发。

---

1、什么是用户故事？

用户故事描述了对用户、系统或软件购买者有价值的功能。每个用户故事代表一个独立的功能：即用户在一个单独环境中可能做的事情。一个好的用户故事有以下三个部分组成：

（1）、一份书面的故事描述，用来做计划和作为提示

（2）有关故事的对话，用于具体化故事细节

（3）测试，用于表达和编档故事细节且可用 确定故事何时完成

对这三部分有一个很好的概况，即：

卡片（ Card）、对话(Conversation）、确认（Confirmation）

需要注意：卡包含故事的文本描述，然而需求细化，要在“对话”中获得，并在“确认”部分得以记录。

---

2、细节在哪里？

事实上 ，多个小故事远远胜于个庞大的故事。

在最开始， 理想的情况是所有的故事能够让一两个程序员花半天到两周时间完成代码和测试。

如果一个故事很大，我们有时候就称之为史诗故事（Epic）。

史诗故事可以分成两个或更多的小故事。

3、必须多长时间完成？

用户的期望最好以验收测试的形式被记录下来，如果使用的是纸质片卡描述用户故事，可以把卡片翻过来，在背面记录下这些期望

特别注意，在记录测试的时候，测试描述可以简短、不完整，可以在任何时候加入或者删除。写这些测试描述的目的是传递故事的额外信息，以便于开发人员知道故事于什么时候结束

---

4、客户团队

在一个理想的项目中 我们会有一个专职人员为开发人员的工作排列优先级，回答他们的所有问题，在软件完成时使用软件，并且写下所有的故事。然而这几乎总是可欲而不可求，所以我们要建立 个客户团队。

客户团队中包括确保软件满足用户需求的所有人，可以包括测试人员、产品经理、实际用户和交互设计师。

5、使用故事的过程是怎么样的？

使用传统的面向瀑布模型的过程会有一个书写所有需求、分析需求、设计方案、编码、最终测试的周期。对于故事驱动的项目而言，最引人注目的是客户和用户在项目整个过程中全程参与，因此，编写用户故事的过程最好从考虑系统的用户类别开始。

一个项目的用户故事初稿通常是在故事编写工作坊（workshop）中写就的，但用户故事可以在项目生命周期的任何时候编写。

在项目开始后，一旦确定迭代长度，开发人员就会估计每轮法代中可以做多少事情。 我们称之为速率（velocity）。

确定速率之后，我们可以用初步估计来勾勒出大致的蓝图或者发布计划 用以说明在每轮迭代中会完成哪些工作，需要多少轮迭代周期

为了做发布计划我们把故事排列成许多堆，每一堆代表一轮迭代

---

6、规划发布和迭代

一个发布由一个或多轮迭代组成。发布规划指的是确定项目时间表和预期功能集合之间达到平衡。

在排列故事优先级时，需要考虑下面几点：

（1）、大部分用户和客户对特定特性的渴望程度

（2）、小部分重要用户和客户对特定特性的渴望程度

（3）、故事之间的关系。例如，“缩小”（zoom out）这个故事的优先级可能不高，但是它可能被看作是高优先级的，因为它与高优先级的另一个故事“放大”（zoom in) 互补。

（4）、排列故事优先级时，应该坚持客户组织利益最大化的原则

（5）、排列故事优先级时，不能不考虑它们的成本

（6）、除了在迭代中临时跳过一个大的故事而放入一个较小的故事以外，可以把大故事分成两个小的故事。

---

7、什么是验收测试？

验收测试用来验证实现的用户故事是否符合客户团队的期望。

需要注意的是测试应该尽早的在选代中编写。如果你能大致猜到即将开始的选代会产出什么，就应该在迭代开始前编写测试。尽早把这些测试交给开发人员，客户团队不仅澄清了他们的预期，也同时提醒了程序员可能会忘记的情形。

8、为什么要变？

1、用户故事强调对话交流而不是书面沟通。

2、用户故事 以同时被你和开发人员理解。

3、用户故事的大小适合于做计划。

4、用户故事适用于法代开发。

5、用户故事鼓励推迟考虑细节，直到你非常清楚地了解自己的真正需求。

---

9、小结

• 故事卡包含对用户或者客户有价值的功能的简短描述

• 故事卡是故事的可见部分，但客户团队和开发人员关于故事的对话更重要

• 客户团队包括那些确保软件符合潜在用户需求的人可以包括测试人员、产品经理、实际用户和交 设计师

• 故事是由客户团队编写，因为他们最了解如何表达需要实现的需求，也因为他们会与开发入员共同确定故事细节并安排故事的优先组顺序

• 按照故事对客户的价值来安排故事的优先级顺序

• 将各个融事放入选代 进行发布与法代规划

• 速率是开发人员可以在下一轮轮选代中完成的工作量

• 放入下一轮迭代的故事估计总和不能超过事先开发人员预计的速率

• 如果故事太大以至于无法在下一轮迭代中完成， 可以考虑把它分成两个或更多的小故事

• 验收测试用于验证实现的故事是否开发成符合客户团队的设想

• 用户故事是很有意义的，因为它们强调口头交流，你和开发人员都可以理解，可以用于进行选代计划，在迭代开发过程中能很好地工作，而且因为它们鼓励推迟细节

---

10、问题

1.1 用户故事包含哪 大部分？

1.2 客户团队 囱哪些人组成？

1.3 以下哪些不是好的用户故事？为什么？

     a. 用户可以在 WindowsXP Linux 上运行系统

     b. 所有绘图和图表将用第三方类库完成

     c.用户可以最多撤销 50 步操作

     d. 软件将在 30 日后发布

     e. 软件将用 Java 编写

     f.五用户可以从下拉列表框里选择她的国籍。

     g. 系统将使用 Log4J 把所有错误信息记录到一个文件中。

     h. 如果用户 15 分钟内没有保存文档，系统将提示用户进行保存。

     i. 用户可以选择“导出到 XML”特性。

    j. 用户可以导出数据到 XML 文件。

1.4 需求对话相对于需求文挡 有哪些优势？

1.5 为何在故事卡背面写测试描述？