双专家案解剖大回放：京东研发效能提升实践

摘要：本次活动的话题是以“京东研发效能提升实践”为主题，以翰德恩咨询公司两位世界500强大厂背景的老师分享，嘉宾之间对话，以及观众与嘉宾对话的方式，深度剖析京东如何利用规模化DevOps提升研发效能。

每月举办的明兰面对面专题直播，在6月22日拉开了序幕。本次活动的话题是以“京东研发效能提升实践”为主题，以翰德恩咨询公司两位世界500强大厂背景的老师分享，嘉宾之间对话，以及观众与嘉宾对话的方式，深度剖析京东如何利用规模化DevOps提升研发效能。

本次活动我们邀请到了两位嘉宾—师资阵容如下：

王明兰老师：翰德恩创始人，原华为企业精益敏捷专家；

熊志男老师：翰德恩高级技术咨询师，原京东DevOps平台产品经理&研发效能专家。

本次分享，熊老师主要围绕以下三点进行讲解：

1. 规模化研发效能提升实践；

2. 研发效能工具的持续演进；

3. 研发效能提升的关键角色；

一 规模化研发效能提升实践

话题首先以京东的研发效能历程展开，分为别以下三个阶段：

2015年~2018年：业务研发的效能提升实践：

这个时期，京东处于高速发展阶段。2014年京东在美国纳斯达克上市，随之而来的是业务的快速增长。在此期间的研发效能实践是由各业务线的研发团队来自发驱动的，提升效能的目的也很明确，就是：一方面要快速响应业务方的需求；另外一方面要保障系统的质量。

2019年后：零售体系的研发效能度量

此时，开始在集团层面大规模推动研发效能度量机制，首先是从零售体系开始推行，参与方包含前台和中台的技术研发团队。

2020年：多业务形态的研发效能体系

发展到这个阶段，各个业务线和研发体系都有自己的研发效能工具链，可以称为一个小闭环。目的是为了在集团层面实现研发流程和数据的打通，同时减少工具的重复建设，开始整合研发效能体系，要做到一套体系适配多业务形态，包含金融，零售，物流以及其他业务线。

研发效能提升是需要两种类型的团队相互配合开展的，第一个就是业务研发团队，第二个是效能工具团队。在双方的紧密配合下，研发效能提升的目标就可以从理想变为现实。

接下来，熊老师就通过三个具体的案例来分享下整个实践落地的过程。

案例一：敏捷先锋队的持续集成实践

这是个公司内一个边缘化的团队逆袭的过程，他们是一帮志同道者的敏捷软件开发拥趸者，通过敏捷转型和引入优秀的工程实践来实现了效率和质量的提升，带来业务的良性增长和用户的友好反馈。

主要从以下三个方面进行剖析：

1. 组织文化：全功能团队，自组织，工程师文化

2. 工程实践：单分支开发，代码评审，持续构建，自动化部署，单元测试，自动化测试，代码扫码，灰度发布

3. 工具支撑：开源工具为主，包含：Jenkins,Findbugs,SonarQube,Zookeeper等

案例二：研发业务线持续交付流水线

通过“案例一”中敏捷先锋队团队的成功证明了通过应用优秀的敏捷工程实践是可以带来效能提升的，因此开始在百人规模的研发团队进行推广实施。可是在执行当中，却遇到了很多的问题，当时是从以下几方面入手来解决规模化落地的问题的。

l 流程机制：流程定制化，分层分级制定标准

l 流水线：单点切入，工具链打通

l 工程师：优先解决痛点，持续提升质量意识

案例三：规模化的全生命周期研发效能度量

熊老师分别从四个维度介绍了规模化的全生命周期效能度量，分别是：价值流交付模型、数据关系、度量平台和实践落地。

- 价值流交付模型

众所周知，不管是做研发效能还是DevOps,最主要的是要构建价值流交付模型，（下图为京东内部价值流梳理图）

说起研发效能度量，经常说提起标准化和定制化的问题，熊老师进行了以下解读：

标准化:首先纵观整个软件开发生命周期，从大的阶段来说是一致的和标准化的。也就是从公司层面出发，需要保持一致，做标准化度量。从业务提出需求开始，再到业务验收，形成大的闭环，构成整个交付周期。

定制化：在大的阶段内部，不同的团队可能会定制自己的小的阶段，比如需求等待，开发等待和测试等待等自定义阶段的设置，是为了满足不同团队定制化的需求。

- 数据关系图

理清楚研发过程中的一些效能相关的数据，并在数据之间建立关联，是度量成功的关键因素之一。这里列出的并不一定包含所有元数据，而是列出了两种重要的数据类型，一类是管理类数据、一类是工程类数据，建立两种数据之间的关联关系是至关重要的。

- 度量平台

以上所有步骤，都需要平台的支撑，下图能带给我们答案。

- 实践落地

