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

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

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

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

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

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

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

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

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

通过故事评估效率

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

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

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

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

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

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

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