我们看到很多关于软件流程、设计实践等的激烈讨论。许多争论都无法解决，因为软件行业缺乏衡量软件开发效率的一些基本要素的能力。特别是，我们没有办法合理地衡量生产力。

你不能把十磅重的屎放进一个五磅重的袋子里

-- 任何尝试过的人

当 Kent 和我写《规划极限编程》时，我们加入了这句异想天开的引言，以帮助理解计划的本质。

许多人认为，在敏捷项目中不能签订固定价格合同。由于敏捷流程的重点是无法预测未来，因此这种假设并非没有道理。然而，这并不意味着你不能达成一份固定价格的敏捷合同，它真正意味着的是，你不能达成一份固定范围的合同。

许多公司喜欢签订固定范围和价格的合同，因为他们认为这降低了他们的风险。这种幻觉认为，他们的财务义务被固定在交易价格上。如果他们没有得到满意的软件，那么他们也不需要为此付出代价。

理想时间是早期极限编程中用来帮助估算工作量的一个术语。现在它已经被故事点或故事计数所取代。

我第一次接触敏捷软件开发是在极限编程的初期与 Kent Beck 一起工作。令我印象深刻的一件事是我们进行计划的方式。这包括一种估算方法，它既轻量级，又比我以前见过的任何方法都更有效。十多年过去了，现在经验丰富的敏捷主义者之间出现了一种争论，即估算是否值得做，或者说它实际上是有害的。我认为要回答这个问题，我们必须看看估算的目的是什么。

时间盒迭代的一种常见方法是为每次迭代分配尽可能多的用户故事，以便最大限度地利用相关人员。闲置时间是一种策略，即故意留出未分配给故事的时间，将这些时间用于计划外的工作。虽然这看起来效率低下，但它通常会显著提高团队的生产力。

我最近听到了一些关于为使用极限编程计划方法的多个团队制定标准故事点机制的问题。他们希望让所有团队都使用等效的故事点，这样在一个团队中三个故事点的工作量与在另一个团队中是相同的。

我认为，试图做到这一点往好了说是价值有限，往坏了说是危险的。

故事计数是一种用于计划和估算的技术。与故事点类似，它与极限编程速度一起工作，帮助你计算出在固定时间段内可以交付多少个故事。然而，它的不同之处在于，你只考虑每个时间单位的故事数量，而（大部分）忽略它们的相对大小。

故事点是在敏捷项目中衡量故事大小的常用名称。结合极限编程速度，它们提供了一种技术，通过预测故事何时可以完成来辅助计划。

如果你正在使用极限编程风格的计划，你需要从开发人员那里获得快速的共识估算。快速估算可以让你快速判断开发人员对估算是否有相似的看法（这样你就可以记下来并继续进行），或者是否存在分歧（当你需要更详细地讨论用户故事时）。

速度是一个概念，它通过将广泛的工作量陈述与经过的时间联系起来，帮助校准计划。速度是指一个团队（如果是个人速度，则指个人）在一段时间内完成的工作量。你通常应该通过测量过去一段时间内完成的工作量来确定速度，遵循昨日天气的原则。一种典型的方法是将过去三个时间段的速度平均，以确定未来时间段的速度。速度最初是作为极限编程的一部分而形成的，但后来得到了推广，现在广泛应用于各种形式的敏捷软件开发中。

这条原则说的是，你今天完成的工作量将与你昨天完成的工作量一样多。在迭代项目中，它表示你应该计划在本次迭代中完成与上次迭代相同的工作量。这个术语来自极限编程社区。