前言

在软件这个行当里，我们看到的度量数据大都是来自于一些衍生性的指标。在缺乏上下文的情况下，这些指标通常都不能直接告诉我们到底发生了什么，也就是说，大部分指标数据都只是一些间接的证据。将这些证据关联到我们想要度量的对象上，靠的是我们这些人根据经验做出的判断。这种判断具有相当的主观成分，即使是最靠近现场的人，这种判断很多也是在证据不完备的情况下做出的。当有人告诉你，这个团队平均每人每天完成300行代码的时候，你能对这个团队的效率做出什么判断吗？如果你能做出判断，那你绝对能配得上先知的称号，你还不知道这个团队用的是汇编语言、C、C++、Java还是Ruby，你不知道这个产品的类型是操作系统、电信嵌入式软件、商用软件包、定制软件还是网页脚本，你也不知道这个数字的统计是包含软件开发周期的哪些阶段——只是开发阶段，还是包含了分析、设计、开发、测试和维护支持所有的活动。

我本人原来一直对度量抱着嗤之以鼻的态度，觉得那是领导们获得虚假的安全感、满足控制欲的皇帝新衣。不过在过去几年里，遇到了不少的各种软件开发组织，从产品线总裁到一线开发、测试人员，到为产品掏钱的客户，各种人物一次又一次地问我:

“我感觉我们是有进步，但我们的进步到底有多少啊？”

“我怎么拿出点实实在在的证据告诉我老板，我们比以前做得更好了？”

“我要的是效率、效率、效率，告诉我，如果你干了这事儿，效率能提升多少？”

“反正都要测试，你能告诉我们这所谓的新方法对质量能带来什么不同的效果吗？”

这个问题的列表可以不断加长，一开始遇到这类问题的时候，我一边心里嘀咕“谁关心就到现场看看不就行了”，一边嘴上顾左右而言他。到了后来，次数多了，我也不得不重新反思，度量这事儿，既然有这么强烈而广泛的需求，必然有其存在的道理，有其创造的价值。这就好像我们经常在财经新闻里看到的经济指标一样，什么GDP、CPI，什么货币供应M0、M1、M2，这个采购经理人指数，那个行业景气指数，这些数据本身的准确性和它们能够对经济现状的反应程度都有很多的局限性，但不管是政府还是投资客，却要使用这些数据来做出干预市场或是投资市场的判断。这使得我开始思考，软件开发的度量可能也并不是那么不靠谱的一件事，其实同样也是人们梳理复杂问题的分析线索，尝试接近真相的努力。于是就开始不断地根据不同人员的诉求，摸索着尝试各种度量手段，在这个摸索过程中，对度量的价值和方式也有了一些自己的认识，希望在此能和更多的同行分享和讨论。

本书并不试图描述一个完整的软件度量体系，也不会试图解决度量所面临的所有问题，只是从精益理念的角度，尝试重新梳理在中等规模到大规模软件开发中度量体系设计和实施的思路。

读者对象

可能对本书感兴趣的读者如下。

●希望引入持续改进的IT/软件企业和组织、软件产品研发组织的管理者。

●希望实施敏捷、精益理念的软件开发组织管理人员。

●希望扩展知识面和工具箱的软件项目管理人员。

●其他希望了解大型项目工程管理的软件从业人员。

●有一定软件工程基础的高校教师和高年级学生。

如何阅读本书

本书的结构主要分为3部分，如下所述。

第一部分介绍精益软件开发的度量理念和体系的设计，包括第1章至第4章。

●第1章重点阐述了本书基于的精益软件开发的度量理念。

●第2章至第4章则从度量体系的目标、软件生命周期中涉及的决策场景，以及指标框架的设计3个阶段来描述体系的建立。

第二部分是度量维度的分析，包括第5章至第12章。

●第5章试图描述流程模型、对象模型等几个软件度量中涉及的基本概念，包括对需求和功能划分单位的理解，以及对功能完成的定义。

●在第6章至第12章则是深入分析交付价值、市场响应速度、交付速率、质量和能力等几个主要的考察维度。

第三部分是度量体系的导入与部署。

●第13章和第14章用案例的方式，分别展示了一个体系在导入验证阶段的准备和执行工作。

●在第15章，也是最后一章里，尝试初步探讨在一个组织范围内，如何部署和推广一个新的度量体系。

大家可以根据自己的兴趣重点阅读，也可以根据索引作为工具书查阅，当然我个人还是相信，从头阅读能够使大家对这个主题有一个更加系统化的图景。