熊老师表示，我们做了以上这些动作还是远远不够的，规模化的全生命周期效能度量最难的是“实践落地”。其中有以下四种角色来共同做这件事情：

二、研发效能工具的持续演进；

熊老师分享了研发效能工具演进的路线：从单点自动化，到工具链打通，再到统一平台。

单点自动化有限解决研发过程中单点的效率问题，而从构建和发布来切入是很多团队的做法，京东内部就是这么做的，因此最早实现的是构建自动化和发布自动化。下图是其技术演进的过程。

当一个需求和用户故事被研发团队受理以后，往往在测试阶段是耗时最长的，下图中的测试自动化是代表广义上的测试，即包含：自动部署测试环境、自动代码扫描、自动化接口测试、自动化测试数据构造和自动化单元测试。

单点效率的提升，不能代表全局效率提升，因此还需要通过工具链打通来实现全流程的效率提升，下图是一个业务闭环的研发团队通过持续集成系统打通工程域各单点工具的案例。

在工具链打通的实践过程中有一种方式，就是产品、开发和测试仍然用不同的工具，只是通过消息通知或者接口调用的方式实现数据的同步和步骤的协同。在一定时期，这种方式是能够起到积极作用的，随着效能数据的规则增长和复杂度增加，这种方式常常会遇到一些同步不及时和数据不准确的问题。

由各个业务研发团队自行推动的工具链打通，往往在各自业务环节内实现闭环，同时会出现每个不同有不同的持续集成平台的情况，只是会应用一些公司层面公共的基础能力。

在实现公司层面平台整合的道路上，遇到了各种各样的问题，有些做的比较成功，有些却遇到了难以突破的瓶颈。其中比较成功的案例就是基于金融业务的强管控的一站式DevOps平台，实现了管理域和工程域的工具和流程的统一，整个平台内嵌了质量和安全的自动化检查机制和流水线门禁，很好的支撑了业务研发团队对于质量和效能方面的诉求。

而当需要在多业务形态基础上构建统一的研发效能平台时，“开放化”就成了唯一的实现路径。通过开放化的插件机制，采用可插拔的方式来选择不同的原子能力。比如可以选择通过SonarQube来进行代码扫描，也可以通过Infer或者其他自研的引擎，一切都基于业务研发团队的实际需求。

三、研发效能提升的关键角色；

最后，熊老师基于在研发效能提升的实际过程中的经验，分享了推动研发效能提升的三个关键角色。分别为：PMO部门、效能工具团队和研发架构师。

其中PMO部门常常作为研发效能提升这件事的首先发起者，在京东内部早期的持续集成实践就是由集团项目管理相关部门发起的。在后面持续的演进过程中，也是始终发挥了至关重要的作用。可以说PMO部门是流程、方法和实践的有力“ 推动”者。

无论是公司层面公共的效能工具团队或者是业务线内部的工具小组，都始终在致力于通过应用先进的技术来驱动工程实践的落地，是研发效能提升的“ 支撑”者。

而研发团队的架构师起到的是“ 拉动”的作用，架构师在业务研发团队内部一般具有较高的影响力，其本身对追求卓越的，往往在代码质量提升、架构优化、效能度量和工程师文化建设等事情上，架构师都担任了引领者的作用。因此我认为在企业内部实现研发效能提升，研发架构师是一个至关重要的核心角色。

嘉宾分享结束后，就有很多同学迫不及待地向讲师提问了~

问题一：在工具链打通的时候，需求链变更，是通知到所有人还是指定人，如果是指定人是否会出现遗漏？

熊老师：需求变更的通知一定是要通知相关人，即：提出人-受理人-关注人。为了减少不必要的打扰，一般不用通知到所有人，通知干系人即可，例如：产品经理，开发，测试，以及他们的Leader。

问题二：提测要求比较严格，要根据要求进行开发自测，代码评审，产品体验后才可以提测，有时候已经达到提测要求，但是走流程还需要一些时间，有没有更好的办法加快提测流程？

熊老师：有一种方法，不是从提测的事件触发做这些流程，而是检查提测之前是否做了开发自测，代码评审这些事情。在提测之前我是知道了变更了哪些代码范围的，然后针对代码范围，只要做过评审、自测和产品体验就OK了。

问题三：在度量过程中，度量效率中的需求吞吐量，度量需求吞吐量的时候会对于需求颗粒度的的划分有歧义，请问老师有标准实践吗？

明兰老师：这个指标不适合把各个团队横向比较，比如说做前端和后端的需求的数量、需求粒度本身有很大差异，建议团队自己跟自己的历史比，持续改善自己的吞吐率。设置度量指标的意义是，要回归到本质，即：是为了牵引团队改善，如果我们牵引的行为是正向的话，是一个很好的事情，比如说，通过度量机制牵引了团队把需求拆小，可以以小需求为单位来开展开发-测试-交付，缩短反馈周期，这是值得鼓励的事情。