研发效能之我见

• 研发效能的目标
• • 研发效能目标的若干说明
• 研发效能的建设
• • 从CI/CD到DevOps
  • 从组件化到微服务
  • 从敏捷开发到OKR
• 附件

这个章节想讨论研发效能的目标，在张乐的《研发效能度量核心方法与实践：行业案例和关键原则》 研发效能的度量体系，介绍各大厂的主要做法。但个人对研发效能的做法，更倾向于理解为研发效能的目标。笔者所在的公司，研发效能的目标，主要追求以下两个：

• 交付速度：早期的时候，比较注重发布的频率，例如：一周发布1K次。中期开始，主要讲的是需求的响应周期，例如：特性的平均交付周期为1个月；
• 交付质量：主要考查产品交付后，半年内出线上BUG的数量；

• 关于交付速度、与交付质量的说法。
  在资源一定的场景下，一直认为交付速度、交付质量是一对比较矛盾体。如果更关注质量了，或许测试会更多些，发布就慢了点。有几个小心得：

  1. 有没有即可提高交付速度、也提升交付质量的做法呢？这个就要看研发效能做到什么程度了，对于非敏捷团队来说，还是比较容易的（但现在这种公司小了吧^-）。对于采用DevOps等先进经验的团队，可能就很难了；
  2. 对于交付速度、交付质量，也没有绝对的平衡点。 例如，对于服务端来说有，会更关注于交付速度点些；对于客户端来说，会更关注于交付质量些。毕竟，服务端分分钟钟就可以buffgix，但客户端的升级成本比较高；

• 为什么把研发效能理解为目标？
  研发效能的度量是一个很复杂的体系，涉及到需求、开发、运维等跨阶段、跨类型的指标监控体系。在实践当中，往往根据公司的业务特点按制定相关的研发效能目标，并跟随业务的发展、以及研发效能的建设而演进。

• 研发效能是针对团队的OKR，而不是针对个人的KPI。
  看到一些关于研发效能的实践，把指标设置成个人的KPI，如：代码产出、996，以及到有些团队将实施敏捷开发等当做研发效能的目标。然而，对于研发效能来说，是一个团队的OKR，在现有的条件下，逐步改优先开发过程、改善开发工具、整合开发资源进行的一场对有质量的软件交付的一块变革。有几个观点需要确认的：

  1. 研发效能的提升是需要成本的，随着指标的提升，成本也会逐渐增加；
  2. 研发效能的管理， 从实践上来说，正逐渐的以OKR取代KPI；
  3. 研发效能的提升，伴随着是工程师文化的建设，而不是忽略工程师的感受；

对于高效的交付系统的建设，一般为：

记得在04年的时候，就做过一个CI/CD的体系：

自然，后面Jenkins构建的输出已经不是war了，而是一个Docker镜像，Salt Stack的部署系统也改成了K8S的管理系统。

其实早期的体系中，我们只想做一个：

• Daily Build、Daily Test

然而随着Docker的出现，以及对高效率发布的需求，逐渐转向了DevOps平台的建设。

一个完整的DevOps平台的建设，涵盖了整个软件的生命周期，如上图所示（看图，就不展开说明了，东西很多）。其实，一个大家可能会比较在意的系统，在于：有没有现成的系统，可以把上述的内容都涵盖在一起呢，如：Jira 、阿里的云效等。但比较遗憾的事情在于，其实这些系统并没把整体的系统做集成，它们基本上只把左边(深色部分的系统)集成好了，但对于监控、运维部分的内容，实质上都需要做额外的集成。除了商业系统外，也开源的系统可用，但这些系统都只是实现各自独立的功能，集成部分就需要自己操心了。

DevOps部分，实现了研发效能在工具层面上的支撑。现在在设计的角度上来讲，如何一种方式能让团队跑起来。诚然，对于一个铁板一块的系统来说，想让它跑起来是很困难的。因此，我们就需要一个分而治之的方案。按微服务的讲法，比较推崇Amazon的Two Pizza Team。

