一直以来，我对度量骨子里有一种抵触，因为很多时候，指标容易被拿来衡量团队绩效。而作为考核的KPI，容易成为团队改进指挥棒，带有很大片面性和欺骗性；另一方面，如果没有度量，有无法客观的评价组织改进的效果，这是一种矛盾。不想因为自己心智模型导致目光的短浅，跳出盒子去了解原本的度量，这是我都这本书《精益软件度量——实践者的观察与思考》的初衷。本次阅读本书的前四章。
第一章 度量谜题
按照IEEE的定义，“软件工程是将系统化、规则，以及可控的体系方法，应用于软件设计、开发、操作和维护；换言之，即工程理念在软件中的贯彻。”
Roger Martin在他的著作《The Design of Business: Why Design Thinking is the Next Competitive Advantage》把知识的演进用一个知识漏斗（Knowledge Funnel）生动形象地描述了出来。这个漏斗总是从一个问题开始，需要经过谜题（Mystery）、启发（Heuristic）和算法（Algorithm）3个阶段[注释]，如图1-1所示。
Roger在书中提出了两种思考问题的方式：分析性思维和启发性思维[注释]。分析性思维的驱动力是标准化，消除个体的判断所带来的偏见和差异，而启发性思维的驱动力是发现和创新。这两种思路在具体实现上体现出的区别在于，分析性思维倾向于可靠性，而启发性思维倾向于有效性。
度量本身似乎就是一个分析性思维的产物，但这并不妨碍我们回归问题本身，同时利用分析性和启发性思维，判断到底哪些要素跟“成功”更相关，并尝试用一个度量体系来帮助我们在动荡的环境中捕捉和把控这些要素。
1.1 精益软件开发的度量体系
在理念上，我们希望把度量的重心从“控制”转向“改进”。虽然控制和改进都是对系统采取的干预性措施，“控制”给人造成的心理暗示是围绕着静态目标而行动；而“改进”则将动态的目标植入人们的思维模式。
度量体系的实现分成3个不同的层次——理念、设计、应用。
1.2 度量是什么
1、度量是在一个特定组织上下文中形成的一系列共识。
秦始皇“一法度衡石丈尺。车同轨，书同文。”
度量的一个重要意义是统一思想、统一方式，从而使不同的人能够在一致的基准上进行沟通，减少产生误解的可能性。
在一个软件开发组织里，度量统一的不仅仅是度量单位、度量对象、度量手段，更重要的是统一对目标的认识。
2、度量是将经验模型向量化模型进行匹配的尝试。
量化模型就是通常所指的硬数据、硬指标。量化模型比较有两种类型：
•跟自己比较：持续改进，持续超越自己，就需要比较自己发生的变化。
•橫向比较：这对于拥有大量开发人员、团队和产品的大型组织来说，是非常有吸引力的。在组织内部进行团队和团队之间的比较，是不少公司激励大家提升绩效的手段。另外，如果能跟业界的数据比较，也可以知道自己在行业中的位置如何。
3. 度量是包含人、流程、组织和工具的一个动态系统。
如果把软件开发组织看做一个动态的系统，度量实际是作为反馈机制来对这个系统产生作用的。
1.3 度量不是什么
1. 度量不是软件开发固有的活动。
作为一个组织来讲，应该积极地评估当前的度量活动的成本，分析是否真正为达成业务目标发挥着价值，从而确保运行度量体系的投入产出是在一个合理的水平。
2. 度量应该避免跟绩效直接相关。
把一套标准的度量与个人、团队绩效强相关，很可能导致各种奇怪的博弈行为，中长期的负面作用经常会大于短时间指标提升带来的好处
3. 度量不是免费的。
目标和指标的选择就显得特别重要，试图实施一个大而全的度量体系，通常弊大于利。
第二章 组织目标
度量体系是引导团队达成业务目标的一整套策略，如图2-1所示，包含了业务目标、决策场景和指标体系3个阶段。
2.1 业务目标
软件产品的开发分成几个大的阶段：业务策略、项目定义、项目执行、维护支持。
2.2 开发组织的目标
业务对开发组织的期望大致分为几类：价值、效率、质量和能力，其中效率又包括对市场的响应速度和单位规模开发组织的交付速率。
2.2.1 交付价值
对于功能性需求，开发组织能够在开发前，将低价值内容从高价值特性上剥离下来，从而提升投资回报（ROI）。
对于非功能性需求，很多情况下，开发组织提出的方案都会影响投入在短期和长期时间轴上的分配，因此，能够使技术方案跟业务模式相吻合，就有可能在相当程度上提升交付的价值。
2.2.2 响应速度
管道的长度代表了端到端的软件开发活动，包含了从用户需求的产生到该需求以产品的形态为用户产生价值的整个过程。管道的长度和交付对象在管道里流动的速度，决定了组织对市场的响应速度，也就是交付周期。
2.2.3 交付速率
如果把管道直径比作组织的规模，效率的一个目标是提升管道的吞吐率，也就是交付管道直径不变的情况下，提高单位时间内通过管道的工作单元的数量。对应到软件开发组织，就是单位规模的组织在单位时间内所能交付的软件规模，我们简称其为交付速率。
软件开发本身的特点，使得在传统制造业中大放异彩的规模效应，并没有在软件开发中产生明显的效果。业界分析的结果指出，规模能够对软件开发效率带来2个正面效应。
（1）在以提高生产效率为目的的工具和基础设施上的投入可以被更广泛的共享。
（2）产品和项目管理的成本不会直接随着项目规模的增大而增加，可以想象，一个项目经理或一个产品经理，可以应对从十来号人到上百人团队的管理工作。
负面效应：
（1） 沟通成本：如Brooks在《人月神话》中说的[注释]，开发规模大了之后，团队成员之间、团队和团队之间的沟通路径是几何级数增长的。
（2）人员投入程度：软件开发是一个需要紧密协作的活动。大团队增加了人员间个性冲突的概率，会造成团队内不良的化学反应，降低团队效率。此外，大团队还降低了大多数个体的参与感。
（3）系统复杂度：产生大规模团队的一个原因是系统本身的规模，而根据Conway’s Law[注释]，软件设计的架构，实际上反映了开发组织的结构与沟通架构。随着组织结构的扩展和复杂化，模块间接口数量也会随着模块数量的增加呈几何级数增长的。这意味着系统复杂度的增长，而且更加难以评估引入变更的影响，这也意味着系统维护、演进成本的增加。
2.2.4 质量
质量是指广义上的质量，包括产品设计、用户体验、功能完善等。质量是个约束性的属性，对于一个特定的产品来说，其质量要求通常是相对稳定的。质量保障是通过系统化的一系列活动，提供足够的证据说明软件产品是适合使用的（fI Tfor use）。
2.2.5 能力
个人、团队、组织的能力是对上述3个因素有直接影响的要素。Peter M .Senge在《第五项修炼》中指出，一个组织唯一可持续的竞争优势是比对手更快的学习能力。这种学习不仅发生在课堂里，更重要的是从客户、市场、团队学习，从成功和失败学习。
第三章 决策场景
3.1 使用度量的人们
软件度量信息的使用者分成3个主要角色——管理层、项目管理、工程师。
管理层关注：
•公司的战略定位——产品和服务的交付对战略目标的支撑。
•战略目标的达成——产品和服务的商业绩效，组织的交付效率。
•组织所处的竞争环境——自身和竞争对手商业模型，对市场变化和机会的响应速度。
•客户满意度，等等。
大多数的度量都跟项目管理相关，但是项目管理也分不同的层面。首先需要在组织层面考虑各个目标的权衡，诸如交付、创新和能力提升；然后需要考虑本项目在产品或产品线组合中的位置、产品各个版本之间的关系，还要顾及项目目标和相关人员个人诉求之间的关系。
工程师不仅仅是第一手度量信息的生产者，当管理层和项目管理人员根据信息采取行动时，工程师都常常是执行者或是最终受到主要影响的人。
3.2 决策的组织上下文
合适的软件开发实践一定会受到产品本身和开发组织特点的影响，正如 Barry Boehm 和 Richard Turner 在“Balancing Agility and Discipline: A Guide for the Perplexed”里提到，5个方面的因素[注释]会在很大程度上影响开发的组织模型和流程模型。
3.3 项目决策的阶段
3.3.1 项目定义
1. 问题定义
清晰地定义问题是设定目标、制定计划的前提。如果把项目分成问题域和方案域，不少组织和个人都会不自觉地混淆问题域和方案域。
2. 交付目标
交付目标应该有可度量的开始点和截止点，也就是有清晰的边界。这个边界可能会在交付过程中，根据最新的信息而调整。但在任何特定的时候，项目的所有干系人对边界都应该有一个清楚的共识。
3. 提升目标
一个组织要分析相关行业和竞争对手的数据，对自身交付竞争力做出评估，有策略地制定提升目标。研发竞争力的提升必须要以项目为载体，在实践当中部署实施。
4. 资源配置
一个大型的开发组织一般都有多个产品、多个版本在同时进行当中。这就涉及到在不同发布目标之间的权衡，决定资源，特别是优质资源的分配。资源的投入经常是多个项目、多个产品之间博弈的结果。项目管理人员需要根据项目的目的和里程碑来规划项目，在规划的时候需要覆盖进度、质量、资源和风险各个方面。
5. 进度目标
项目的关键路径信息可以帮助项目管理人员识别交付过程中的里程碑。里程碑提供了一个常规机制来跟踪项目的进展是否跟预期相符。这些里程碑给团队之外更广泛的项目干系人一个必要的机会，一起分析最新的项目和环境信息，调整后续的时间点、投入、工作范围和目标，或做出其他必要的决策和干预。
6. 质量目标和手段
不同类型的产品有不同的质量目标。在这个项目里，开发人员将负责单元测试完成，测试人员将会跟业务分析人员一起定义每个用户估算的验收条件，并设计功能和集成测试用例。功能和集成测试用例的自动化则根据工作量的平衡，由开发人员和测试共同完成。
7. 资源的规划
项目管理人员就需要用真凭实据，对照过往的历史数据和项目相关信息，提出资源的要求。对于个人来讲，项目的参与人员需要了解团队计划，评估个人对于交付目标的承诺，并且识别成长的机会。
3.3.2 项目执行
项目干预通常主要出自以下两个方面的原因。
•环境变化——市场上的客户需求或是竞争对手的行动出现了变化，原来决策所基于的事实或假设出现了变化，因此需要对本组织的开发做出调整。
•内部变化——本项目的进度、质量，周边其他项目的进展跟预期不符，如果需要达成原来的目标就需要采取额外行动，否则就可能需要调整目标。
对于项目管理来说，为管理层提供确实的数据，支持管理层决策是至关重要的。这里度量数据的典型用途包括以下几方面。
（1）设定管理层对进度和质量的期望。
（2）获取更多资源，以较低的风险达成项目目标或是管理层的期望。
（3）提高项目透明度，取得包括管理层在内的各方干系人的信任，以取得决策的权威。
（4）预测项目状态，争取管理层做出对项目有利的干预。
（5）识别项目执行当中的瓶颈，做出相应调整，或是说服调动其他有资源、有权利的人做出调整。
（6）识别项目执行过程中的浪费，积极采取措施消除浪费。
3.3.3 维护阶段
管理层在这个阶段更关心客户的满意度，这里满意度主要体现在以下两个方面。
•需求的价值命中率——做出来的东西是否真是市场和客户最需要的东西，是否为公司创造了最大的价值。
•客户满意度——这个维度更加复杂一些，不仅包含了前一个需求价值命中率的因素，还包含了用户体验、线上的缺陷率，以及支持维护的响应速度和质量。
项目管理人员需要在维护阶段管理客户和市场对维护响应的期望，因此需要知道以下内容。
（1）问题的优先级——哪些问题会造成较大的影响，必须先解决。
（2）响应速度——支持团队对客户的响应周期，包括：邮件、电话确认问题，定位、解决问题，回复客户的周期。
（3）响应质量——提出解决办法是否真的解决了问题？打补丁的时候是否引入了新的问题？
（4）维护成本——每个类型问题和请求的处理工作量。
第4章 指标框架
如果借助戴明环（PDCA循环——P计划、D执行、C检查、A行动）分析这个过程，就会发现度量数据的使用主要集中在支持计划和检查两个环节的决策。
4.1 支撑决策的数据
计划-根据己知的数据，设定合理的目标，预测未来可能发生的情况，制定可行的计划。
检查：我们借助度量数据，识别现实与预期的差异、面临的问题、改进的空间。
4.2 指标
一个指标体系通常包括下列内容。
•指标的维度。
•每个维度里可选的具体指标。
•指标的优先级评估。
•指标的数据采集、分析和使用方法。
4.3 指标属性
每一个指标都不是独立存在的数据，都必然跟一系列上下文信息相关，具体体现为类似下面所列的属性。
4.4 指标优先级
在裁剪指标体系的时候，也应该在目标优先级的引导下，如图4-3所示，权衡有效性、可靠性和成本，设计和选择要使用的度量指标。
•有效性：指标数据在多大程度上能真实地为达成目标服务。
•可靠性：数据收集以及分析结果的一致性和可靠性。
•成本：度量数据的收集和分析成本。
以工作量的估算数据为例，在使用Delphi专家估算法的时候，参与者会将很多可以量化、不可以量化的上下文信息都纳入到估算的考虑当中，因此有可能得到更有效的数据。
4.5 指标体系的局限性
从前面的过程中可以看到，度量体系的设计本身蕴含了很多人为的主观判断和取舍，面临着不少的局限性，所以肯定不能满足所有人的诉求。
对业务目标有帮助，能起到引导作用才是我们实施度量体系的价值所在。
4.6 指标体系需要演进
度量体系中的指标不是一成不变的，所谓“流水不腐，户枢不蠹，动也”。
企业内部和外部环境的变化不可避免，我们设计体系时所期望满足的目标和优先级也可能发生变化，因而需要随之增加、减少或是修改当前的指标。
当增加一个指标的时候，一定要记住重新审视一下己有的指标，看看是否有可以减去的，否则指标体系将会越来越沉重，体系的投资回报逐渐降低。
4.7 度量信息的传播和使用
1. 度量数据应该解决数据生产者的问题。
2. 各级组织有自己的期望和目标并需要上下双向沟通。
小结
今天参加了《研发教练大会》，收获和体会很大，对着自己的心智模型有了改变。有客观的数据，去直面团队变化，应该是团队转型的第一步。
