Google改进过程：
本文案例源自：《Measuring Engineering Productivity》
作者：Ciera Jaspen，Google
前言
随着敏捷开发、DevOps等方法论在软件行业持续运用，各种用来提升组织研发效率和产品质量的实践层出不穷，如何有效度量评估这些实践带来的改进和提升则成为一个重要的课题。建立一套完备的度量指标体系看似是解决这个问题的第一步。当然有不少知名企业已经率先完成这一步，比如：阿里研发效能体系[1]等。研发效能度量体系发展到今天看似即将抵达终点。但是这些指标体系有以下两个问题：
1.指标过于宏观，影响因素过多。实践则相对比较微观，直接使用这些宏观指标对于具体实践所单独起到的作用说不清，容易出现只要指标提升就万事大吉的现象。2.只描述了What，没介绍How。这个是二手知识的通病，我们需要对舶来品进一步消化和理解，形成原则性指导共识。
Google作为当代最为成功的数据驱动公司，我们来看看它的度量指标和具体实践是如何结合开展实施的。
Google的度量实践
从团队组成、度量是否必要、如何开展度量三个部分来介绍Google的度量实践。
团队组成
首先从组织层面说起，Google创建了一个专门研究工程效率的研究团队，这和大多数做DevOps的组织类似。但Google的特色在于其团队的多样性：不但有软件工程专家、资深研发大神，还拥有社会科学家，其中包括认知心理学和行为经济学。整个团队即可研究软件研发过程，也研究人性化方面，包括个人动机，激励结构和管理复杂任务的策略。团队的目标是采用数据驱动的方法来衡量和提高工程效率。
改进价值评估
不能为了度量而度量
在Google进行度量有一个前提：必须先回答下面的系列问题：期待获得什么样改进结果及原因？如果得到预期或非预期结果，将采取什么措施？谁将决定对结果采取行动，什么时候会采取行动？运用这些问题与研发团队交流，将会发现很多情况下，度量根本是不值得的：仅仅对度量结果感兴趣，没有后续措施的话，改进效果会大打折扣。
另外确保进行度量的人有权采取行动也很重要。需要了解决策者是谁，可能需要在有限的时间内为决策者提供他们所需的数据，在这种情况下，最好迎合决策者偏好。可以考虑以下问题：他们会认同从访谈中获取的情况来做出决策吗？他们是否信任访谈中的调查？他们信任调查结果或记录数据吗？他们对复杂的统计分析感到满意吗？如果决策者原则上不相信结果的形式，那么度量也就失去了意义。
GSM(Goals-Signals-Metrics)框架
在Google，使用目标/信号/指标(GSM)框架来指导目标导向型指标的创建。(Google UX领域的HEART模型[2]也是基于该框架)
目标是期望的最终结果。 它是根据从更高层次上理解的内容来表达的，不应包含具体的衡量方法的参考。
信号是目标达成与否的结果。 信号本身也可能无法测量。
指标是信号的代理。 代理的含义是指由于信号本身可能无法量化，因此需要通过指标来代理信号的量化。指标是一定可度量的内容。但指标可能不是理想的测量方法，但是已经足够接近了。
创建顺序：先创建目标，然后创建信号，最后创建指标，可以防止“路灯效应”。这说明人们倾向于使用易于获取和测量的指标，无论这些指标是否满足需求。而GSM则迫使思考哪些指标将真正对实现目标有帮助，而不是简单地获取现有指标。
路灯效应：“在路灯下寻找钥匙”，如果只看可以看到的地方，则可能找不到钥匙的真正所在。
其次，GSM通过鼓励在实际测量结果之前提出一种有原则的方法，一套适当的度量标准，从而帮助防止指标蠕变(注：长时间导致的指标差异)和指标偏差。考虑以下情况：在没有原则性方法的情况下选择指标，然后结果可能不符合利益相关者的期望。那时就会出现失效风险，利益相关者会建议使用他们认为会产生预期结果的不同指标。由于并无原则性方法，因此难以反驳。相反，GSM鼓励我们根据衡量原始目标的能力来选择指标。利益相关者可以轻松地看到这些指标如何映射到原始目标。
最后，GSM可以展示度量覆盖了哪些地方，哪些地方未被覆盖。当执行GSM流程时，需要列出所有目标并为每个目标创建信号。并非所有信号都是可测量的，使用GSM至少确定了不可测项，通过识别这些缺失的指标，可对创建新指标或度量价值进行评估。
重要的是保证可追溯性。对于每个度量指标，应该能够追溯到它代理的信号以及试图度量的目标。这样可以确保知道要度量哪些指标以及为什么要度量它们。
下面将对GSM框架进行介绍，并将其套用到Google曾经开展过的代码可读性提升实践。
制定改进目标(Goals)
目标应该根据期望来编写，而不参考任何度量相关的内容。这些目标本身是无法度量的，但在进一步提出信号并开始度量之前，每个人都应认可目标的正确性。
为了使之有效，首先需要确定一组正确的目标。这看起来很简单：团队难道会不知道他们的工作目标吗？但是，Google的研究团队发现，在许多情况下，由于目标设定问题导致度量的偏差。以可读性为例，假设团队仅专注于使可读性效率目标，则会导致代码质量问题。故团队会以此设定度量并跟踪，以了解完成评审过程耗时以及工程师对该过程的满意度。团队中的一名成员提出以下建议：
我有使代码评审更高效的办法：那就是不做代码评审。
尽管这是一个极端的例子，但团队在度量时有时会忘记初衷：过于专注于提高效率，以至于忽视了质量(反之亦然)。为了解决这个问题，Google的研究团队将生产效能分为五个核心元素。这五个元素相互制约，团队需要全面考量这些元素的目标，以确保不会顾此失彼。为了帮助人们记住所有五个组成元素，我们使用助记符“ QUANTS”模型来表达。
QUANTS组成
代码质量(Quality of the code)
产生的代码质量如何？测试用例是否足以防止回归？架构在降低风险和变更方面的表现如何？
工程师注意力(Attention from engineers)
工程师多久实现一次状态流动？他们被通知分散注意力的频度？工具是否支持工程师进行上下文切换？
智力复杂性(Intellectual complexity)
完成一项任务需要多少认知负担？要解决的问题的内在复杂性是什么？工程师需要处理不必要的复杂性吗？
速度与速率(Tempo and velocity)
工程师能多快完成任务？他们可以多快推送并发布？在给定的时间范围内他们完成多少个任务？
满意度(Satisfaction)
工程师对工具有多满意？工具满足工程师需求的程度如何？他们对工作和最终产品的满意度如何？工程师是否感到筋疲力尽？
QUANTS示例
回到可读性的例子，效能研究团队与可读性推进团队合作，确定了可读性过程的多个效能目标：
代码质量
由于可读性的提高，带来了更高质量的代码、更一致的代码、并促进了代码健康的文化。
工程师注意力
对于可读性来说，该领域没有任何目标。(并非所有有关工程效能的问题都涉及这五个要素的权衡)
智力复杂性
工程师通过可读性提升过程了解Google代码库和最佳编码实践，并获得指导。
速度与速率
通过可读性过程，工程师可以更快，更高效地完成工作任务。
满意度
工程师们看到了可读性提升的好处，并对参与其中抱有积极的感觉
确定结果信号(Signals)
信号是实现目标的方式。信号对度量没有强依赖，也就是说并非所有信号都可度量。信号与目标之间没有1：1的关系，每个目标至少应有一个信号，但也可能会有多个信号。一些目标也可能共享信号。
选取量化指标(Metrics)
指标最终确定信号的量化方式。指标本身并不是信号，而是信号的可测量代理。因为仅是代理，所以它们可能并不完美。因此当尝试对信号进行三角测量时，某些信号可能具有多个指标。
拿可读性改进举例：为了衡量在可读性提升后是否可以更快地评审工程师的代码，可以结合使用调查数据和代码提交日志数据，形成相应的指标。这些指标都没有真正提供潜在的事实。(日志指标可能无法衡量工程师花费在查看一段代码上的时间的全部情况，或者可能被当时其他的因素所混淆，例如代码变更的大小或难度) ，如果这些指标显示相悖的结果，则表明其中一个指标可能不正确，需要进一步探索。如果相同，则会为事实真相提供更多的信心。
另外，某些信号可能没有任何关联的度量指标，因此此时信号可能根本无法测量。例如，代码质量的度量。尽管学术文献已经提出许多关于代码质量的度量代理指标(圈复杂度、代码行数等等)，但没有一个指标是完备有效的。最终，尽管Google确实要求工程师对其代码质量进行自我评估，但最终决定不将其作为量化指标。
遵循GSM框架是阐明为什么要测量软件过程以及如何对其进行实际测量目标的好方式。但如果所选择的指标没有捕获所需的信号，那仍有可能无法说明全部情况。在Google，通过使用定性数据来验证指标并确保它们捕获了预期的信号。
采集提炼数据及数据指标验证
关于定量指标
定量指标非常有用，可以用来衡量全公司工程师在很长一段时间内的工作情况，并对结果充满信心。但定量指标的问题在于不提供任何上下文，无法解释为什么选择使用过时的工具来完成任务，为什么采用特殊工作流，或者为什么绕开标准流程。只有定性研究才能提供这些信息，只有对定性指标的研究才能提供有关流程改进后续步骤的洞见。根据Google的经验，当定量指标和定性指标不一致时，多半是因为定量指标没有捕获预期的结果。
定量指标：非常客观、具体，能准确反映工作成果，评价结果比较直观，效果好。
定性指标：是指无法直接通过数据计算分析评价内容，需对评价对象进行客观描述和分析来反映评价结果的指标。
基于GSM框架所建立的代码可读性QUANTS模型
| QUANTS | 目标 | 信号 | 指标 |
| 代码质量 | 由于可读性的提高，工程师编写了更高质量的代码 | 被教授可读性的工程师判断其代码的质量要高于未被教授可读性的工程师 | 季度调查：报告对自己的代码质量感到满意的工程师比例 |
| | 可读性过程对代码质量有积极影响 | 可读性调查：报告可读性评审对代码质量没有影响或负面影响的工程师比例 |
| | | 可读性调查：报告参与可读性过程已改善其团队的代码质量的工程师比例 |
| 由于可读性的提高，工程师编写了更加一致的代码。 | 作为可读性过程的一部分，可读性审查者会在代码审查中为工程师提供一致的反馈和指导 | 可读性调查：报告可读性审阅者的评论和可读性标准不一致的工程师比例 |
| 由于可读性的提高，工程师为代码健康文化做出了贡献 | 被授予可读性的工程师会在代码审查中定期评论样式及可读性问题 | 可读性调查：报告定期在代码审查中评论样式及可读性问题的工程师比例 |
| 工程师注意力 | N/A | N/A | N/A |
| 智力复杂性 | 由于可读性的开展结果，工程师们了解了Google代码库和最佳编码实践 | 工程师报告从可读性改进过程中学习 | 可读性调查：报告了解四个相关主题的工程师比例 |
| | | 可读性调查：报告学习或获得专业知识是可读性过程带来的优势的工程师比例 |
| 工程师在可读性过程中接受了指导 | 工程师报告他们与经验丰富的Google工程师进行了积极互动，他们在可读性过程中担任审阅者 | 可读性调查：报告与可读性审阅者一起工作是可读性过程的优势的工程师比例 |
| 速度与速率 | 由于可读性的提高，工程师的生产率更高 | 被教授可读性的工程师认为自己比未被授予可读性的工程师更有生产力 | 季度调查：报告高效率的工程师比例” |
| | 工程师报告完成可读性过程会对他们的工程速度产生积极影响 | 可读性调查：报告缺乏可读性会降低团队工程设计速度的工程师比例 |
| | 由被教授可读性的工程师编写的变更列表(CL)比未被教授可读性的工程师编写的CL更快 | 日志数据：具有可读性和不可读性的作者对CL审核的中位时间 |
| | 被教授可读性的工程师编写的CL，比未被教授可读性的工程师编写的CL，更容易通过代码审查来进行管理 | 日志数据：具有可读性和不可读性的作者编写CL的中位时间 |
| | 与未被教授可读性的工程师编写的CL相比，被教授可读性的工程师编写的CL通过代码审查的速度更快 | 日志数据：具有可读性和不可读性的作者提交CL的中位时间 |
| | 可读性过程不会对工程速度产生负面影响 | 可读性调查：报告可读性过程对其速度产生负面影响的工程师比例 |
| | | 可读性调查：报告可读性审阅者迅速做出响应的工程师比例 |
| | | 可读性调查：报告及时性是可读性的优势的工程师比例 |
| 满意度 | 工程师们看到了可读性过程的好处，并对参与过程抱有积极的感觉 | 工程师将可读性过程视为总体积极的体验 | 可读性调查：报告其在可读性过程方面的经验总体上是积极的工程师比例 |
| | 工程师认为可读性过程值得 | 可读性调查：报告可读性过程值得进行的工程师比例 |
| | | 可读性调查：报告可读性审查质量是流程优势的工程师比例 |
| | | 可读性调查：报告完整性是流程的优势的工程师比例 |
| | 工程师并不认为可读性过程令人沮丧 | 可读性调查：报告可读性过程不确定，不清楚，缓慢或令人沮丧的工程师比例 |
| | | 季度调查：报告对自己的工程速度感到满意的工程师比例 |
现在考虑表中显示的信号。可以创建哪些度量指标来衡量每个指标？其中一些信号可以通过分析工具和代码提交日志来测量。其余的只能通过直接询问工程师来衡量。还有一些可能并非完美的度量：例如我们如何真正地测量代码质量？
最终，当评估可读性对效能的影响时，我们最终结合了三个来源的指标：
1.首先，来自专门针对可读性改进过程的调研。以便立即获得可读性改进过程的反馈。该调研希望避免回忆偏差，但会导致近因偏差和抽样偏差。2.其次，使用大规模的季度调查来跟踪与可读性不一定相关的跟踪项(纯粹关于期望可读性会影响的指标)3.最后，使用细粒度代码日志指标来确定工程师完成特定任务的时间
回忆偏差：在对以前发生的事件或经验进行回忆时，由于回忆的准确性和完整性的差异所产生的系统偏差。 近因偏差：人们在判断事物发展趋势时，会认为未来事件将会和近期体验高度类似。 抽样偏差：在抽样过程由于一系列因素造成不符合随机抽样的原则，导致样本失去可以估计总体的能力(失真)。
规划后续行动及跟踪行动结果
在对某个主题进行研究后，Google团队会准备一份建议清单，以说明如何继续改进。可能包括：对工具提出新功能需求，改善工具的等待时间，改善文档，删除过时的流程，甚至更改工程师的激励结构。理想情况下，这些建议是“工具驱动的”，Google始终假设工程师将在适当数据和工具的支持下进行有效改进。
对于可读性而言，Google的研究表明总体上是值得的：实现可读性的工程师对该过程感到满意，并认为他们从中吸取了经验。采集的日志显示，工程师对代码的审查和提交速度也更快了，甚至不再需要那么多评审人员了。研究还显示该过程需要改进的地方：工程师反馈了该改进过程的一些痛点，基于这些痛点研究团队推动了对工具和流程进行改进，以使流程更快，更透明，从而使工程师拥有更好的体验。
总结
本文重点介绍Google作为一家以数据驱动闻名的公司是如何进行研发效能改进落地的全流程。其中实施的关键在于GSM目标驱动改进框架和QUANTS元素模型的合理运用，使得整个度量改进更加聚焦和完备。希望对你有所帮助：)
References
[1] 阿里研发效能体系: https://zhuanlan.zhihu.com/p/57029968[2] HEART模型: http://www.mysecretrainbow.com/blog/12460.html
转播
