管理层喜欢他们的指标。他们的想法是这样的：“我们需要一个数字来衡量我们的工作情况。数字可以让人们集中注意力，并帮助我们衡量成功。” 虽然出发点是好的，但用数字进行管理会无意中导致有问题的行为，并最终损害更广泛的项目和组织目标。指标本身并不是一件坏事；只是经常被不恰当地使用。本文论述了管理层传统使用指标所造成的许多问题，并提供了一种解决这些问题的替代方案。

在商务会议中，通常通过比较平均值来比较几组数字。但这样做往往会掩盖这些组中数字分布的重要信息。有许多数据可视化方法可以揭示这些信息。这些方法包括条形图、直方图、密度图、箱线图和小提琴图。这些方法很容易用免费软件生成，可以处理小到十几组，大到几千组的数据。

衡量开发人员的生产力是一项艰巨的挑战。传统的指标侧重于开发周期时间和吞吐量，这些指标是有限的，而且对于从哪里寻找其他指标也没有明显的答案。定性指标提供了一种强大的方法，可以使用从开发人员自身获得的数据来衡量和理解开发人员的生产力。组织应该优先使用来自人的数据来衡量开发人员的生产力，而不是使用来自系统的数据。

我们看到关于软件过程、设计实践等的讨论充满了情绪化。许多争论是不可能解决的，因为软件行业缺乏衡量软件开发效率的一些基本要素的能力。特别是，我们没有办法合理地衡量生产力。

技术债务 是一个非常有用的概念，但它提出了一个问题：如何衡量它？遗憾的是，技术债务不像金融债务，所以很难说你欠了多少债（尽管我们最近似乎在衡量金融债务方面遇到了一些麻烦）。

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

-- 任何尝试过的人

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

在我的职业生涯中，我听到过很多关于函数应该有多长的争论。这是一个更重要的问题的代理问题——什么时候我们应该将代码封装在它自己的函数中？其中一些准则是基于长度的，例如函数的长度应该不超过一个屏幕。有些是基于重用的——任何使用超过一次的代码都应该放在它自己的函数中，但只使用一次的代码应该保持内联。对我来说，最有道理的论点是意图和实现的分离。如果你必须花力气去看一段代码才能弄清楚它在做什么，那么你应该把它提取到一个函数中，并根据这个“做什么”来命名这个函数。这样，当你再次阅读它时，函数的用途就会一目了然，而且大多数情况下，你不需要关心函数是如何实现它的用途的——这就是函数的主体。

想象一个团队正在为一个购物网站编写软件。如果我们看这个团队的产出，我们可能会考虑他们在上个季度开发了多少新功能，或者是一个跨职能的衡量标准，比如页面加载时间的减少。然而，结果衡量标准会考虑衡量销售收入的增加，或者产品支持电话数量的减少。关注结果而不是产出，有利于构建更多地提高软件用户和客户效率的功能。

我第一次接触敏捷软件开发是在 极限编程的黎明 与 Kent Beck 一起工作。那个项目给我留下深刻印象的一件事是我们进行计划的方式。这包括一种估算方法，这种方法既轻量级，又比我以前见过的任何方法都更有效。十多年过去了，现在经验丰富的敏捷人士之间出现了一种争论：估算到底值不值得做，或者说估算是否有害。我认为，要回答这个问题，我们必须看看估算将用于什么目的。

我经常听到一种抱怨，说敏捷方法没有一个严格的定义。抱怨者可能会说，这意味着你无法判断一个特定的团队是否在使用敏捷方法。他们也可能会说，这使得教人们如何使用敏捷方法变得很困难——课程是什么？

在某种程度上，我确实感受到了这种抱怨的痛苦——但我接受没有办法解决这个问题。这种缺乏严谨性是敏捷方法定义性质的一部分，是其核心哲学的一部分。

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

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

我时不时地听到有人问他们应该以什么样的测试覆盖率（也称为代码覆盖率）为目标，或者自豪地陈述他们的覆盖率水平。这样的说法没有抓住重点。测试覆盖率是一个有用的工具，可以用来查找代码库中未经测试的部分。测试覆盖率作为一个数字化的指标来衡量你的测试有多好，用处不大。

CHAOS 报告称只有 34% 的项目取得了成功。

Standish 集团的 CHAOS 报告 多年来一直在谈论 IT 项目浪费了数十亿美元。34% 的成功率实际上比 2001 年的 28% 有所提高。但我们所说的“失败”到底是什么意思？