《敏捷开发艺术》第二版

容量

听众

开发人员

我们知道自己能承担多少工作。

使用迭代的团队应该在每次迭代中完成每个故事。但他们怎么知道要完成多少呢？这就需要能力了。能力是对团队在一次迭代中能可靠完成多少任务的预测。

容量仅用于预测下一次迭代中可以包含哪些内容。如果您需要预测特定故事集何时发布，请参阅"预测"。

如果您使用的是持续流而不是迭代，您就不需要担心容量问题。您只需在前一个故事完成后开始新的故事即可。

注意

能力最初被称为速度。我不再使用这个词，因为 "速度 "意味着一种并不存在的控制水平。想想汽车：要提高速度很容易，只需踩下油门踏板。但如果你想提高汽车的容量，就需要做出更大幅度的改变。团队的能力是一样的。不容易改变。

昨天的天气

能力可能是一个有争议的话题。客户希望团队每周交付更多产品。开发人员不想被催促或施加压力。由于客户通常会听取团队发起人的意见，因此他们往往会在短期内获胜......。从长远来看，如果团队迫于压力，不得不承诺超过他们的交付能力，那么每个人都是输家。现实占了上风，开发耗时最终会超过预期。

为避免这些问题，请测量您的容量。不要猜测。不要希望。只需衡量。这很简单：本周你可能会完成与上周相同的工作量。这也被称为 "昨天的天气"，因为你可以用 "今天的天气很可能和昨天一样 "来预测今天的天气。

更具体地说，你的能力就是你在上一次迭代中开始并完全完成的故事数量。部分完成的故事不算在内。例如，如果你在上一次迭代中启动了 7 个故事，并完成了其中 6 个，那么你的能力就是 6 个，你可以在下一次迭代中选择 6 个故事。

注意

不要对多次迭代求平均值。只需使用前一次迭代。"稳定容量 "介绍了如何在不求取平均值的情况下创建稳定容量。

只有在故事大小基本相同的情况下，计数才会起作用。您可以拆分和合并故事，使大小 "恰到好处"，如"拆分和合并故事 "中所述。随着时间的推移，您的团队将学会如何使故事大小相同。

一开始，你的故事可能不会都一样大。在这种情况下，你可以估算你的故事，我将在"估算故事 "中介绍这一点。在使用估算时，要衡量你的能力，可以看看你在上一次迭代中开始并完全完成的故事。将它们的估算值相加。这就是你的能力。

例如，如果您完成了上一次迭代开始的六个故事，它们的估计值分别是 "1、3、2、2、1、3"，那么您的能力就是 1 + 3 + 2 + 2 + 1 + 3 = 12。下一次迭代，你可以选择任何你喜欢的故事，只要它们的估计值总和是 12。

昨日天气 "是一个简单却出人意料的复杂工具。它是一个反馈回路，能产生神奇的效果：如果你的团队低估了自己的工作量，无法在迭代截止日期前完成所有故事，那么你的能力就会下降，下次的工作量就会减少。如果你高估了自己的工作量，提前完成了工作，那么你的团队就会承担更多的故事，其能力就会增加，你就会承担更多的工作。

这是平衡团队工作量的一种极为有效的方法。能力与松弛相结合，能让你可靠地预测每次迭代能完成多少工作。

能力和迭代时间框

昨日天气 "依赖于严格的迭代时限。为了让能力发挥作用，永远不要把迭代结束时还没有 "完成 "的故事计算在内。绝不允许迭代的最后期限有任何闪失，哪怕是几个小时。

你可能会想耍点小聪明，推迟迭代截止日期，或者算上一个快完成的故事。不要这样做！这当然会增加你的工作量，但会破坏反馈回路。你的团队实际能完成的任务会超出你的预期，下一次问题就会扩大，实现承诺也会变得更加困难。

与我共事过的一位项目经理希望在迭代开始时增加几天时间，这样他的团队就能 "一鼓作气"，他也能与经理分享一个更令人印象深刻的能力数字。但这样做的结果是，他的团队注定要失败：在接下来的迭代中跟不上节奏。请记住，容量是用来预测你在一次迭代中能装下多少东西的。它并不代表生产率。 ...