2007年10月1日：“你怎么度量你自己？”

在微软，我们唯命是从，但是否应该有自己的思想？当数十亿的美元投入到生产线上，你最好不要对已做出的决定有什么异议。10年前，我们的产品不是猜想出来的，它们是我们在学习竞争对手成功的产品基础上改进的，我们赢在后来居上。

现在我们在很多领域处在领先地位，没有竞争对手，智囊团们只能凭空遐想。他们的格言是：开发些很酷的玩意儿，希望得到客户的认可。结果是：一地鸡毛，毫无价值或无法理解。

万幸的是，明智的团队不会胡乱猜想。他们依照微软的研究数据及客户数据来认定使客户真正开心或烦扰的因素，并由此提升我们的产品。如果没有这些数据或回馈，我们将陷入绝境。因此，记得通过数据决定我们如何生产我们的产品，那么就会一身轻松。

没那么多尝试

如果出色的团队根据数据生产产品从而消除无端猜想，为什么这种猜想还会左右我们如何生产呢？现今的软件开发过程充满着奇思妙想。“最佳实践”是传统的智慧结晶，过程管理是业内共识，一些自命不凡的敏捷开发方法被当成教条从而取代数据。为什么？

作者注：我最喜欢的敏捷方法，如Scrum及测试驱动开发，都使用数据。测试驱动开发则更甚——它需要以测试通过率为基础。

不要告诉我有数据可以证明某种方法最有效。我不是在谈论某某人的数据，我是在说你的。在发现Bug之前，你怎么知道你的团队使用了正确的方法能得到正确的结果？你怎么知道你们今天就会比昨天更好？为什么你们始终不使用数据来查找问题？

或许是因为软件开发是一种开创性的过程或技艺，它是无法度量的；或许度量就是错误的或容易被不当利用；或许由于你没有充分的数据进行判断；也或许怯懦的狂热者们只愚昧地膜拜于他们所迷信的陈规戒律，他们因为太胆怯而不敢（利用数据来）度量，也太蠢不知道怎么度量。

仅仅把心思放在成熟的好方法上是不够的。如果没有这么多资金及相关人员投入到产品线上，且你又对如何以一种正确的方式使用正确的度量方法一无所知的话，你是无法经受住生命的洗礼的，伙计。幸运的是，你不用非得刨根究底先了解它。

有什么问题

我曾听闻：“你们这些蠢货，你不知道软件度量很恐怖吗？你不知道脑子锈豆的管理者将利用它们来使你与你的同事们，或者让你的团队与另一个做着不同项目的团队相争吗？你不知道它们只是用来冒险一试，而陷你们的工作及客户于水火吗？”是的，我知道。我们早已知道你们对如何恰当使用度量方法一无所知，但既然你提到它了，那就让我们来打消你的顾虑：

软件是一项创新性的工艺，是不可度量的。就像我在第5章中说的：“软件苦旅——从工艺到工程，”工艺对于制造桌子与椅子很管用，但对于一座桥，一个心脏起搏器以及软件来说就不够了。总之，你忽视了其中的区别。准则一是：不要想着怎么度量，而是度量什么。

软件度量是错误的，也容易被不当使用。有些人会这样说：“你度量什么就会来什么。”如果你对每行代码都进行度量，人们就会写出更多糟糕的代码；如果度量修复了多少Bug，那他们就会留下更多的Bug需要修复。准则二是：不要对中间环节进行过多度量分析，只对其期望结果进行度量分析。

有充分的数据能对所有事情做出论断。计算机能产生非常大的数据量，而软件开发是在计算机上进行的。然而，如果这些数据反映的是更多问题而不是答案的话，那它就是没用的，不管那些图表看起来有多美。准则三是：不要只是收集数据而已，使用度量分析解决关键问题。

只有管理者使用数据而不是你。管理者的慵懒众所周知。如果数字告诉了你该做什么，有什么必要把你的想法提交给管理者呢？出色的度量分析工作不是告诉你该怎么做，因为好的度量工作并不是解决怎么做的问题（记得准则一吗？）。准则四是：不要使用度量分析来做决定，而是通过度量分析来使你明白需要做出个决定。

管理者往往做一些不恰当的比较。管理者的无知也众所周知。他们“高屋建瓴”，认为软件是软件，Bug是Bug，完全不拘细节。只把注意力放在期望结果上或许有用，但这往往会带来不正当的相互比较。准则五是：不要只对原生度量进行比较，要有一些基准及范例，它们提供了参照细节。

作者注：我那些在Google及新兴网络公司的朋友会说：“这很简单，把管理者干掉就是了。”好主意。把“管理者”换成“执行官”或“产权人”，你会面临同样的问题。

现在就让我们按照以上准则按部就班。

怎么回事

