《敏捷软件开发：用户故事实战》—计划发布和迭代

计划发布和迭代

一个发布是由一个或者多次迭代组成的。发布计划是指在预定的时间表和所需的功能集之间确定一个平衡。迭代计划是指在这次迭代中选择要包含的故事。客户团队和开发人员都参与发布计划和迭代计划过程。

为了计划发布，客户团队开始对故事进行优先级排序。进行优先级排序要考虑如下因素。

l   这一特性对大多数用户或者客户是否具有吸引力。

l   对于少数重要用户或者客户来说，这一特性是否具有吸引力。

l   故事与其他故事之间的内聚关系。例如，一个“缩小显示”的故事可能它自身不具有高优先级，但是如果作为故事“放大显示”的补充，它就具有了高优先级。

对于许多故事，开发人员可能有不同的优先级定义。他们可能建议，故事的优先级应该根据技术风险或者因为它与另一个故事的互补关系而改变。客户团队应该听取他们的意见，应该坚持交付组织最大化价值的原则，然后调整故事的优先级。

故事在优先级排序时必须考虑成本。去年夏天我的度假胜地本来是塔希提岛[1]，直到我考虑了它的开销，正是由于这一点，其他地点的优先级上升。所以要优先考虑每个故事的成本，故事的成本是由开发人员估算给出的。每个故事都有一个故事点数的估算，它显式表明这个故事相对于其他故事的规模大小和复杂性。因此，估算有4点的故事是2点的故事的两倍。

通过给发布中的迭代分配故事来逐步构建发布计划。开发人员说明他们预期的速率，也就是他们认为每次迭代完成的故事点的数量。然后客户将故事分配到迭代，确保分配给每次迭代的故事点的数量不会超过预期的团队速率。

例如，假设表1.1列出了项目中所有的故事，它们按照降序排列。团队估算每次迭代的速率为13点。故事将被分配到迭代，如表1.2所示。

因为团队期望的速率是13，所以没有迭代的计划超过13点。这意味着第2和第3次迭代计划只有12点。不要担心评估的精确性不够精确，如果开发人员的速率比计划的要快，他们会要求再加一两个小故事。注意，在第3次迭代中，客户团队实际上选择了将故事J包含在更高优先级的故事中，这是因为故事I 是5点，太大了，无法包含在第3次迭代中。

表1.1  示例故事和成本

表1.2  表1.1中故事的发布计划

可以暂时跳过大故事，在迭代中放入更小故事的替代方法，是把大的故事拆分成两个故事。假设5点的故事I我可以拆分成故事Y（3点）和故事Z（2点）。故事Y包含了旧故事中最重要的部分，可以适合第3次迭代，如表1.3所示。关于如何和何时拆分故事的建议请参见第2章和第7章。

表1.3  拆分故事创建一个更好的发布计划