这里把组件化跟微服务放在一起讲了，有必要说明一下：

• 组件化，一般人的理解上，更像是一个库，当各端开发时，把组件拼装在一起形成一个产品、或者服务；
• 微服务，一般理解上就是一个独立运行的服务，它使用到了组件，或者其它的；

当然，这里并不是纠结这两个东西，只是从时间上来说，是先后两个不同时期的概念。对于组件化，对于人们来说，就是想：

• 一个客户端的产品，能不能根据客户的定制需要，快速组装出一个产品。

当然，这样的做法在组件化极端的情况下，可以有条件的实现的。有笔者曾经呆过一家公司，专业做网关产品，它可以实现用户拿到安装包后，根据授权码（Licence)的要求，安装的时候，定制不同的组件，从而实现一定程度上的定制。这种可插拔的组件，基本上就是需要定义一下组件注册中心，进行组件的识别，以及通过SPI的定义，实现组件间数据的协同。当然，后面也有OSGi这类的可插拔式组件开发框架，做起来更简单些。

对于PAAS平台化后，开始引用的微服务的概念，这种快速拼装的做法，仍然还是存在的。笔者现在所在的公司，有参与设计基于教育类的产品的拼装平台。当然，它的技术也更复杂：

• 首先，每个产品需要有一个产品标识，称之为app id；
• 其次，每个产品需要有一个独立的租户，用于做数据隔离；
• 再者，要需要WEB端的产品拼装，需要从业务控件开始，并成业务的业务、然后集成为Web站点；
• 最后，移动应用的打包，更是涉及业务组件、移动应用的构建、以及相关的拼装的构架的集成系统；

当然，这样做的好处在于可以分分钟钟可以创建出你所需要的产品。对于一个每周发布1K次的云平台来说，你的产品每周都可以有新的东西进行交付。但这么做，也有些问题，比如：

• 定制能力的有限，想有做更个性化的开发，其实还是避免不了开发的投入的，即所谓的产品脱水代码；
• 组件的能力复杂，从多语言、皮肤方案，到组件的集成API、个性化的定制接口，层出不穷，往往事来更多的维护工作；
• 对于产品指定特性的交付，往往涉及相关多的中间环节，需要项目经理进行有力的协调；

受于篇幅限制，这边就不展开讨论组件化、以及微服务的实现了。但对于研发效能来说，确实是一个有效的提升开发速度的手段，把一个具体的需求转化成一个个5人左右的团队、一周就可以完成的开发特性，而后做大规模集成，至少从效率上是有保障的。
其缺点在于拼装产品的质量，需要建设强有力的自动化测试平台，才能有所保证。另外，这套的方案，对架构师、开发经理的要求是提高一个数量级的。协调每周数以百计的特性的设计、以及进度把控，想想就是头疼的事，何况还需要满足插单的需求。

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

不知各位在做敏捷的实践的时候，有没有想想敏捷宣言。对于研发效能来说，有了好的工具、好的架构，也需要有一段合理的管理方法。敏捷是较好的项目管理实践，特别是Scrum。

对于一个Two Pizza的团队来说，实践Scrum是一个较好的选择。当然也有做结对编程、TDD之类的，但对技术的要求太高不易落地。每次的Sprint实现一个Story、或者Story中的一个部分，并即时的向客户演示反馈。敏捷的精髓在于实践，并在实践中，想想敏捷宣言，不断的做PDCA。

其实再想想，敏捷解决的还只是开发的过程管理问题，那么目标管理呢？对于研发效能来说，更注意的是结果指标。对于目标管理来说，现在都引进了OKR。相对来说，对于一个团队负责人来说，制定团队的年度、季度、乃至月度OKR的时候，都制定各自的OKR目标。对于OKR的制定，经验原则来说，主要是要符合SMART的原则。

• 《研发效能度量核心方法与实践：行业案例和关键原则》
• 《组件化产品思维：让你看懂社交软件的本质》
• 《Microservices》
• 《敏捷宣言》