这些年，由于一直在拥有数万名研发人员的大型互联网公司做DevOps和研发效能的相关工作，做过敏捷和持续交付实践的大规模推广，组建并带领团队从零开始建设服务于全公司的、一体化的、一站式的DevOps平台，发起公司级效能度量委员会并制定度量指标体系；而且在技术社区持续活跃，在各类综合性/专业性技术大会中担任出品人等角色，对互联网大厂的研发效能提升思路和做法有一定的理解，因此，把这些经验总结起来，形成了一个具有增强回路效果的研发效能提升体系，我们称之为研发效能的“黄金三角”，如图1所示。
图1 研发效能的“黄金三角”
研发效能的“黄金三角”由三部分组成，分别是效能实践、效能平台和效能度量，它们彼此独立，又相互关联。
其关联关系如下。
- 效能实践中的优秀实践可以固化、沉淀到效能平台；反过来，效能平台支撑效能实践的落地。
- 效能平台产生的大量研发数据形成了效能度量中的效能洞察；反过来，效能度量可以持续观测效能平台中产生的数据，进行下钻和深入分析。
- 效能度量中的洞察和分析结果可用于针对性地优化效能实践；反过来，效能实践可以给效能度量更多的输入，帮助其完善度量指标集和分析方法。
因此，效能实践、效能平台和效能度量形成了一个彼此增强、迭代优化的回路，有效利用好这个增强回路可以帮助企业持续提升研发效能。
下面我们分别从目标、价值主张、实践分类和实施建议几个维度展开讨论。
1
效能实践
研发效能实践地图如图2所示。
图2 研发效能实践地图
目标：提炼和采纳与上下文匹配的DevOps及效能提升实践。
价值主张：产品导向 工程卓越。
- 产品导向：区别于项目导向的交付模式（在特定时间内，以相对确定的预算和人力交付预先计划的内容），我们更倾向于以产品导向的交付模式组织相关效能实践。产品导向可以让我们面向长期的业务价值，组织长期稳定的敏捷团队，持续迭代和优化产品。我们承认需求的不确定性，要持续改进产品，而不是简单地遵从既定计划；我们要考虑长期产品和团队能力的建设，而不是把短期项目做完了事；我们要考虑持续为客户创造价值，而不是看项目有没有超过预算；我们要面向工作结果进行响应，而不是盯着一些局部的工作产出。
- 工程卓越：我们必须持续关注工程和技术的卓越性，而不仅仅是交付了多少需求或特性。比起多完成几个小功能，也许工程和技术上的提升所带来的价值会更大。就像微软CEO萨蒂亚·纳德拉所说：“每一天我都在开发新特性和提升我们的生产力之间进行权衡。”我们要追求用工程化的方法持续把确定性、重复性、机械性的任务自动化，从而在提升效率的同时让工程师有更多时间花在有创造性的事情上。用工程化的思路解决问题，追求工程卓越就是一种“反内卷”的表现。
实践分类：业务敏捷创新实践、敏捷精益协作实践、持续交付工程实践、云原生技术实践、组织和团队拓扑等。
实施建议：业界一致认为，DevOps领域和研发效能领域从来没有“一刀切”的解决方案，不要迷信某个成熟模型或某种规模化框架就一定能对你有帮助。正确的实践选择一定要基于上下文，找出价值流中最大的障碍，选取工具箱中适当的实践，从小范围开始，纵向进行实验，应用敏捷思维来提升组织效能，逐个解决瓶颈问题，循环往复。
2
效能平台
效能平台框架如图3所示。
目标：打造一站式、一体化的效能平台，支撑软件交付全生命周期。
价值主张：自动化 自助化、场景化 生态化。
图3 效能平台框架
- 自动化：自动化很好理解，DevOps讲究“自动化一切”，这正是DevOps的精髓“CALMS”中的A（Automation），研究表明高效能的企业在自动化构建、自动化测试、自动化环境创建和部署、自动化监控和可观测性等方面要远远好于中低效能的企业。
- 自助化：自助化代表上下游角色可以通过平台紧密衔接，在工具平台被某种角色创建出来之后，上下游的其他角色应该都可以按需、自助地使用，降低了对某种角色或者某个人的依赖，这样组织协作效率才能提升。
- 场景化：我们经常看到很多所谓的“一站式、一体化”，是按功能领域进行划分并展现相关能力的，或者说是一个“拼凑”起来的平台。而真正让管理者和工程师使用顺手的、易用的平台一定是按研发场景进行组织的。比如，以某一产品为主线贯穿DevOps流程，方便用户管理产品的相关需求，创建特性分支，迭代开发和交付。同样，以应用为主线对运维人员来讲会更加友好。
- 生态化：在互联网大厂搭建效能平台时，遇到的普遍难点是业务复杂、规模庞大、业务独特、场景众多，很难通过一个团队的努力满足整个公司的需求。但是如果各个业务部门什么都自己做、重复造“轮子”，甚至相互进行恶性竞争就更不好了。因此，平台建设者应该更加开放，分离平台底座和原子能力的建设，即通过生态合作伙伴关系，促进公司效能平台的良性发展。从公司角度来看，减少重复建设和避免内耗，也都是“反内卷”的表现。
实施建议：效能平台的建设切忌开始就追求“大而全”，所谓的“一站式、一体化”只是手段，不是目的，最终以能满足研发场景的诉求为主。尤其是在平台建设初期，不妨以支持To B客户的思维来运营平台，深度绑定和跟进种子团队，深刻理解业务痛点和需求，这样做出来的平台马上就会有人用，然后收集反馈，像滚雪球一样越做越完善。另外，还要注重需求价值流和工程价值流之间的联动，而不要将其分裂成毫无关联的两个系统。
3
效能度量
目标：在正确的方向上开展研发效能度量和数据洞察，指导和驱动效能改进和提升。
价值主张：数据驱动 实验思维。
- 数据驱动：我们经常遇到的现象是，一个组织或者团队在消耗了大量的“变革”时间成本和人力资源后，却无法回答一些看似本质的问题。比如，你们的研发效能到底怎么样？比别的公司或团队的好还是差？瓶颈和问题是什么？采纳了敏捷或DevOps实践之后有没有效果？下一步应该采取什么行动？我认为，效能度量的目标就是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能，而不要总是凭直觉感性地说“我觉得……”。用真实和有效的数据说话，勇于挑战现有流程和规则，直指研发痛点和根本原因，也是一种“反内卷”的表现。
- 实验思维：研发效能提升没有“一招鲜，吃遍天”的万能招式，而是要基于上下文进行有针对性的实验和探索。比如，想提升线上质量，降低缺陷密度，经验告诉我们应该去加强单元测试的覆盖，完善代码评审机制，做好自动化测试案例的补充。但是，这真的有效吗？我们通过数据来看，很可能没有任何效果！并不是说这些实践不该做，而是可能做得不到位。比如，只是为了指标好看，编写缺少断言的单元测试，找熟人走过场通过代码评审，覆盖一些非热点代码来硬凑测试覆盖率目标等。因此，我们需要实验思维，找到真正有用的改进活动及其与结果之间的因果关系，有的放矢才会更有效率和效果。
实施建议：效能度量本身也是一个比较复杂的体系，包含自动采集效能数据、度量指标体系、度量分析模型、度量产品建设、数据驱动和实验思维等多个方面，将它们整理后，称为“研发效能度量的五项精进”，如图4所示。
图4 研发效能度量的五项精进
（1）构建自动采集效能数据的能力。通过系统分层处理好数据接入、存储计算和数据分析。
（2）设计效能度量指标体系。选取结果指标用于评估能力，选取过程指标用于指导分析改进。
（3）建立效能度量分析模型。这里的模型是指对研发效能问题、规律进行抽象后的一种形式化的表达方式。模型有很多种，如组织效能模型（战略资源投入分布和合理性）、产品/团队效能模型、工程师效能模型等。我们还要合理采用趋势分析、相关性分析、诊断分析等方法，分析效能问题，指导效能改进。
（4）设计和实现效能度量产品。首先将数据转化为信息，然后将信息转化为知识，让用户可以自助消费数据，主动进行分析和洞察。
（5）实现有效的效能数据运营体系。要避免不正当使用度量而产生的负面效果，避免将度量指标KPI化而导致“造数据”的短视行为。效能改进的运作模式也很重要，如果只是把数据报表放在那里，效能不会自己变好，需要有团队或专人负责推动改进。
与研发效能相关的话题是不是很有意思？这里还有很多值得展开和深度思考的内容，比如：
- 研发效能提升的实践应该如何选择？管理和工程技术实践都有哪些？
- 研发效能度量指标体系应该如何设计？效能数据如何分析？
- 促进高效能的组织、结构和个人能力提升的模型是怎样的？
- 研发效能如何进行规模化扩展？
- 研发效能的支撑工具如何选择和落地？
- 各个行业研发效能提升的综合案例有哪些？
在这本书中，不仅仅面向研发效能，对于质量效能也做了很多阐述，随着软件系统规模的持续增大，业务复杂度的持续增加，软件测试的复杂度也随之越来越大。而软件测试工作复杂度的直接体现就是测试用例编写、维护、执行和管理，所以编写易读、易维护和易管理的测试用例可以有效的降低测试工作的复杂度，比如使用免费质量管理工具itest。
这款工具平台查看的地址是www.itest.work
以上每个问题都值得单独探讨，我们会在《软件研发效能提升实践》一书中一一分享。
本文摘自《软件研发效能提升实践》一书，欢迎阅读本书了解更多相关内容。
