本节书摘来自异步社区《精益软件度量——实践者的观察与思考》一书中的第1章1.2节度量是什么，作者张松，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.2 度量是什么
精益软件度量——实践者的观察与思考
1．度量是在一个特定组织上下文中形成的一系列共识。
司马迁在《史记·秦始皇本纪》中写道，秦始皇“一法度衡石丈尺。车同轨，书同文。”度量的一个重要意义是统一思想、统一方式，从而使不同的人能够在一致的基准上进行沟通，减少产生误解的可能性。在一个软件开发组织里，度量统一的不仅仅是度量单位、度量对象、度量手段，更重要的是统一对目标的认识。关于度量是什么、不是什么如图1-4所示。
如果一个组织确定了提高质量的目标，每个团队和个人就必须在如何度量质量上形成共识。在我曾经提供过咨询服务的一个产品研发机构里，有的人认为，只有产品交到客户手里后，使用过程中产生故障的数量和故障的严重程度才是衡量质量的依据；而另外一些人则认为，产品的代码质量，甚至测试脚本的质量，也应该是质量的度量范围，因为对于很多生命周期较长的软件来说，代码和测试脚本中的坏味道和技术债，是后续版本的质量陷阱和成本陷阱。双方争执不清，分析其根本原因，其实是在于对软件代码内在质量上的投入产出上有不同的意见。如果一个组织在这些方面缺乏澄清和共识，就无法形成统一的目标和手段，从而很难取得显著的改进成果。
另外，度量体系可以帮助一个组织形成一套统一的术语。当人们在讨论问题的时候，能够在一定程度上确保大家是在用同样的语言说着同样的事情。几个来自不同团队的人在讨论开发效率的时候，如果组织里都用的是相同的工作量度量单位，比如故事点，大家都应该知道这个数据是怎么得来的，是用的相对大小，还是绝对大小，考虑的因素有哪些，其优势在什么地方，局限性又在什么地方。只有在这些方面理解一致，才能取得有效的沟通，减少误解和不必要的争执。
2．度量是将经验模型向量化模型进行匹配的尝试。
量化模型就是通常所指的硬数据、硬指标，这是大多数管理人员想看到的。当人们看到数字的时候，总会生出一种更加准确、更加靠谱的印象，觉得这样的度量结果不容易受到主观因素和人为操纵的影响。只要看看那些号称7天美白的护肤品卖得有多好，就知道这种数字营销对人的影响效果了。
不过说老实话，看看定期发布的CPI数据，对比一下我们对生活成本的直观感受，我们就可以知道，量化与否，跟是否能够准确反映度量的目标没啥直接关系。以单位时间生产的代码行数（SLOC）为例，作为生产效率的度量手段，这个指标现在仍然在很多大型的产品开发组织当中广泛应用。我们在有些组织中观察到的实际效应是：为了体现我的效率，一个特性可以用800行代码完成的，咱绝不用500行，最好能用1000行以上才能体现我的辛苦。一位同事曾对客户的一个遗留系统的某个模块做过一次重构，将其代码行数削减了将近80%，事后他告诉我，其实还有不少空间。这个客户的研发团队是用代码行来度量工作量和效率的，虽然这种包含大量冗余代码的系统，并不都是用代码行来度量工作量所导致的，但至少度量并没有对产生优化的系统起到有效的引导性作用。
虽然量化的不一定就是好的，量化模型确实有个非常重要的优势—方便进行比较，这种比较有两种类型。
跟自己比较：持续改进，持续超越自己，就需要比较自己发生的变化。
横向比较：这对于拥有大量开发人员、团队和产品的大型组织来说，是非常有吸引力的。在组织内部进行团队和团队之间的比较，是不少公司激励大家提升绩效的手段。另外，如果能跟业界的数据比较，也可以知道自己在行业中的位置如何。
可惜的是，软件开发中的很多信息都难以用量化模型来描述。经验性模型，也就是定性的度量，主要依赖文字来描述度量的依据，靠人对这些信息的理解和分析来判断、还原情境的过程和结果，比如说：团队经验和能力、项目和系统约束、流程的可靠性和成熟度、用户满意度等，这类度量描述通常由于包含很多的上下文信息而难以量化。
这样产生的一个问题就是，度量结果容易受到信息提供者和使用者的经验和主观意识的影响，也可能引入信息不对称带来的偏见。典型的例子就是任何两个人对一个产品的用户满意度都会有不同的判断。
由于包含了上下文信息，度量结果无法在个人和个人之间、团队和团队之间进行横向比较。比如我们说有两个团队都很成熟，可能的情况是，一个团队成熟是因为其成员经验很丰富；而对于另一个团队则是指其开发流程运转十分顺畅。
为了解决经验性模型的局限性，业界做了各种尝试，其中最著名的当属CMMi模型。其实当前流行的各种成熟度模型都是将经验模型向量化模型匹配的尝试。我个人并不反对这种努力，不过在使用这样的量化模型的时候，我们一定要注意量化模型本身的局限性。这种模型的度量结果来源于对大量上下文信息的汇总、过滤和抽象，这种简化容易让人们在度量中失去了度量发生的场景细节，迷失了度量本身的目标，以至于为了度量而度量。
3．度量是包含人、流程、组织和工具的一个动态系统。
如果把软件开发组织看做一个动态的系统，度量实际是作为反馈机制来对这个系统产生作用的。
如图1-5所示，假如我们把交付目标，包括交付时间和内容，作为系统的输入，当我们想要呈现进度相关的输出时，如果我们用的是瀑布式开发模型，那么得到的可能是哪些功能需求已经分析完成，或是代码写了百分之多少；而如果我们用的是迭代开发模型，得到的信息可能是以故事点为单位的燃烧图（Burn up Chart），呈现的是端到端已经完成的特性。这些信息可能是某人手工计算产生，也可能是项目管理工具自动采集、汇总的，形式可能是一个Spreadsheet，也可能直接呈现在工具的页面上。
系统的干预者，可能是项目经理、产品经理，或是某个领导，依据目标和当前环境情况（比如竞争对手信息），对照这些进度数据，判断是否应该采取干预措施。如果发现跟预期有所差距，干预者可能会在交付内容或交付时间上有所调整，或是为团队提供更多的资源来提升其交付产能，当然也可能是要求团队开始加班加点……团队对这种干预通常也会马上做出反应，他们会根据干预行动和其他新的输入，寻求并调整到一个新的稳定的工作机制，这种新的工作机制可能是找到一个更有效率的方法，也可能是马上把设计、优化、验证等活动抛掉，“裸奔”前进。
度量本身也会对软件开发组织的人员、流程、组织和工具产生影响。在一些比较大型的产品开发组织当中，特别是实施SEI的CMMi模型的组织中，为了有效地管理过程质量，产生了质量保障（QA）组织。SEI的CMMi模型中强调的是软件质量保障（SQA）的独立性，组织的独立性意味着，需要为不在一线团队中的QA创造观察和干预开发活动的机制，这样的机制通常表现为围绕开发流程创造出来的新流程，为了支撑这个流程的运转，可能需要部署针对开发过程的数据的采集、汇总、报告一系列的工具。不过在实际的部署中，有些号称重业务轻流程的组织里，QA组织形同虚设，只是为了获取CMMi等资质而存在；而另一个极端是，在一些“成熟”的组织里，QA的影响力很大，原本应该承担老师、医生和警察责任的QA，最后只剩下了警察角色，挥舞着度量的大棒，跟开发团队玩着猫捉老鼠的游戏。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
