1.5. 使用故事的过程是怎样的？

对于故事驱动的项目而言，最引人注目的是客户团队在项目整个过程中全称参与，我们不希望（或者不允许）他们在项目进行时离开，不管团队是否在使用XP、Scrum之类的敏捷过程或开发人员自己发展出来的故事驱动的敏捷过程。

客户团队应该在编写用户故事时承担着非常活跃的角色。

编写用户故事的过程最好从考虑系统的用户类别开始。

例如，如果是在构建一个旅行预订网站，你可能会有诸如经常旅行者、假期计划着等用户类别。客户团队应该尽量包括了这些实际的用户类别。

可以参考使用用户角色建模。

客户团队为什么要编写故事？

有客户团队而不是开发团队来编写用户故事主要基于两个原因。

1. 每个故事必须用商业语言来写，而不是技术用语。这样一来，客户端团队可以排列故事的优先级，放入迭代和发布。
2. 作为主要的产品构想者，客户团队所处的位置最适合描述产品行为。

通过故事评估效率

一个项目的用户故事初稿，肯定是在一开始就要写好的，但是用户故事可以项目生命周期的任何时候编写。

在每次迭代结束时，开发人员将负责发布完全可用的应用程序子集。客户团队在迭代周期间高度参与，与开发燃油谈论迭代期间正在开发的故事。

在迭代期间，客户团队也会详细定义测试，并且和开发人员一起编写运行自动化测试。此外，客户团队要保证项目能够达到交付所需产品的目标。

一旦确定了迭代长度，开发人员就会评估每轮迭代中可以做多少事情。我们称之为速率(velociry)。

团队第一次的速率评估可能是错误的，因为无法事先知道团队的速率。然而，我们可以用初步估计来勾勒出大致的蓝图或者发布计划，用以说明在每轮迭代中会完成哪些工作，需要多少轮迭代周期。

在每轮迭代开始前，客户团队可以在中图修正计划。当迭代结束后，我们可以得知开发团队的实际速率，然后用它来代替估计速率进行估计。这意味着每一堆故事可能需要通过增加或者移除来进行调整。

有些故事可能比预期的简单很多，所以有时开发团队想在迭代中完成另外的故事。但有些故事比预期的难，这是就要把有些工作移到下一轮迭代或者下一个发布计划中去完成。