准则一：不要想着怎么度量，而是度量什么。

人们都讨厌被迫按某一模式工作。没错，他们会乐于接受一些指点及建议，他们也愿意接受一些约束及要求，但是没人愿意成为一个（模式化的）机器人。

当一个人开始一项任务时，可以肯定他们已经知道有办法可以更好地解决问题。强迫人们按你的方式工作，而不是他们自己的，那当你的方式比他们的差时，这种不良后果就可能发生。这样就会让他们产生挫败感，他们会憎恨你，蔑视你，认为你愚蠢。

如果对你希望事情怎么做进行度量分析就等于说你要求人们怎么做。这样就把你树立成为了一个让人憎恨又蔑视的蠢人了。我可不建议这样。

相反，你要对希望完成些什么进行度量分析而把怎么完成留给明白人。只要说明你希望一段脚本运行良好，而不是度量需求规格完成情况、功能点情况或还剩下多少Bug（这都是关于“怎么做”的），而是把这些脚本分解成片段再分析有多少脚本片段及这些片段之间衔接起来是否能按预期运行。理想情况下，你需要一个客户来当你的评判，但如果有一个独立的测试者也可以了。

最后，你得感谢我

准则二：不要对中间环节进行过多度量分析，而只对其期望结果进行度量分析。

软件度量被过度利用了。我们都了解软件度量，大多数人都用过。为什么？因为管理者掌控着软件度量标准。如果你没有达到其度量标准，你的头儿就会从地洞里冒出来冲你发火。这样就让目标变成“完成你的度量标准”而不是“完成你的目标”。

如何能避免以软件度量指标为准而不是以目标为准这样的陷阱？有两种方法：

不要使用软件度量，愚者自乐。将你的目标与软件度量目标等同起来。

想想你团队的目标。他们真正追求的是什么？当你们作为一个团队要有什么成果？你们要努力完成什么？对期望结果进行度量分析。那么怎么达到那些度量标准（合理的标准）就不成问题了，因为达到这些标准就是你们真正想要的。

作者注：将这一节再仔细读读。可叹的是很多人并不理解这一点。

我现在就想知道

稍等片刻，一名惊恐的管理者有个问题：“如果我只对最终结果进行测评，那如何保证我们总是能得到这样的结果呢？”这个问题问得很好。成功的软件开发没有一次不是步步为营的——先以跬步，并时刻监测你们是否保持在正确的轨道上，再接着走下一步。但如果你只是对结果进行分析，那如何能保证你在正确的轨道上呢？

有两种方法可以始终警示你，使你的工作始终围绕着期望的结果进行：使每一小步都小有成果。这是敏捷方法的最好方式及基本概念。只要在每次阶段性工作中都能为客户提供其价值，就可以通过客户来经常性地监测你是否保持在正确的轨道上。你的软件度量方法注重度量客户想要的结果（如可用性、完整性及稳定性）。

使用一些与期望结果紧密相关的预测方法。这种方法并不是很好，因为这种相关性从来都不完美。然而，一些“最终结果”直到最后也不能进行准确测定，所以用一些预测方法是需要的（如在第5章中说的“工程质量的大胆预测”）。如果你必须使用预测分析，那么始终把它们当成是对真实结果分析的基础从而确保你正在向你所想的目标前进。

按需索取

准则三：不要只是收集数据而已，使用度量分析解决关键问题。

软件开发，毋庸置疑，会产生海量的数据——软件构建消息、测试结果、Bug、可用性研究、编译警告、运行时错误及断言、时间表信息（包括实施进程图）、源代码控制统计，等等。作为一个软件工程师，你或许已经将这些数据制成报表并产生数据图表。那很好，祝贺你！

确实该祝贺你吗？不，不，过犹不及。在一个人员嘈杂的大商场，你很难听清他人的交谈，事实上你根本没听清。你的大脑都把这些列为噪音并加以屏蔽。对于一堆杂乱的数据来说也是这样。

按需收集数据，不要一整堆铺天盖地地扔过来。相反，关注你真正想要的。你关心哪些关键属性？有些人称之为关键质量信息（CTQ）或关键性能指标（KPI）。你需要一种浓缩的精华，即关键又通用的CTQ。

一些CTQ对于你的产品是特定的。比如你正在从事一项有关无线网络的项目，其目标是建立一个快速又稳健的网络连接，那么你的CTQ就是网络连接时间及平均在线时间。

而另一些软件开发的CTQ则是共性的。如果你追求精益（我希望你是这样的），你就关心最小开发周期，你的CTQ可能就是完成一段脚本所需要的时间；如果你追求工程质量（我同样希望你是这样），你可能就关心代码的稳定性。你的CTQ应该是一种预测指标，像代码返修率或复杂度，及一个更精准的指标，像Watson警示。

