14.4  承诺驱动的迭代规划

承诺驱动是规划一次迭代的另一种方法。承诺驱动的迭代规划包含许多与速度驱动的迭代规划相同的步骤。但是，它不是使用“昨日天气”的方法来确定在当前迭代中应该规划多少个故事点或是理想日，而是要求开发小组把用户故事逐个添加到迭代中，直到他们无法承诺完成更多的故事。图14-3显示了整个承诺驱动的迭代规划方法。

图14-3  承诺驱动的迭代规划中的活动

最开始的步骤—— 调整优先级和确定迭代目标—— 与速度驱动的方法中的步骤是一样的。接下来的步骤，选择一个要增加的用户故事，就不一样了。产品所有者和开发小组仍然选择支持迭代目标的具有最高优先级的故事。但是，在承诺驱动的迭代规划中，用户故事被选中并分解成任务，每次都是对一个用户故事的任务进行估计。这与速度驱动的方法是不同的，在那种方法中选择的用户故事的估计值之和等于估计的速度。

每次只选择一个用户故事是因为在把每个故事分解成任务并进行估计之后，小组需要确定他们能否承诺在迭代中交付这个故事。

要求小组做出承诺

Larson与LaFasto(1989)在他们关于什么使小组取得成功的研究中，认定由所有小组成员共同做出的统一的承诺是引向小组成功的关键因素之一。在一次迭代规划会议中，我问开发小组：“你们可以承诺交付我们已经讨论过的功能吗？”请注意我问的不是：“你们可以承诺交付我们已经确认的任务吗？”这是一个完全不同的问题，也是一个要弱得多的承诺，因为它承诺的是完成一组任务而不是承诺的交付新功能。

如果在迭代中发现了新的任务(几乎肯定会发现)，一个承诺交付特定用户故事所描述的功能的小组会尽力同样完成这些新的任务。而只对一组已经确定的任务做出承诺的小组则可能不会完成。两种情况下，新发现的任务都有可能要花太长的时间而不能在当次迭代中完成。这时，开发小组需要和产品所有者讨论这个情况，寻找是否有别的方法来达到迭代目标；他们也许会需要减少某个用户故事的功能或者完全放弃它。

每把一个用户故事分解成任务并对这些任务做出估计，我就会问小组能否做出承诺。对第一个用户故事，这个问题大多数时候看起来很愚蠢。小组中可能有7个人，计划使用2周的迭代长度。可能他们目前只确定了34个小时的工作，而我在问他们能否做出承诺。他们的答复(要么是说出来的，要么是通过脸上困惑的表情表达的)是：“我们当然可以承诺这个。我们有7个人干2周，而这里只有34个小时的工作。”但是，随着会议的进展，越来越多的用户故事被加到迭代中，要回答我这个“你们能够承诺吗？”的问题，就开始需要一些思考了。我们最终会达到某个时刻，小组不能再做出更多的承诺了。如果他们不能再承诺了，也许他们会选择在结束前放弃一个用户故事，并用一个稍小的来代替它。

1. 对估计值求和

我发现一个小组要确定他们能否对一组用户故事做出承诺，最好的办法是把对任务的估计值求和，看看它所代表的工作量是否合理。在某些任务上可能会有相当大量的不确定性，因为并没有对工作进行设计，而且需求也是模糊的。但是，对估计值求和总可以在一定程度上预示总工作量。

假设一个有7个人的小组采用2周的迭代周期。他们每次迭代就有560个小时可用(7人×10天×8小时/天)。我们知道这些时间中的一部分将会花在任务卡片没有显示出来的活动上—— 回复电子邮件、参加会议，等等。与之相似，我们还知道对任务的估计值是错误的；他们毕竟只是估计而不是保证。因为这些原因，我们不能期望小组会签订560个小时的任务。实际上，大多数小组在计划每天4～6个小时的工作量(任务卡片的和)的时候能够取得成功。对我们这支7个人的小组，采用2周的迭代长度意味着他们可能可以规划280～420个小时的工作。小组会在这个范围中的哪一点结束，取决于他们对特定用户故事的任务确定的程度、对这些任务进行估计的准确度、小组成员做出的外部承诺(译者注：即与项目本身无关的工作或承诺)量，以及小组的一般系统开销的大小。可能最少只需两次迭代之后，大多数小组就开始认识到他们每次迭代中大约应该规划多少个小时的任务。

在对一次迭代的工作做出承诺之前，开发小组需要看一下任务，感觉一下它们所代表的工作量分布对小组成员所具备的各种技能是否合适。是不是Java程序员可能会工作过重，而HTML程序员在这次迭代中无事可做？选定的用户故事是否容易编写，但是测试时间过长或者难以测试而让测试人员超负荷了？是不是每个选中的故事在编码前都需要分析师和用户交互设计师的工作？

处于这种情况下的开发小组应该首先尝试找到可以更好地分摊工作的办法。这个例子中的HTML程序员能不能去帮助测试人员？除了用户交互设计师以外，有没有别的人可以做这项工作？如果没有的话，我们能不能在这次迭代中少考虑一些需要用户交互设计的用户故事，引进其他一些不需要交互设计的故事？关键在于让小组中的每个人都有责任做出他们力所能及的贡献，而不管这是不是他们的专长。

个人承诺

在对承诺完成一组新功能的能力进行评估时，有的小组倾向于把每项任务分配给特定的人，然后评估每个人是否能够对该数量的工作做出承诺。这个方法相当有效，我过去也曾推荐过它(Cohn 2004)。但是，我发现不在规划迭代时分配任务，也不要进行做出个人承诺时所需的个人能力计算，可以让小组建立“我们是一个整体”的思维方式并从中受益。

如果您发现确实需要在规划一次迭代时把工作分配给个人，应该把这种分配看作是暂时的，一旦迭代开始进行就可能会发生改变。

2. 维护与承诺

除了在项目中取得进展，很多小组还要负责支持和维护另一个系统。那个系统可能是他们正在处理的产品的上一个版本，也可能是一个无关的系统。当小组承诺在一次迭代中完成一组用户故事的时候，他们需要同时考虑在维护和支持工作方面的负担。我所指的并不是可以提前确定优先级的常规的除错。这些工作应该经历常规的迭代规划中的确定优先级过程。我所说的维护和支持活动，指的是那些无法预测但是占据了很多小组的一部分时间的工作—— 支持一个产品网站或者数据库、接听关键客户的支持电话、或是第一层的技术支持，等等。

我把一次迭代看作是一个空杯子。首先倒进去的是小组做出的不可改变的承诺，例如对其他产品的支持和维护工作。杯子中剩下的才是小组可以用于对迭代中的工作做出承诺的空间。图14-4显示了这种情况。显然，与杯子一开始就被占用了90％的小组相比，杯子中的10％被支持工作占用的小组可以承诺更多的工作时间。

图14-4  其他的承诺决定了一支小组在迭代中能做出多少承诺

在大多数情况下，开发小组无法很准确地预测接下来要承担的支持工作负荷。他们应该知道一个长期的平均值，但是平均每周20小时的支持工作与每周都要进行20小时的支持工作是不一样的。如果在一次迭代中支持和维护工作的负担超过了预期值，他们可能就无法实现他们的承诺。他们需要在支持和维护负担比预期轻的迭代中超越做出的承诺，才能弥补这个问题。对具有显著的支持和维护职责的小组来说，这种可变性是不可避免的。