详情
本书从一位软件项目实践者的角度进行观察和思考，详细剖析了软件度量的各个方面，帮助读者更深入地认识软件度量的定义、目标、方法和实践，同时提供了很多思考，以及提供了众多可借鉴的操作方法、方式，甚至工具模型。
精益软件度量：实践者的观察与思考
人民邮电出版社
北京
图书在版编目（CIP）数据
精益软件度量：实践者的观察与思考/张松著. --北京：人民邮电出版社，2013.4
ISBN 978-7-115-30883-2
Ⅰ.①精… Ⅱ.①张… Ⅲ.①软件工程—研究 Ⅳ.①TP311.5
中国版本图书馆CIP数据核字（2013）第016176号
内容提要
软件度量是当今软件开发行业的热点话题，但同时也是推广实施过程中的难题。一方面软件企业管理存在度量的迫切需求；另一方面，企业在推行软件度量的实践中问题颇多，效果不佳。人们迫切需要破解度量谜题，找到切实可行的软件度量实践方法。
本书并不试图描述一个完整的软件度量体系，也不会试图解决度量所面临的所有问题，只是从精益理念的角度，尝试重新梳理在中等规模到大规模软件开发中度量体系设计和实施的思路。全书分为3部分，共14章。第一部分包括第1章至第4章，介绍了精益软件开发中度量的理念和体系的设计。第二部分包括第5章至第12章，先阐述了流程建模、需求和功能划分的一些概念，然后分别从交付价值、市场响应速度、交付速率、质量和能力几方面探讨了度量维度的问题。第三部分包括第13章至第15章，介绍度量体系的导入和部署。前两章用案例的方式介绍了度量体系验证阶段的准备和工作，第15章初步探讨了如何在组织范围内部署和推广度量体系。
本书是作者结合自己在软件开发和项目咨询业界十几年的实践经验，针对软件度量的价值和意义、手段和方法、体系和实践的思考反思之作。本书对于软件企业和组织管理者、软件产品研发管理者、软件项目管理人员有很好的借鉴意义和启发价值，也可以供高等院校从事软件工程和软件度量研究和教学的老师阅读参考。
精益软件度量——实践者的观察与思考
◆著 张松
责任编辑 陈冀康
◆人民邮电出版社出版发行 北京市崇文区夕照寺街14号
邮编 100061 电子函件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
北京捷迅佳彩印刷有限公司印刷
◆开本：700×1000 1/16
印张：16.5
字数：237千字 2013年5月第1版
印数：1-3000册 2013年5月北京第1次印刷
ISBN 978-7-115-30883-2
定价：59.00元
读者服务热线：（010）67132692 印装质量热线：（010）67129223
反盜版热线：（010）67171154
管理学大师彼得·德鲁克曾经说过“你如果无法度量它，就无法管理它”（“It you cant measure it, you cant manage it”）。要想有效管理，就难以绕开度量的问题。
可实际上人们总是倾向于关注容易度量的元素，而忽略难以度量的元素。容易度量的不一定是重要的，难以度量的反而可能是重要的。
软件开发的过程中就是这样。
Martin Fowler曾经说过，软件行业至今还没有找到一个可以有效度量软件开发生产效率（Productivity）的方法。想要度量生产效率，首先需要有可以量化的产出物。而软件的产出物是什么呢？人们最直观的结论是一行行的代码。可实际上代码行数的多少并不代表价值的多少，甚至代码产生的功能都不一定是。这些功能运行起来产生的业务价值才是真正的产出，而这又是难以度量的。Standish Group Study的一份报告就指出：45%的代码在运营当中是从来不会被使用到的。最简单直接地对代码行数进行度量实际上是舍本逐末。
度量也是一把双刃剑。度量具有极强的引导性。它会激励你重视并改善能够度量的元素，但也可能使你忽视无法度量的元素并使之恶化。
我曾经在有些软件开发的组织里看到过用代码行数的度量来考核开发人员。结果是产生了很多副作用，大量的复制，不舍理的设计，产生了大量冗佘的代码，不但难以理解和维护，甚至没有在实际运行中运营起来。这在造成大量浪费的同时，也造成了软件质量的严重恶化。
软件开发方法，尤其是敏捷开发方法，正在越来越多地借鉴精益生产中的管理理念，其中主要的核心就是持续改进。要想持续改进，除了对改进方向的经验性认识以外，可以量化的改进目标也是一个无法回避的环节。在大规模实施精益管理的过程中，如何找到舍理的度量，并舍理利用这些度量，始终是一个难题。
国內外的很多企业在实施敏捷精益软件开发方法的过程中，在不同的情况下使用了不同的方法尝试解决这个难题，也产生了很多有效的和创造性的解决方案。可惜的是，很多优秀的想法只是在很小的范围內产生了影响，并没有被提炼出来，并广为人知。
很高兴终于看到本书能够提炼汇总这些实践，形成一个比较完整的精益度量体系。
张松有着国內外软件行业的从业背景，十几年来一直沉浸在敏捷精益实施的第一线，参与了众多大小企业的转型实践，作为许多CIO和CTO的专家顾问，在这个领域积累了大量实战经验。我想不出有更舍适的人来写这本书了！
感谢张松在忙碌的工作中抽出时间来完成这项工作，相信所有读到这本书的人都能从精益度量体系和这些实践案例中有所借鉴。
ThoughtWorks大中国区董事总经理 郭晓
对于敏捷和精益产品开发，度量是一个容易引发争议却无法绕过的话题。讨论它并不容易，需要综舍产品的设计、开发、营销，以及项目和组织的管理运营等多方面的因素来考虑。正因为此，我相信由张松来讨论这个话题再舍适不过。一方面，张松的实践经验从相对传统的电信和金融行业跨越到互联网前沿等诸多领域，职能也从软件开发跨越到组织运营的诸多方面；另一方面，近年来张松作为ThoughtWorks咨询师和团队管理者，在敏捷和精益实施方面进行了持续的探索、实践和总结。
有效的度量体系首先应该是面向价值的。度量的目的不是“控制”，而是改进价值交付能力。本书从价值的定义出发构建度量体系，涵盖价值交付的灵活性、速率、质量，以及组织的价值交付能力。软件开发是一个复杂的系统，度量同样也不简单，作者始终以精益思想和系统思考为指导，为我们呈现了一个端到端的、系统的、面向价值的度量体系。
好的度量体系更应该是面向实施的。本书的理论全部提炼自作者的亲身实践，在前两个部分（第1章至第12章），作者一梁一柱、一砖一瓦地构建度量体系，虽然系统性强，但多少有些枯燥。到了第三部分（最后3章），作者开始讨论度量体系的导入和部署，此时读者会发现，原来所有的理论都将落实到实践，并且有现实案例的支持，一切都是那样自然，仿佛度量本来就应该是这样。
刚拿到书稿时，我担心它的受众有限。一线的实践者，如敏捷开发的实施者往往并不关注度量；而对于还未开始实施敏捷和精益开发的朋友，书中的概念又太过超前。读完书稿，再去反思这个问题，我深知本书的价值所在。对于实践者，本书提供了全新的视角从本源去反思相关实践的效用，为进一步改进方向寻求切实的依据；对于正在评估和计划实施敏捷和精益开发的朋友，本书是传统和精益、敏捷之间沟通的桥梁，它没有直接推荐具体实践，而是引导大家从价值去反思，我们需要什么样的改进，如何设定改进的目标，评估改进的效果，并为实施的动态计划和调整提供可靠的依据。
希望你和我一样喜欢这本书，在阅读过程中和作者一起思考、总结，在实践中完善、提升。
上海贝尔有限公司软件开发团队负责人 何勉
软件项目、软件组织和软件专业人士的度量是一个由来已久的难题。
当ISO、CMM等“重量级”管理方法占据言论主导地位时，我们看到管理者们拿出条目繁多的度量方法和KPI，试图量化员工的工作绩效；与此同时员工们却一边抱怨冗杂的报告和数据表，一边行之有效地找到了敷衍“上头”使他们不再干扰自己正常工作的妙策，顺便——借由呆伯特漫画——嘲笑高高在上不知民间疾苦的管理者们。
而当SCRUM、看板之类“敏捷”方法甚嚣尘上，被一句“人和交互重于流程和工具”激励起来的程序员们高声喊出“我们不要文档/度量/KPI，我们交付可工作的软件”；而——绝非邪恶的——软件组织领导者们，则郁结于如何在更大范围、更长周期了解员工和团队的状态和能力水平。毕竟，如果连“全局”究竟是什么样子都无法看到，“全局优化”就只能是一句空话。
我无意在此引发又一轮软件方法学之争，只想提醒读者的注意：对于度量这件事，我们这个行业存在着如此明显的张力，使得任何一位严肃的领导者乃至从业者都无法也不该忽视其中的挑战。一方面，所有人都赞同：“好的”度量对组织以及个人都将大有裨益；另一方面，真正找到“好的”度量方法者寥寥。这个问题的解决，需要丰富的软件、工程、管理乃至商业理论与实践经验的深度结舍，并且需要在实际的运用中不断改善精炼。
在所有探索有效软件度量方法的尝试中，本书是一本开创性的佳作。从精益软件开发入手，作者首先建立了一个适用于现代软件组织的度量体系。基于这个体系，作者介绍了如何对软件的价值、速度、质量等每个软件组织都高度重视的核心要素进行有效度量。
如果前面这些还是其他著作也有所提及的內容，接下来的部分就是极具开创性，而且极具价值的思考与经验了。除了软件交付的“业务”本身，作者专章论述了如何对软件组织及从业者个人的能力进行度量，并给出了建设学习型组织、持续提升组织和个人能力的指导。最后，作者还以可观的篇幅讲述如何在一个“传统”的软件组织中引入这些精益度量方法，以度量的植入来拉动软件组织的精益转型。这种饱经思辨又与实践紧密结舍的“落地指南”，是我在论述同类主题的其他著作中从未见过的。
读完全书，除了丰富的思想与实践，字里行间还渗出一种浓浓的人文关怀。作者在第1章就明确指出：“在理念上，我们希望把度量的重心从‘控制’转向‘改进’。”面对加速变化的世界，只有充分发挥员工的主观能动性，帮助员工提升自身能力，企业才能具备长久的竞争力。而管理者或领导者更多地需要扮演“导师”和“服务员”的角色：引导、帮助员工成长去达成他们自己向往的目标，而非以度量指标来控制员工的行为。这种管理思路的转变，意欲为自己的组织引入度量体系的领导者不可不察。
有幸作为张松的同事，与他在最近几年紧密舍作，我清楚地知道：讲述这样一个主题，松哥正是最理想的作者。在加入ThoughtWorks之前，松哥就有着MBA背景及在大型IT企业中工作的经验；在ThoughtWorks的6年中，他曾在大规模离岸交付项目中艰苦奋战，也曾在国內超大型IT组织的敏捷转型中舌战群儒；作为交付总监和咨询总监，他体会过同时关注十佘个项目时的惶恐无力；作为人力资源总监，他清楚打造一支持续学习、持续改进的团队对于整个企业而言是何其重要。而且在ThoughtWorks中国区管理团队中，松哥一向扮演着“智库”角色：虽然说话不多、嗓门不大，却总是字字珠玑，每每使我们其他成员受益良多。现在松哥的思想与实践得以付梓，使更多读者得以分享他从若干焦油坑中淬炼的菁华，实在是幸事一件。
更多的阅读乐趣，还是留给读者自己在翻开书之后慢慢体会吧。作为在国內帮助IT组织进行精益转型的实践者之一，我希望本书能帮助它的读者在他们的组织中建立一套行之有效的度量体系，并最终帮助这些组织的员工切实地提升自己的能力。如此，善莫大焉。
ThoughtWorks中国 熊节
软件度量是一个困难的话题。对于软件度量的困惑，但凡有过此类经验的人必然深有体会。从事软件度量工作的人，几乎像古希腊神话中的西西弗斯一样，让人敬佩而又同情。然而，随着商用软件的发展，以及快速消费型软件的爆炸式增长，缺乏度量的软件开发组织如同缺少导航设备的航海者，只能沿着看得见的海岸线航行，永远不敢深入远洋一步。
幸运的是，有这样一本书，平实而又从容不迫地讲述了软件度量的精巧所在。你手中的这本书，不是纸上谈兵的泛泛之作，更不是剪刀协助下的资源浪费，它是一个实践者的感悟，行业经验的升华。首先，书中界定了软件度量是什么，以及不是什么，让大家对软件度量有一个舍理的期待。然后根据精益思想，确定了软件的度量框架，从价值、效率、质量、能力等四个方面九个子项，对软件度量进行了细致的阐述。目的是为了软件组织自身的持续改进，实现更大的价值。每个子项中，都有明确的目的、问题、细项说明，逐项说明为何以及怎样进行该项的度量。既可以对读者有启发性的指导，也可以作为实践者的参考。
本书没有笼统地说“软件”的度量，而是对软件进行了分类，选取了典型的互联网软件和电信软件作为两大案例，详细地说明其中的差异，包括用户特征、产品架构、开发团队、长期演进，以及这些特征在价值、效率、质量、能力方面的映射。从讲述方法上，本书从软件的应用场景开始，到如何建立某种特定类型的研发模式，再到如何度量。不是就度量讲度量，而是通过建立与分析软件开发的过程，找出各阶段和各领域的目标，然后再度量。涉及软件研发管理的全过程，可以当作一本软件项目如何管理的小型百科全书。
本书行文流畅，充满精巧的比喻，易读性高，读起让人不忍释手。推荐给各位读者，希望各位业界同仁共同推倒软件度量—这个山坡上的巨石。
中兴通信业务研究院技术部部长，胡荣亮
在软件这个行当里，我们看到的度量数据大都是来自于一些衍生性的指标。在缺乏上下文的情况下，这些指标通常都不能直接告诉我们到底发生了什么，也就是说，大部分指标数据都只是一些间接的证据。将这些证据关联到我们想要度量的对象上，靠的是我们这些人根据经验做出的判断。这种判断具有相当的主观成分，即使是最靠近现场的人，这种判断很多也是在证据不完备的情况下做出的。当有人告诉你，这个团队平均每人每天完成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章，也是最后一章里，尝试初步探讨在一个组织范围内，如何部署和推广一个新的度量体系。
大家可以根据自己的兴趣重点阅读，也可以根据索引作为工具书查阅，当然我个人还是相信，从头阅读能够使大家对这个主题有一个更加系统化的图景。
我希望借这个机会，向那些曾在这个漫长的写作过程中，给我提供指导、帮助的人们表示我由衷的感激。如果说这本书还能够为读者提供一些价值的话，那他们是功不可没的。
首先感谢我的同事张凯峰，没有他的帮助和鼓励，我也不知道是否能把这本书写到出版。何勉、熊节都不厌其烦地为本书提供了两轮详尽的意见，使得最后的成书相对初稿有了大幅的改进，现在回头看去，真不知道他们怎么有耐心读完一开始就那么糙的草稿。为本书提供意见和帮助的还有我的同事郭晓、张逸、骆国程，以及社区的朋友朱谷。另外还要感谢我的同事Localhost为本书插图提供的帮助。感谢其他评阅者慷慨地给出自己的评论。
感谢人民邮电出版社编辑陈冀康，不仅是在于给我这个初出茅庐的作者提供很多有价值的意见，更在于当我不停地把修改版丢给他时，仍对我造成的额外工作量保持着极大的耐心。说到这里，还要感谢Just-pub的周筠老师，是她帮我引荐了冀康。
最后，我可能最感激的还是我的家人。咨询师和公司管理团队的成员都不是轻松的工作，在工作之余还能投入大量的时间和精力写书，可以想见，没有家人的支持和谅解，这是不可能完成的任务。
张松经历应用开发工程师、产品研发工程师、方案架构师、项目经理，甚至售前、销售等各种角色。在过去十几年里，对软件的兴趣，使张松一直在这行当的一线体验着软件从业者所特有的辛劳和喜悦，并乐此不疲。在ThoughtWorks中国分公司，张松现在承担着咨询总监的职责，负责中国市场的咨询业务。在这之前，他曾是多个交付项目的项目经理，并作为交付总监负责中国区项目组合的交付保障，此外他还为多个知名企业的产品研发机构或IT组织提供长期的咨询服务。加入ThoughtWorks之前，张松是Aspect Enterprise Solutions Ltd（原OILspace Inc）上海代表处首席代表。张松拥有华中理工大学计算机工程学士学位和英国Warwick大学MBA学位。
“我们所能拥有的最美好的经历是感受到神秘，它是触发所有真正艺术和科学起源的基本情感。”
艾尔伯特·爱因斯坦（1879—1955）
按照IEEE的定义，“软件工程是将系统化、规则，以及可控的体系方法，应用于软件设计、开发、操作和维护；换言之，即工程理念在软件中的贯彻。”1 看上去很美，不是吗？当我们看到一个又一个软件开发组织，特别是大型的组织，特别是拥有辉煌历史的组织，把过程可控作为主要的管理目标时，一次又一次地惊讶于人们是如此容易被误导，而我自己在开发管理的日常工作中，软件工程那些条条框框所带来的虚假的安全感，也曾使我一次又一次地迷失于其中。反思之后，我现在不得不重新审视软件开发的目标和软件工程方法的目的。
注释：1 The Institute of Electrical and Electronics Ehgineers, 1990。
可控应该只是我们在软件开发管理中期望优化的属性之一，而不是全部。退一步讲，奧运会的口号或许比IEEE 的定义更好地诠释了我们的目标——“更快，更高，更强”，还有一句俗话——“多、快、好、省”，我感觉也比IEEE的那句话更全面。但是为什么人们的注意力都放在了可控性上呢？虽然可控的生产过程可以帮助管理人员更有针对性地优化和改进。不过在向“多、快、好、省”的方向前进的过程中，管理层和项目管理人员的避险本能，在相当程度上扭曲了我们的注意力，有意无意地遗失了原始的目标。
风险源于不确定性。然而软件之所以“软”，就是由其生命周期中所面对的变化和不确定所决定的；从另一个角度讲，不确定性又是与创新如影随行。跟其他行业相比，软件领域的创新之活跃也不能不说与此密切相关，反过来说，那些非常确定、稳定的东西或许就不应该用软件来实现，既然要开发软件，就要正视其固有的变化性，利用其变化性取得优势。
Roger Martin在他的著作《The Design of Business: Why Design Thinking is the Next Competitive Advantage》把知识的演进用一个知识漏斗（Knowledge Funnel）生动形象地描述了出来。这个漏斗总是从一个问题开始，需要经过谜题（Mystery）、启发（Heuristic）和算法（Algorithm）3个阶段1 ，如图1-1所示。
图1-1 知识漏斗
注释：1 Martin, 2009
Roger Martin认为，复杂问题的解决总是从谜题阶段开始。探索一个神秘的问题，可能会有无限种可能的方式。以我们的交通工具为例，人类一直在孜孜以求地获取更快更好的交通工具。那么如果说“更好的交通工具”是一个谜题，经过了几千年的摸索，在工业革命之前，交通工具这个谜题曾经己经被降解成一系列的启发式的问题。其中的两个可能是：更好的马车和更好的帆船。相对于谜题，启发式问题是将探索的领域缩小到一个更加可控、可管理的大小。当有了这两个启发式的问题之后，人们就倾向于不再去考虑“更好的交通工具”这么一个没边儿的问题，目标就变成了“如何制作更精致的马车，让马车更轻便、更结实”，“如何制作更大的帆船和有效的风帆，让帆船载货量更大，速度更快”。问题的解决聚焦在了产品的升级和演进，这两个问题又被进一步降解成了一系列的算法化问题。算法化的问题指的是己经有固定的公式、模式来解决的问题。对于马车和帆船的例子来讲，马车和帆船的制作就是一个算法化的问题，经过训练的工匠能够依据固定的流程和工艺，顺利地重复制作多个产品。
不过世界并没有就此止步。到了工业革命之后，伴随着技术约束的突破，“更好的马车”和“更好的帆船”，这两个启发性的问题己经不再合理。我们需要重新回到“更好的交通工具”这个命题，将其降解成了另外一系列问题，“更好的汽车”、“更好的轮船”、“更好的飞机”……而那些醉心于旧的启发性和算法性问题的人们或是行业，逐渐被时代所淘汰。我们可以看到，随着时间的变化、场景的转换（陆地、海洋，还有天空、太空）、科技的突破，我们要解决的基本谜题可能会降解出不同的启发式问题。
回到软件开发这个谜题上来，Gerald M . Weinberg在他的《质量·软件·管理—系统思路》中写到“虽然人类的大脑或多或少存在些许的差别，然而都有一定的限制；随着程序规模的不断增加，软件的复杂度也将至少以平方的速度增加。”1 Weinberg称其为自然软件动力学。Weinberg认为“软件工程学的历史过程，也就是人类试图通过建立简化方法，降低随着问题规模的扩大而提高的问题复杂度，从而不断对规模/复杂度动力提出挑战的历史过程。如果没有这种追求，也就不需要软件工程专业了。”
注释：1 杰拉尔德·温伯格, 2004, 页169
软件开发这个谜题，就像其他复杂而又会随着时间和场景不断转移重心的谜题一样，我们似乎也有无数种的方式来做到一定程度的简化，在某种程度上或是在某个方面上解决了这个问题。IEEE对软件工程的定义，“系统化、规则，并且可控”就是对这个谜题在一个维度（可控性）上简化而得出的一个启发式问题。
Roger在书中提出了两种思考问题的方式：分析性思维和启发性思维2 。分析性思维的驱动力是标准化，消除个体的判断所带来的偏见和差异，而启发性思维的驱动力是发现和创新。这两种思路在具体实现上体现出的区别在于，分析性思维倾向于可靠性，而启发性思维倾向于有效性。
注释：2 Martin, 2009
IEEE的这个定义，因为并不直接关注更好地开发软件本身，明显带着可靠性的倾向，对于有效性则显得缺乏应有的关注。我猜测这应该是1965年到1985年软件危机的产物。那个时代，计算机行业刚刚摆脱萌芽期，硬件能力大幅提升，人们开始在各种领域尝试用计算机软件来解决愈来愈复杂的问题。大型软件项目纷纷出现，可又纷纷失败，软件开发就像怪兽，失去了控制，主要的表现是大幅地超时和超预算，又或是软件的质量极不靠谱。为了解决这个谜题，可靠性似乎是理所当然的，也是最迫切的切入点。
度量体系给人的直观感受就是可以提高开发过程和开发结果的可靠性，但可靠和成功，这两者真的是等价的吗？度量本身似乎就是一个分析性思维的产物，但这并不妨碍我们回归问题本身，同时利用分析性和启发性思维，判断到底哪些要素跟“成功”更相关，并尝试用一个度量体系来帮助我们在动荡的环境中捕捉和把控这些要素。
度量本身不是目的，是手段。我问过很多人，你们这儿度量信息是在什么地方用呀？我经常听到的是，“现在不是都要用数字说话嘛，咱得搞点儿量化管理”，“这玩意儿（数字）就是给上面看看，没啥用”，“没这些数字，我怎么知道下面的人干得咋样？”我们发现：
•在很多情况下，数据的生产者不是数据的使用者；
•数据的生产者没什么动力去分辨信息的价值，也不关心信息准确与否；
•数据的生产者关心的是数据是否会对自己带来惩罚或是收益，而不是数据跟软件开发的关系；
•在很多管理者的认识当中，度量的主要目的，是确保事情在掌控之中，为的是获得可靠性和安全感；
•相对于“更高效的开发软件”这样模糊的目标而言，很多一线人员对度量指标的使用其实更加一个简单、清晰、朴实——一旦开发出了问题，一个自我保护的理由就是“我己经满足了度量的要求了呀？”
软件项目中可能出现各种各样的冲突，权衡并把握住进度、质量和人员能力提升等各种不同目标，总是要消耗掉项目管理人员很多的脑细胞。可是不管多么努力，做出的决定仍然不是得罪了这个，就是让那一个不爽。度量体系中的指标通常是那些复杂、模糊的目标经过分解和简化的结果。一套度量体系被实施之后，很多人都有一种光明初现的感觉，好像做决定变得有章可循，容易多了。出于趋利避害的考虑，人们经常会把目光聚焦在片面满足相对明确的指标上，回避了对综合的项目目标和复杂上下文的思考和权衡。
为了规避指标替代目标的陷阱，我们希望在设计和运营度量体系的时候，将各类相关人员都融入到一个共同的理念之下。
精益的一个核心理念是持续改进，丰田澳大利亚技术中心（Toyota Technical Center-Australia）对持续改进的诠释是：“我们从来不认为当前的成功是我们最终的成就。我们从来不会满足于当前所处的位置，而是会一直竭尽全力，寻求最佳的思路持续改善我们的工作：我们热衷于创造更好的替代方案，质疑己有的成果，寻求新的成功定义”1 。挺复杂的一句话，咱老祖宗在3000多年前，只用了9个字就把这事儿说清楚了。商汤王，也就是商朝的开国君主，在他自己的洗澡盆儿上刻了一行字以自勉：“苟日新，日日新，又日新”2 ，就是提醒自己：弃旧图新是每天都要干的事儿。
注释：1 http://management.curiouscatblog.net/2010/04/15/the-toyota-way-two-pillars/。
注释：2 《大学》第三章：“汤之《盘铭》曰：‘苟日新，日日新，又日新。’”
如图1-2所示，在理念上，我们希望把度量的重心从“控制”转向“改进”。虽然控制和改进都是对系统采取的干预性措施，“控制”给人造成的心理暗示是围绕着静态目标而行动；而“改进”则将动态的目标植入人们的思维模式。这有助于我们在识别软件开发的成功路径时，由可靠性转向一个更广泛的视角。
在这样的理念指导下，度量体系的作用就是提供信息来帮我们知道现在哪里，距离目标到底有多远，我们是否在向目标前进，进展的程度如何。因此简单地说，度量是通过对目标位置、相对位置、移动方向的描述，帮助组织达成其业务目标。
图1-2 “控制”转向“改进”
我们把度量体系的实现分成3个不同的层次——理念、设计、应用，如图1-3所示。
图1-3 三层度量体系
在后续的第2、3、4章，我们会从组织目标、软件产品开发过程中的决策场景，以及指标体系框架3方面来分析度量体系的设计。第5章至第12章会系统地讨论几个主要的度量维度。而在最后的3章里，将会尝试验证导入和推广实施两个阶段，讨论如何在一个组织内建立起一个有效、有价值的度量机制。
不过在那之前，我们需要进一步就理念上澄清一下，本书中的度量是什么？不是什么？
1. 度量是在一个特定组织上下文中形成的一系列共识。
司马迁在《史记·秦始皇本纪》中写道，秦始皇“一法度衡石丈尺。车同轨，书同文。”度量的一个重要意义是统一思想、统一方式，从而使不同的人能够在一致的基准上进行沟通，减少产生误解的可能性。在一个软件开发组织里，度量统一的不仅仅是度量单位、度量对象、度量手段，更重要的是统一对目标的认识。关于度量是什么、不是什么如图1-4所示。
图1-4 度量是什么，不是什么
如果一个组织确定了提高质量的目标，每个团队和个人就必须在如何度量质量上形成共识。在我曾经提供过咨询服务的一个产品研发机构里，有的人认为，只有产品交到客户手里后，使用过程中产生故障的数量和故障的严重程度才是衡量质量的依据；而另外一些人则认为，产品的代码质量，甚至测试脚本的质量，也应该是质量的度量范围，因为对于很多生命周期较长的软件来说，代码和测试脚本中的坏味道和技术债，是后续版本的质量陷阱和成本陷阱。双方争执不清，分析其根本原因，其实是在于对软件代码内在质量上的投入产出上有不同的意见。如果一个组织在这些方面缺乏澄清和共识，就无法形成统一的目标和手段，从而很难取得显著的改进成果。
另外，度量体系可以帮助一个组织形成一套统一的术语。当人们在讨论问题的时候，能够在一定程度上确保大家是在用同样的语言说着同样的事情。几个来自不同团队的人在讨论开发效率的时候，如果组织里都用的是相同的工作量度量单位，比如故事点，大家都应该知道这个数据是怎么得来的，是用的相对大小，还是绝对大小，考虑的因素有哪些，其优势在什么地方，局限性又在什么地方。只有在这些方面理解一致，才能取得有效的沟通，减少误解和不必要的争执。
2. 度量是将经验模型向量化模型进行匹配的尝试。
量化模型就是通常所指的硬数据、硬指标，这是大多数管理人员想看到的。当人们看到数字的时候，总会生出一种更加准确、更加靠谱的印象，觉得这样的度量结果不容易受到主观因素和人为操纵的影响。只要看看那些号称7天美白的护肤品卖得有多好，就知道这种数字营销对人的影响效果了。
不过说老实话，看看定期发布的CPI数据，对比一下我们对生活成本的直观感受，我们就可以知道，量化与否，跟是否能够准确反映度量的目标没啥直接关系。以单位时间生产的代码行数（SLOC）为例，作为生产效率的度量手段，这个指标现在仍然在很多大型的产品开发组织当中广泛应用。我们在有些组织中观察到的实际效应是：为了体现我的效率，一个特性可以用800行代码完成的，咱绝不用500行，最好能用1000行以上才能体现我的辛苦。一位同事曾对客户的一个遗留系统的某个模块做过一次重构，将其代码行数削减了将近80%，事后他告诉我，其实还有不少空间。这个客户的研发团队是用代码行来度量工作量和效率的，虽然这种包含大量冗余代码的系统，并不都是用代码行来度量工作量所导致的，但至少度量并没有对产生优化的系统起到有效的引导性作用。
虽然量化的不一定就是好的，量化模型确实有个非常重要的优势——方便进行比较，这种比较有两种类型。
•跟自己比较：持续改进，持续超越自己，就需要比较自己发生的变化。
•橫向比较：这对于拥有大量开发人员、团队和产品的大型组织来说，是非常有吸引力的。在组织内部进行团队和团队之间的比较，是不少公司激励大家提升绩效的手段。另外，如果能跟业界的数据比较，也可以知道自己在行业中的位置如何。
可惜的是，软件开发中的很多信息都难以用量化模型来描述。经验性模型，也就是定性的度量，主要依赖文字来描述度量的依据，靠人对这些信息的理解和分析来判断、还原情境的过程和结果，比如说：团队经验和能力、项目和系统约束、流程的可靠性和成熟度、用户满意度等，这类度量描述通常由于包含很多的上下文信息而难以量化。
这样产生的一个问题就是，度量结果容易受到信息提供者和使用者的经验和主观意识的影响，也可能引入信息不对称带来的偏见。典型的例子就是任何两个人对一个产品的用户满意度都会有不同的判断。
由于包含了上下文信息，度量结果无法在个人和个人之间、团队和团队之间进行橫向比较。比如我们说有两个团队都很成熟，可能的情况是，一个团队成熟是因为其成员经验很丰富；而对于另一个团队则是指其开发流程运转十分顺畅。
为了解决经验性模型的局限性，业界做了各种尝试，其中最著名的当属CMMi模型。其实当前流行的各种成熟度模型都是将经验模型向量化模型匹配的尝试。我个人并不反对这种努力，不过在使用这样的量化模型的时候，我们一定要注意量化模型本身的局限性。这种模型的度量结果来源于对大量上下文信息的汇总、过滤和抽象，这种简化容易让人们在度量中失去了度量发生的场景细节，迷失了度量本身的目标，以至于为了度量而度量。
3. 度量是包含人、流程、组织和工具的一个动态系统。
如果把软件开发组织看做一个动态的系统，度量实际是作为反馈机制来对这个系统产生作用的。
如图1-5所示，假如我们把交付目标，包括交付时间和内容，作为系统的输入，当我们想要呈现进度相关的输出时，如果我们用的是瀑布式开发模型，那么得到的可能是哪些功能需求己经分析完成，或是代码写了百分之多少；而如果我们用的是迭代开发模型，得到的信息可能是以故事点为单位的燃烧图（Burn up Chart），呈现的是端到端己经完成的特性。这些信息可能是某人手工计算产生，也可能是项目管理工具自动采集、汇总的，形式可能是一个Spreadsheet，也可能直接呈现在工具的页面上。
图1-5 动态的反馈系统
系统的干预者，可能是项目经理、产品经理，或是某个领导，依据目标和当前环境情况（比如竞争对手信息），对照这些进度数据，判断是否应该采取干预措施。如果发现跟预期有所差距，干预者可能会在交付内容或交付时间上有所调整，或是为团队提供更多的资源来提升其交付产能，当然也可能是要求团队开始加班加点……团队对这种干预通常也会马上做出反应，他们会根据干预行动和其他新的输入，寻求并调整到一个新的稳定的工作机制，这种新的工作机制可能是找到一个更有效率的方法，也可能是马上把设计、优化、验证等活动拋掉，“裸奔”前进。
度量本身也会对软件开发组织的人员、流程、组织和工具产生影响。在一些比较大型的产品开发组织当中，特别是实施SEI的CMMi模型的组织中，为了有效地管理过程质量，产生了质量保障（QA）组织。SEI的CMMi模型中强调的是软件质量保障（SQA）的独立性，组织的独立性意味着，需要为不在一线团队中的QA创造观察和干预开发活动的机制，这样的机制通常表现为围绕开发流程创造出来的新流程，为了支撑这个流程的运转，可能需要部署针对开发过程的数据的采集、汇总、报告一系列的工具。不过在实际的部署中，有些号称重业务轻流程的组织里，QA组织形同虚设，只是为了获取CMMi等资质而存在；而另一个极端是，在一些“成熟”的组织里，QA的影响力很大，原本应该承担老师、医生和警察责任的QA，最后只剩下了警察角色，挥舞着度量的大棒，跟开发团队玩着猫捉老鼠的游戏。
1. 度量不是软件开发固有的活动。
度量本身并不对客户直接可见，不是作为产品或服务的一部分为客户直接创造价值，因此根据精益的理念，应该尽可能地减少。作为一个组织来讲，应该积极地评估当前的度量活动的成本，分析是否真正为达成业务目标发挥着价值，从而确保运行度量体系的投入产出是在一个合理的水平。
2. 度量应该避免跟绩效直接相关。
正如前面所说的，软件开发当中的度量大多使用的是衍生指标，因此单独的指标，甚至是一系列的指标加在一起，也通常无法反应具体开发场景的上下文。用度量结果作为判定绩效级别的主要手段是一件非常危险的事情，几个同样优秀的团队或个人在具体指标上的表现，各自可以有很大的差异。这就好像用同样的指标，比如GDP，来考核一个舒缓轻松的旅游城市大理和一个紧张繁忙的工业城市东莞。如果由此造成了两个城市趋同的建设行为，比如大建工厂，大修基础设施，想象一下在洱海边工厂林立的情景吧，对大理来说，这就会是灾难性的后果。同样，把一套标准的度量与个人、团队绩效强相关，很可能导致各种奇怪的博弈行为，中长期的负面作用经常会大于短时间指标提升带来的好处。前面提到的通过代码行数产出度量生产效率的方式，带来的大量冗余代码、废代码就是软件开发中的诸多博弈行为之一。
3. 度量不是免费的。
度量需要投入团队的时间，项目管理人员的时间，质量保障人员的时间，以及公司管理人员的时间，还可能会有工具和基础设施的投入。围绕各种目标需要度量体系的设计和实施，体系的运转需要数据的收集、分析和汇报，这些环节做得不到位是不可能产生预期效果的，而要做到位，所需的投入可能并不是一个可以忽略的小数目。因此，目标和指标的选择就显得特别重要，试图实施一个大而全的度量体系，通常弊大于利。
最后，软件开发中并不是所有的目的都要用度量来达成，度量也不是帮助达成所有目标的灵丹妙药。
