腾讯资深技术专家：研发效能的五大灵魂拷问
茹炳晟
腾讯TEG基础架构部资深技术专家
知名实战派软件质量和研发工程效能专家,腾讯云最具价值专家TVP，畅销书《测试工程师全栈技术进阶与实践》和《高效自动化测试平台：设计与开发实战》作者。
内容来源：全球C++及系统软件技术大会
首先我们来看一下研发效能的5个灵魂拷问：时代变了，很多东西的底层逻辑发生了很大变化，软件研发行业也发生了天翻地覆的变化，早年基本上是软件巨头来主导整个行业。所以在那个时代更多的认为是大鱼吃小鱼的时代。但是今天软件行业，尤其消费互联网一侧的变化已经出现了，大鱼吃不了小鱼， 而且“大”已经成为反应迟钝的代名词，更加追求的是“快”，因为对市场的把握、需求的梳理这些能力大家都类似的，就看谁能够最快速做系统性考虑。
从研发效能整体来说可以归结成“方轮子效应”。图中拉车的是老板、业务，他看准了这个方向，全力朝着他的目标前进，他雇用了很多程序员去帮他把车往目标方向推进。在推进过程，老板不知道轮子是方的；员工在推车过程中，由于担心业务停滞也不敢停下来。
这就是为什么我们在做很多架构设置、功能交付的时候，虽然知道研发模式、实现方式很挫但是只要能够把功能交付出去就万事大吉。那如何面对方轮子效应 我们引发出了五个灵魂拷问。
第一个拷问说研发团队的忙碌能不能代表高效。举一个比较扎心的例子，有一些猛将型的员工，线上出了生产事故，第一个冲上去乒乒乓乓在生产环境敲一通代码，紧急修复，整个过程像英雄一样的存在。你觉得他是优秀的员工吗？实际上你会觉得为什么出了这个故障要他来修？这个坑是不是他挖的呢？
整个软件的交付过程当中 我们大量的工作都集中在“救火”的象限，既重要又紧急 的事情，不做影响业务。如果你的业务团队 、研发团队 、运维团队大量的时间花在救火的话，肯定是忙碌的，但并不代表是高效的。
第二个敏捷是研发效能提升的银弹吗？举个例子，人在A点，要去向这个B点，那两点之间最短的距离一定是直线。对应到软件的研发模式，如果软件最重要的功能点是明确的，那两点之间最短的直线，对应的恰恰是瀑布模型。
所以敏捷真的适合所有吗？实际上敏捷要求的“小步快跑”是指能够迅速适应变化。还是刚才这个例子，从A点走向B点的过程中，如果看不清B点，能站着不走吗？显然不行，必须先走两步，做一个迭代。当我做完这个迭代时，去观察B点是近了还是远了。如果远了，有两种可能，一种可能是一开始没有看清，还有一种可能需求本身已经发生变化，或者需求得到了进一步的释放。再走接下来的两步就可以朝着新的方向快速调整。
所以敏捷的“快”体现在船小好调头上，而不是快速交付。因为对于瀑布模型，敏捷并没有带来效率上的提升。但是敏捷开发不仅增加了沟通上的成本、每天站会的成本、回顾会的成本 、任务打分的成本，还增加了每个阶段额外投入的自化测试成本，每个迭代都要有测试，每个迭代都要有自动化，投入必然是增大的。所以说敏捷能不能提高研发效率取决于项目类型。
谈敏捷就必须得看自动化，每个迭代做完的功能 在下一个迭代必须要被重复验证，所以一定需要自动化。自动化测试真的让整个研发的效率或者质量提升了吗？其实很多时候并不是。
自动化测试原来应该是手段，却变成了目的。举个例子，因为敏捷追求两个迭代之间的功能要被重新验证，必须要做自动化。所以很多项目里行政上有这样的规定：两个迭代之间必须做自动化；自动化测试必须达到多少等等。测试有这样的指标要求，有限工作时长内必然是先去完成自动化，而更探索性的、多方位的去使用软件，尝试发现更多问题的时间被开发自动化脚本所占据。在这种模式下面，得到的就是自动化，而不是高质量。
如何面对呢？应该说，自动化测试从敏捷的角度来讲就不应该做。尤其在前面一个功能被实现完成之后，在第一个迭代、第二个迭代应该更多的把时间和精力，放在如何的去测试这个软件，多方位多角度使用这个软件，以探索性的方式去发现更多问题。一两个迭代之后，在功能趋向于稳定的基础上，把核心路径拿出来做自动化。
第四个要做得快，“快”是一个很主观的概念，如何做得快，要有度量。管理学大师比德德鲁克说过：如果你不能衡量他，那你就没有办法改进他。这句话放在研发软件或者研发效能领域是否成立呢？研发效能领域里面，通常存在一个很普遍的现象：你度量什么，你就会得到什么，但是一定不是以你所期望的方式得到。
举个例子来讲，如果通过千行代码的Bug概率来衡量代码质量，开发人员会怎做？把代码函数分母搞大一点， 一行分两行写，注释多写几行，空格多放几个。Bug率降了吗？最终目的达到了吗？
而软件真的能度量吗？如果你认为软件的研发过程是能度量的，那你就是用传统的科学管理的思维来管理软件的研发，而软件研发是一个创造性的劳动。
上述四个拷问基本上都是基于流程过程或者基于技术，那第五个拷问是说研发效率是不是一定由技术来驱动。有个很扎心的结论：其实很多研发效率的提升或者大的研发效率的提升可以不基于技术，只要你站在更高的位置。有一个非官方的数据,一个Bug 的生命周期从被发现到修复关闭，假定生命周期是100个小时，真正有效的时长不足10%。90%以上的时间是在流程中的等待，在搭建设施环境，在沟通的成本上。如何去除这种等待，如何去除这种流程, 效果远远比单点的技术提升要大得多的。
研发效能的点点滴滴
讲了这么多，那到底什么是研发效能？很多人认为软件的架构是设计出来的，其实软件的架构都生长出来的。架构师只是搭了个骨架，同样一个骨架可以生长出不同的架构。换句话说，它通过历史的纬度不断迭代、变更适应。研发效能是个复杂的概念，他是先有这个现象，再去把它总结、它定义。
给大家看一些案例，大家如何来做原型？像现在的AI技术就很方便。如图，你可以当场在后面的白板上去画软件界面的设置，摄像头对着白板，通过模式识别的方法，实时识别、生成前端代码的预览。AI技术的应用可以大幅提升我们的效能。
现在的软件普遍都在走微服务务架构，一旦微服务之后是带来一个特点是什么？开发人员对一个单点开发的微服务做测试，你会发现难的不是测试本身而是搭环境。因为你这个微服务要跟其他的服务交互，要在本地保证服务可测的话，就必须保证要把调用服务在本地拉起来，还要保证跟开发版本一样，保证启停的顺序，保证版本的依赖方式。这种方式显然不高效。高效的玩法是做一套公共的基础环境，定期跟生产环境去做同步，这样一来测试的效果会有大幅度提升，也更愿意主动的去做测试。
通过这两个例子，我们来看一下 研发效能到底是什么东西。这是我归纳的一句话叫：研发效能的“第一性原理”：顺畅，高质量地持续交付有效价值的闭环。
顺畅指的是整个的价值交付，从需求变成可交付的软件，并且让用户用到软件的过程必须顺畅。不能做完功能没有发布窗口或者没有办法做测试等等都是不顺畅的表现。
第二个要高质量，如果你跑得快、质量差，换句话说也会死的越快。所以说要跑得快，同时质量要求还是比较高的。
持续交付是指效率能够做的很高，也能够系统化的保证这个效率，而不是通过加班等不可持续的方式。我们要求持续交付要是持续的、系统性的、高效的。
有效价值是针对需求，更多是从产品经理角色去讲，要听用户讲，但不要去照着做。
最后要形成闭环，要能够快速反馈。
在这下面就引出了五个持续：开发过程要能够持续，不能中断；CI集成过程要能持续；测试要能够持续，阶段性交付、接口、模块跟模块之间的集成能做测试。而且能非常轻量级的来做测试，不能变成一锤子买卖；持续交付，东西做完能快速给到生产环境做部署、发布；对于互联网产品还要持续的运维过程。
在这个理念下，我们关注价值的流动速度，关注长期稳定的质量，同时关心客户价值的交付，整个过程必须透明化，以数据驱动的方式来展开 这就是我对研发效能的比较系统的定义。
研发效能提升经验分享
那么研发效能的提升，尤其对大的企业，可以使用MVP的思想。从研发效能角度来讲，不要做一个流程或一个工序对现在没用但为了以后有用。一定要把一个有价值的东西拆成一个小片，哪怕改进点是非常小，但是对你的用户或者研效平台的使用者可以带来实际的价值。
在这种思想下面，就引出了我们研发效能的一套经验。
从痛点入手（从下往上走）
本地编译时间长就从分布式编译入手；自动化测试用例数量很大执行维护成本很高，可以做微服务；数据准备困难，可以通过测试中台去打造Test Data Service。
从全局切入
刚才已经讲过的一个BUG的流转生命周期，一定要站在更高的宏观视角去审视效率的提升，单点优化带来的提升是有限的，全流程拉通目前阶段来看更有价值。
用户获益
第一是伪需求，做研发效能经常会碰到的尴尬情况，比如说要帮用户做测速率的版本，而用户连自动化测试平台都没有建起来。所以这种情况下，那怎么来识别需求，就看看业务团队自己有没有在做。
第二是结构问题有一句话是结构不对，什么都不对。那结构问题讲的是什么呢？要把厉害关系理清楚，用体制帮你去推进，制定好规则，其他由系统去保证。做底层逻辑设计时， 要假设任何人都是自私自利的。如果体制设计能在每个人都自私自利的情况下获得全局利益最大化，那这个制度设计就是成功的。
最后是服务意识，做研发效能的人要放低姿态。用户用工具，驱动产品的过程，必须提供全程的保姆式服务甚至要帮助“背锅”。
持续改进
永远不要想把一件事情一下子就吃透。
全局优化（自上而下）
研发效能到底从下往上做还是从上往下做？答案是两边要同时做。靠工程师推不动，老板不知道你的工程上有哪些东西可以改进，这些东西的改进点一定是在工程师更了解。
效率平台的灵活性
主要的一个点在于我们应该尽可能的去搭建一个平台，而不是把所有的东西都自己来做。当规模做大到一定程度抽象成平台，然后让用户按需使用垂直能力来符合业务上的一些特殊的要求。
杜绝掩耳盗铃
虚荣性指标和可执行指标要重点强调，为什么要做研发效能，需要有指标来度量就有两种指标一种叫虚荣性指标。比如Sonar在企业内部推广之后，怎么来衡量推广成功还是失败？很多企业都用有多少项目或者有多少百分比的项目接入了Sonar，这个就是虚荣性指标。Sonar的可执行指标不是接入百分比或者接入用户数量、项目数量，而应该是Sonar里面的关键问题存在时长，Sonar的P1的issue的增长趋势、变化趋势，能够知道接下来行动的度量指标才是有益的。
吃自己的狗粮
我在腾讯内部负责研发效能资源平台，资源平台本身是为TEG各个部门产品提供研发效率的提升，提供Devops、测试、监控、运维相关的能力。那我们这个平台自己的开发遵不遵守我们这套体系呢？答案是我们必须用自己的产品来发规范和内容的，因为只有这样我们才能明白用户的疾苦。
研发效能的发展方向与未来展望
最后我们来聊一聊研发效能行业的趋势。
研发流程全链路打通与过程可视化，这是必然的。现在的研发效能差在哪里，都是单点提升。比如说测试跟开发有没有打通，运维如何跟开发人员结合，安全测试如何融入到整个研发体系当中去，这些东西都是可以深入讨论提升的。全链路打通同时要过程可视化。所有的数据要有看板，数据一定是要通过工具自动触发状态的变更、流转，让整个过程可视化，让数据可相信。
第二个是敏态和稳态的齐头并进。一些快速迭代变更的产品要用敏态，但是一些后端的、偏底层的、稳态的，瀑布模型依然有它的市场，依然有它的业务场景。
第三个研发能力的中台沉淀，很多东西跨部门跨产品，有很多努力是应该被沉淀下来，尤其像Devops，自动化的测试，静态代码的分析等等，都应该要被沉淀成一个垂直的单点。然后可以在研发效能的上层平台做组合。
第四个是讲研发效能不是拍脑袋，所有的东西都应该有数据来支撑。
最后研发效能从有到无，研发效能的核心能力应该融入了你的研发过程，深入人心。
谢谢大家。
扫描下方二维码
免费领取白皮书
