第二章 过程改进，没有灵丹妙药

    我们有责任

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

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

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

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

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

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

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

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

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

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

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

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

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

    标新立异

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

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

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

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