作者注：当一个Windows应用程序崩溃时你将看到一个错误报告对话框，Watson是其背后机理的内部命名。

我们有责任

准则四：不要使用度量分析做决定，而是通过度量分析使你明白需要做出个决定。

我想对一些员工最大的担忧就是他们将度量指标仅仅当成是一个个数字。我在一个专栏里阐述过这种误解，“不仅仅是数字——是生产力”（见第9章）。如果你的审查过程及成就仅仅归因于某种公式，那问题就严重了。

对于所有的决策来说同样如此。如果这个决策也基于一种公式做出，缺少应有的思考与顾虑，那么我们就成为了工序及工具的奴隶。那是本末倒置。工序及工具只为我们所用，而不是我们为它们所用。

幸运的是，如果你遵从前面的法则，只对你的期望结果进行评测，那么你的管理层就无法用那些指标来进行决策。是的，如果你总是没得出团队的期望结果，管理层可要你好看，这也是你应有之责。然而，因为所有管理者所获得的都是最终结果，你就不必明了为什么你没得出这些结果或者由谁或其他什么对此负责。他们（管理层）就必须进行调查、理解及分析。他们就必须在得出结论前进行必要分析。

完善的度量指标让你知道你遇到了问题。它们无法也不应告诉你为什么（有这些问题）。分析根本性原因需要仔细研究。如果有人说他可以从数据指标中轻易找出答案，那么就是在撒谎。

每个女孩都应有自己的风格

准则五：不要只对原生度量进行比较，要有一些基准及范例，它们提供了参照细节。

等等，一个惊恐的工程师有个问题：“好吧，那我们以分析一次结果是否合意为例，如完工的脚本量，相对于其他团队，我们的功能团队只完成了一半的脚本量，那我们的管理层就会要求我们花更多的时间努力赶工，即使我们的脚本相对要复杂得多。使用‘确切’的度量却使我们更加悲惨！”这是一个很不错的想法。但我有一些好消息及坏消息。

好消息是管理者确实在试图解决问题（正确的度量指标是有益的）。坏消息是管理者并没明白问题出在哪里。他们不会分析问题的根本原因（因为复杂庞大的脚本），他们认定问题出在偷懒的工程师身上。你要提供必要的参照帮你的管理者进行分析。

最方便且最好的参照是一些基准及范例。

基准会让你明白从度量指标中你需要什么。你最初获得的结果的度量指标就是基准，自此以后，通过与这些基准进行比较你就知道你如何会做得更好或更差。如果你的基准本身就很庞杂，你的管理者对你的脚本就不会有所惊奇了。

使用基准对于你不断地提升工作质量是很有用的。

范例会让你明白你的工作成果要达到什么程度。范例是应用软件度量得出的最佳结果。不必关心范例是怎么完成的或是哪个团队完成的。你的成果与它之间的差别就是你需要改进的地方。“但是如果他们盗用范例快速地完成脚本怎么办？”如果脚本符合质量标准，那么他们就没有盗用，而是他们找到了更好的方法。“但是如果我们的脚本比范例更庞大更复杂怎么办？”那么，你应该将它们分拆使之简化。记住，你是在度量一种期望结果，如果你真希望快速地为客户提供价值，你就必须使你的代码块既小又能快速地完成。要使你们工作水准获得最大的提高，使用范例是极其省事的。

标新立异

那么，你现在知道了软件度量是分析什么及怎么分析的，也知道正确的软件度量与错误的软件度量之间的区别，也知道忽视软件度量会使你感觉轻松但会显得很无知。忽视软件度量会使软件开发成为一个猜谜游戏从而使成功成为一种偶然。我认为，对这种轻视的委婉称法就是：愚蠢。

然而，你也注意到了，好的软件度量方法只对期望结果进行了分析，这样的做法并不通用。你不能只是简单地将之应用于每个项目上。确实，你还希望有符合工程质量及效率要求的结果指标（如生产率、可靠性、稳定性及责任度），但其他的指标如性能、可用性及所有有关客户价值的东西依赖于你所期望的脚本质量及客户需求。

这就意味着，将适当的度量方法用在适当的地方并不是多余的。这需要从团队的角度出发来决定某个版本中什么是你们真正关心的问题以及你们怎么知道你们已经达到了目标。因此，从一开始你们要使这些度量工作成为工作中每个步骤及客户回馈的一部分，从而保证你们正在朝正确的方向前行。言过其实吧，是吗？事情确实会向预期的目标前行吗？或许我是个神经过敏的傻蛋。

作者注：以我个人的看法，我相信测试部门在定义并监督软件度量上具有很大的作用。他们按数据说话，并以客户的角度来使用软件。关键是，测试者的工作要放在度量期望结果上，而不是建一张张的图表，制造干扰。