《用户故事与敏捷方法》读书笔记 05 流程是什么

传统的瀑布导向的流程会造成一个循环：写下所有需求，分析需求，设计解决方案，编码解决方案，然后最终测试。在这种类型的流程中，客户和用户参与开始的写需求以及最后的接收软件，但是他们可能几乎否定需求和接收。

在故事驱动的流程中应该注意的第一件事是客户和用户一直在项目截止日期前全程参与。在项目中途，他们不被允许发表否定意见。

新软件的客户和目标用户应该计划着积极参与写故事，尤其在使用XP（极限编程）时。写故事的过程最好从考虑目标系统用户类型开始。比如，建立一个旅行预订网站，可能需要考虑用户类型频繁出差者、休假者等等。客户团队应该包含这些用户类型的代表人物。如果不行的话，可以使用用户角色模型。

项目最初的故事经常在写故事的车间进行，但是整个过程中任何时间都可以写故事。在故事记录车间，每个人可以尽量的头脑风暴。有了初始的故事集，开发者可以评估每个的大小。

在大家的协作下，开发者和客户团队可以选择迭代的长度，可能从一周到四周。同样的交互长度可以用于项目的截止时间。在每个迭代结束时，开发者要负责交付应用的某些子集的可用编码。客户团队在迭代过程中应该高度参与，在开发过程中和开发者讨论故事。在迭代中客户团队也可以确定测试，和开发一起实现自动化并进行测试。另外，客户团队要确保项目持续进行直到需求产品交付。

一旦选择了迭代长度，开发者将预估热门在每个交互中要做多少工作。我们称之为速度。团队第一次预估的速度将会不准确因为没有渠道能够预先得知速度。但是，我们可以用初始预估来做一个草图或者发布计划，关于每个交互中需要做什么工作，以及需要多少交互。

计划发行时，我们将故事分类为不同的堆，每一堆代表一个迭代。每个堆将包含某个数量的故事，加入的工作的预估时间不会比预计的速度多。最高优先级的故事在第一堆。当这个堆完成时，下一个最高优先级的故事在第二堆。这个过程一直持续直到你做了太多堆以至于项目超时或这些堆代表了一个理想的产品的新版本。

在每次迭代开始前，客户团队可以进行中期修正。随着迭代的完成，我们可以知道开发团队的实际速度，并且用它来代替预计的速度。这意味着每个故事堆需要通过加入或移除故事来及时调整。并且，一些故事比预计简单的多，因此团队优势想要在迭代中加入这个故事。但是有些故事比预计要难，这意味着部分工作会被一到下一个迭代或者移出这个版本。