业界对于软件研发效能普遍共识的定义是，软件研发效能是一种能力，它能够帮助企业更快速地响应市场机会，更高质量地满足客户的真实需求，更低成本地交付、维护与更新，从而创造更优的业务价值。
但在实践中提升软件研发效能会面临诸多难点，如业务需求复杂多变、架构臃肿而决策缓慢、遗留代码有雷、人员沟通不畅、能力参差不齐等等。因此提升软件研发效能是复杂的系统工程，首先可以从工程实践做起，优秀的工程实践是基础，进而把这些实践沉淀、固化到工具平台中，同时工具平台也可支撑工程实践的落地，而且工具平台积累的大量研发数据，为度量分析提供了基础，度量分析形成的洞察可以促进效能的针对性优化提升。工程实践、工具平台与度量分析，这三者是一个紧密相关且互相牵连的体系，共同促进软件研发效能提升。01工程实践
按照软件研发生命周期来看，工程实践大概是从业务规划到实现验证到发布到运维这样一个循环的流程，其核心价值观点是为客户创造业务价值。由于工程实践比较多，本次挑选几个做介绍。
领域驱动。从传统意义来说，技术人员与客户的属性相距较远，彼此之间都不懂对方的领域，沟通起来会出现巨大的鸿沟，很多业务系统在这方面就会变得很不可用。而领域模型的本质，就是要贯通整个业务价值需求框架实现验证，这就使得所有的前端业务人员和后端技术人员甚至运维人员，要能够在一个共同的语言规范上进行讨论，能够对业务以及业务的实现环境和价值有一个共同的认知，这是领域驱动开发的基本框架。
KANO模型。该模型由日本管理学大师所倡导，是对用户需求分类优先排序的方法，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。将影响满意度的因素划分为五个类型：
1、基本型需求：是用户认为必须有的属性，当其特性不充足时用户很不满意，当其特性充足时用户也不会特别满意；2、期望型需求：用户的满意状况与需求的满足程度成比例关系，此类需求满足的程度越高，用户的满意度越高，反之用户的不满也会增加；3、兴奋型需求：不会被用户过分期望，此类需求即使没有得到满足，用户也不会有明显的不满意，但如果需求得到满足，用户会表现得很兴奋；4、无差异型需求：不论提供与否，对用户体验没有影响；5、反向型需求：用户没有这类需求，提供的越多用户越不满意。
代码静测。可以解决一系列的项目问题，如编码不规范、代码里含有敏感信息、依赖项有安全漏洞、编码缺陷等。但代码静测的使用常常也会陷入一些误区，如机械地、不定制化地应用代码扫描工具，像SonarQube有一系列的编码规则，工程师如果直接拿来用会扫描出很多问题，这在研发效能中并不能起到有效的帮助。还有一些误区，就是不频繁做，而在最后交差时拿出报告；实施静测，但不分析结果，也不修复问题；已经实施代码静测并改好问题，就认为可以减少测试。
精准测试。软件测试的根本价值，与其说是发现Bug，不如说是保障软件可以可靠地交付。但何时可以进行可靠地交付，涉及测试的范围、强度、深度，以及对测试结果的评估。最近业界在持续发布精准测试新的工程方法，特点是以变更提交为触发，能够更精确地标志出代码的变化，然后根据代码的变化开展精准测试，提供一系列的覆盖度指标，让精准测试更及时、更准确、更可信。然而，%覆盖就一定能发现所有Bug吗？应该追求%覆盖吗？从实际情况来看，过分追求覆盖度可能导致工程师在写代码时不会写断言，这是过度追求覆盖度导致的不良后果。
工程实践的实施，一定要围绕业务价值来开展，而不是业界有最新的工程技术就一定要在组织实现。产品和项目之间对于工程实践的选择，会产生各种影响。对所有工程技术的持续追求是工程师追求工匠精神的核心表现，但这些技术必须要通过实践来加以检验，然后才能知道它在组织里能起到什么作用，这是工程实践实事求是的价值观。
02工具平台
工具平台是对工程实践的承载，具备一系列的静态能力。在企业里，工具平台的建设通常由多个部门协作完成，且有整体的业务规划，以解决业务问题为导向，可以清楚认知到各部门的发力点，以及彼此之间的接口关系，同时能够保持某种开放性和弹性，通过合作共建达成目的。
建设工具平台，重点是价值流转关系。通常企业会把工具平台的价值流分为两个层级，一个是产品需求价值流，产品经理、项目经理、业务主管或企业老板会更