使用故事的过程是什么样的？

和以前习惯的相比，一个使用故事的项目将会带给你一种不同的感觉和节奏。使用传统的面向瀑布的过程会导致一个循环，即编写所有需求、分析需求、设计解决方案、编码实现解决方案，然后最终测试它。在这种类型的过程中，客户和用户通常在开始编写需求和最终接受软件的时候参与，但是在编写需求和最终接受之间的过程，用户和客户可能几乎完全没有参与。到如今，我们已经知道这是行不通的。

在一个故事驱动的项目中，首先关注的第一要事就是客户和用户在整个项目期间都保持参与其中。在项目的中途，他们不会被期望（或者允许！）消失。不管团队是否在使用极限编程（XP，参见附录A获得更多信息），敏捷版本的统一过程，像Scrum一样的敏捷过程（见第15章），或者是一个原生的、故事驱动的敏捷过程。

新软件的客户和预期用户应该准备在编写用户故事时扮演非常积极的角色，特别是在使用极限编程时。编写故事的过程最好从考虑预期系统的用户类型开始。例如，如果你正在构建一个旅游预订网站，你可能会有一些用户类型，例如飞行常客、度假计划者等等。客户团队应该包含尽可能多的用户类型的代表，但是如果做不到这点，用户角色建模就有帮助。（关于这一主题的更多内容，请参阅第3章）。

一个项目的初始故事通常都是在一个故事编写工作坊里写出来的，但故事可以在整个项目的任何时候来编写。在故事编写工作坊中，每个人都尽可能多地进行头脑风暴。有了一个初始的故事集，开发人员就可以估算每个故事的大小。

客户团队和开发人员协同选择一个大约持续时间从1周到4周长的迭代长度，项目期间会使用同样长度的迭代。在每次迭代结束时，开发人员将负责交付应用程序的某个完全可用的代码子集。在迭代过程中，客户团队仍然高度参与，与开发人员一起讨论在迭代过程中开发的故事。在迭代过程中，客户团队还详细地定义测试，并与开发人员一起工作，运行自动化测试。同时，客户团队确保项目不断向前推进，及时交付产品。

一旦选择了迭代的长度，开发人员就会估算他们在每次迭代中能够完成多少工作，我们称之为“速率”。因为没有办法预先知道速率，所以团队对速率的初始估算是不准确的。然而，我们仍然可以使用最初的估算来粗略估计发布计划中每一次迭代将要包含的工作量以及需要多少次迭代。

为了计划发布，我们将故事分成不同的批次，每一批次代表一次迭代。每一批次都将包含一些故事，这些故事的估算总和不超过估算的速率。最高优先级的故事会进入第一批次，当这批次报满时，次高优先级的故事就会进入第二批次（代表第二次迭代）。如此往复，直到你的批次累积时长超过了项目时限要求或者直到这些批次体现了一个令人满意的新产品的发布。（关于这些主题的更多内容，请参阅第9章和第10章。）

在每次迭代开始之前，客户团队可以对计划进行中途修正。当迭代完成时，我们可以获悉开发团队的实际速率，并且可以使用它来取代估算的速率。这意味着每一批次的故事都需要通过添加或者删除故事来进行调整。另外，有些故事会比预期的要容易得多，这意味着团队有时想在这次迭代中考虑额外增加一个故事来做。但是有些故事比预期的要难，这意味着有些工作需要转移到后期的迭代中，或者完全移出发布。