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

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

    最后，你得感谢我

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

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

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

    不要使用软件度量，愚者自乐。

    将你的目标与软件度量目标等同起来。

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

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

    我现在就想知道

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

    有两种方法可以始终警示你，使你的工作始终围绕着期望的结果进行：

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

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

    按需索取

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

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

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

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

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

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

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