研发效能提升的系统性思考与实践

我们邀请到业界知名实战派软件质量和研发工程效能专家茹炳晟老师,分享《软件研发效能提升的系统性思考与实践》。本文主要内容:1、当今软件研发行业的本质 2、研发效能的现状与挑 3、软件开发的复杂性困局4、研发效能提升的双流模型5、研发效能提升实践初探;

研发效能提升的系统性思考与实践

本文共计2950字,建议阅读时间:6~7分钟。

阅读本文你将收获:

1、当今软件研发行业的本质到底是什么

2、软件行业研发效能的现状与挑战

3、软件研发效能提升的双流模型

4、研发效能提升实践探索

前言:在DevData Talks 直播活动中,我们邀请到业界知名实战派软件质量和研发工程效能专家茹炳晟老师,分享《软件研发效能提升的系统性思考与实践》。以下是文字版干货回顾,开整!

本文主要内容提纲

  1. 当今软件研发行业的本质
  2. 研发效能的现状与挑战
  3. 软件开发的复杂性困局
  4. 研发效能提升的双流模型
  5. 研发效能提升实践初探

01 当今软件研发行业的本质

从『农业时代』向『工业时代』进化

尽管软件是许多现代科技的基石,但一定程度来说,软件生产过程仍然处于相当原始的状态。我们将软件研发模式归纳为三个发展阶段:

石器时代

一位或少数几位开发者即可完成软件研发工作,个人英雄主义盛行。

农业时代

随着软件规模与复杂度不断提升,开始出现群体协作,但协作仍然是以“手工作坊”的形式进行——开发者接收任务、各自造零件再进行组装,不确定性较高,效率与质量强依赖于个人能力。

工业时代

如今,软件体量动辄几十万行代码,用户规模达数亿,且与民生息息相关。尽管依然依赖个人能力,但相比农业时代更关注以系统性设计保障质效。

  • 接口统一标准化,架构设计保持灵活性
  • 让机器承担重复性高的事务型工作,使人投入更多精力在创造型工作

02 研发效能的现状与挑战

业务发展一段时间后,增长趋势放缓,企业很自然地会期待通过研发效能提升开启第二增长曲线。

然而残酷的事实是,随着业务的发展,软件架构复杂度不断提高,软件与人员规模不断扩大,协作成本变高,加人加班式的粗放增长不再奏效。

概括而言,软件的复杂度提高了。研发效能不仅难以提升,反而会逐步恶化。

所谓『效能提升』实践,并不能扭转这一恶化趋势,而仅能减缓它。前面提到研发模式向工业时代进化,正是减缓效能恶化的重要实践之一。

03 软件研发的复杂性困局

(1)软件研发复杂性的来源

随着业务发展,软件产品所需要解决的问题愈发复杂,带动其本身的复杂度提高。这里复杂性来自两个方面:

  • 本质复杂性:对应的是软件产品的能力提升,是理想情况下的复杂性下限。
  • 随机复杂性:往往带来影响深远的危害,是复杂性中可管控、可优化的的部分。具体包括:
  • 短视效应,急功近利、快糙猛地完成交付,留下隐患
  • 认知负荷,知识未沉淀,学习理解成本高
  • 协同随机性,更多点对点的、准确性难以保障的沟通与协同

(2)以架构腐化为例

架构腐化是随机复杂度带来的负面影响之一。在开发过程中,技术债务被不断引入,到架构腐化被感知的时候,情况往往已经相当严重且不可逆。

针对这一问题,唯一有效的应对方法是防范于未然,预防架构腐化,减缓腐化速度。

技术债务可分为代码级和架构级两类:

代码级技术债务

由于随机复杂度,开发者不断引入代码级技术债务,尤其当团队规模庞大时,代码级技术债务的增长非常快。更糟的是,由于技术债不直接影响产品功能,往往非常隐蔽难以发现。

针对代码级技术债务,可以通过代码分析来持续跟踪,度量指标包括代码重复度、注释覆盖度、圈复杂度等指标,在开发者引入技术债的第一时间识别并解决。在思码逸产品中,这些指标组成了软件工程质量度量的多个维度。

架构级技术债务

架构级技术债务的危害比前者更甚,需要通过持续度量软件系统的可维护性,提前识别反模式。例如:

  • 架构解耦度(decoupling level)度量的是软件系统在多大程度可以被拆分为独立、可替换模块。
  • 不稳定接口(unstable interface)度量的是接口共同修改的关联度,识别影响范围过广的架构热点。

(3)随机复杂性与研发效能的关系

值得注意的是,随机复杂性也并不全然是坏事。个体失误引入随机复杂性,虽然给系统带来未知风险,但同时也带来可以借鉴的经验和教训。经过有效复盘和学习,软件系统将变得更加健壮。

因此,我们将研发效能的本质归纳为:以可接受的成本,将随机复杂性降低至可控范围。

04 研发效能提升的双流模型

那么软件研发行业如何通过优秀的实践和工具来降低随机复杂性呢?这里我们引入双流模型的概念。

(1)什么是研发效能双流模型?

以两个视角去观察研发过程,我们可以拆分出两条流:

  • 需求价值流

需求状态的流转过程,主要关注者是项目经理、产品经理等角色

  • 研发工程流

软件研发流程中的具体操作和阶段性工作产品,主要关注者是开发工程师、测试工程师、运维工程师等角色。

简而言之,双流模型就是将需求价值流与研发工程流关联起来。

(2)研发效能双流模型的价值

  • 提升工程师体验 + 降低随机复杂性

以往,需求价值流和工程价值流没有关联关系。工程师完成任务后,需要离开工作系统,到项目管理工具上做手动流转。

这种繁琐、重复的事务性工作一方面挤占工程师的时间、体验不佳,另一方面给效能数据有效性打了问号。

一个常见的例子是需求燃尽图的折线并非平稳下降,而是迭代最后一天断崖式下跌,因为工程师们都赶在最后一天更新状态。基于这样的工程数据做度量必然不可靠,微观的、以天为单位的研发过程管理不再有效,问题和隐患可能因此被掩盖。

当需求价值流和研发工程流自动双向联动,事情就轻松了许多——举两个例子:

  • 当工程师认领开发任务时,不需要离开 IDE 界面通过插件即可领取任务,平台自动完成需求状态流转、分支创建、代码拉取等工作;
  • 工程师开发完成并完成本地测试后,提交代码合并请求,平台触发 CI 流水线,自动完成静态代码检查、质量门禁检查、质量测试等等,并更新需求状态。

工程师更加专注高效地开展工作 + 工具自动、准确、及时地处理事务性工作,随机复杂性随之降低。

  • 支持研发效能黄金三角

之前张乐老师分享的『研发效能黄金三角』包括研效提升实践、一站式研效平台、效能数据中台三部分,概括而言就是实践 + 工具平台 + 度量。三部分彼此独立又相互关联,构成了彼此支持、不断迭代加强的回路。

基于双流模型的工具平台,不仅优化实践,也保障了度量的有效性。在此基础上进一步归纳、发现优秀的改进实践,形成完整的效能提升闭环。

05 不同阶段研发效能提升实践

以下分享双流模型中不同阶段的几个典型研效实践。

(1)需求阶段

需求阶段的效能提升至关重要,因为它影响到研发团队是否将宝贵资源投入到了正确方向上。

在需求阶段,我们可以使用 Kano Model,从功能实现程度和用户满意度两个维度对需求进行分析,为需求排期提供客观依据。简单列出几个类型:

  • Must-to-have:基本需求,质量如果不达标用户会立刻离开,例如手机的通话功能;这一类型的需求往往需要优先排期
  • Excited-to-have:实现这类功能的时候满意度增长很快,容易引发口碑传播;可从这一类型中选择成本较低或技术壁垒较高的需求
  • Reverse:尽管从模型来看,这一类型需求是最不理想的,但实际上往往是产品的盈利点,例如信息流广告;针对这类需求,需要结合业务阶段判断优先级

(2)个人本地开发和测试阶段

  • 高效获取开发环境

使用云端 IDE,工程师可以在任何一台带有浏览器的设备上进行编码,节约下载代码、编译代码、连接远端调试环境等工作;研发团队可以统一插件版本,保障一致体验,缩短新成员上手周期。

  • IDE 精准代码提示

基于机器学习,IDE 插件能够主动学习代码上下文,给出更加精准、符合逻辑的代码提示,不仅提高效率,也降低工程师失误的随机复杂度。

其中,比较著名的是微软在 2021 年发布的Copilot,这个插件能够根据函数名、注释和代码本身的上下文判断代码意图,自动生成建议,辅助编程。

(3)代码合流阶段

  • 精准测试

单元测试、接口测试等如果用传统的方法做,测试用例规模较大,效率较低。可以通过分析代码变动,精准定位需要进行测试的模块,降低测试环节成本。

(4)集成测试与验证阶段

  • 测试基础架构服务化

在 DevOps 体系下,建立起全面、可复用的测试中台。

如果您想了解更多关于本次演讲的内容,可以联系思码逸团队获取演讲视频和演讲PPT;

思码逸 Merico 研发效能分析平台,致力于帮助研发团队解决研发效率、研发质量和人才发展三大痛点,提升研发效率与软件工程质量;

如果您想要与思码逸团队交流,欢迎在网站留下联系方式,我们将在24小时内回复。

与先进研发团队并肩

“软件工程在工业生产中越来越重要。一方面,软件供应链快速演进,软件研发越来越复杂;另一方面,市场的快速变化对研发能力提出各种新的要求。而思码逸作为客观的研发效能平台,立足于对软件开发给出创新性的解释,并尝试将研发效能指标标准化。这对由管理者视角、业务视角、人员视角等更多维度更加全面地看待开发过程有很大帮助。”

Mars Sun

腾讯CODE平台产品负责人

“看清组织研发过程、合理有效地进行研发效能度量是牵引组织研发效能提升的关键。思码逸实现了深入代码语义的AST分析能力,引入代码当量将常规的基于代码行的相关研发效能度量方式提升到了一个新的高度,并通过代码层面的分析提供了研发人员的技术栈相关的标签数据,为组织研发选型提供有力的数据支撑,在行业内有很强的借鉴意义!”

杨永强

原滴滴出行代码团队技术负责人

“相信很多产品技术团队把研发效能提升列为重要的目标。然而,到底什么是好的研发效能,却很少有人能够表达清楚,而代码度量指标种类繁多且相对浅层。如何有效对程序员的工作合理量化测量,思码逸团队围绕每次代码提交对应的抽象语法树的变化进行有效评估,去除了代码中的一些干扰和噪音,为我们提供了新的思路和相对准确的一种测量基础。”

唐洪山

原京东科技研发效能部

“思码逸研发效能平台的专业性令人兴奋,非常适合中国快速发展的互联网软件企业使用。很好的帮助我们解决了团队和项目快速增加过程中遇到的研发效能度量、研发质量规范和人才组织发展的问题。后期的咨询和落地解决方案针对性强,问题分析和解决专业、高效。”

应阔浩

自如基础架构部总监

“在越来越多的企业把数字化转型作为核心战略落地主要抓手的大背景下,思码逸作为基于源代码并扩展至项目管理领域的研发效能平台分析工具,能够为企业数字化转型提供明显助力。和讯网在和思码逸合作共创的2年时间里,2020年主要集中于降本增效领域(提升下限),当年技术部的年度绩效位列全公司第一;2021年主要集中于价值达成领域(提升上限),当年技术部被公司评为年度优秀团队。”

杨扬

和讯网CTO

“开发人员状态有起伏是很正常的。采用思码逸的研发效能度量工具,我们不仅能及时发现表现优秀的开发者并给予激励,也能快速发现工作有待改善的开发者,给他们提供精准的指导与帮助,推动整个团队共同进步。”

朱文雷

长亭科技CTO

“思码逸在代码度量层面给出了创新性的解释,给技术管理者带来全新的研发效能度量提升思路和指标抓手工具,看清团队研发效能的短板,知道该往什么地方提升和改进。结合历史数据、行业数据的比对,让管理者、开发者可以看到努力的成果,并且用数据说话,研发团队日益精进。”

周彦斌

云货优选 研发部门负责人

“研发成果的度量可以说是一个世界性难题,开发者的工作之间内容不同、起点不同、用户不同、代码质量不同,既难以简单量化,也难以横向比较。思码逸作出了一个非常有意义的尝试,它一方面找到了有效的研发效能度量方法,另一方面打通了企业边界来开展数据比较,为研发数字化变革提供了一个非常有意义的新角度。”

谢超平

索贝数码副总裁/总工程师

在数字化的浪潮里,研发效能的高低是企业的核心竞争力。我们面对的产品研发都是脑力工作者,研发效能的度量也变的更复杂和有挑战性。思码逸的深度分析系统,用代码当量来更科学的评估开发的工作量,有效避免人为对代码量的干扰。通过MARI模型产出分析报告,帮助我们在公司内研发效能的推进和落地提供新的思路和方法。

谢超平

王蕾 贝壳工程效率负责人

长期以来,我们一直努力在复杂的市场环境中保持和不断提升研发效率及质量。思码逸为我们提供了重要的量化工具,较传统量化方式更客观和实用。目前思码逸的量化结果已经成为我们评价和提高研发效能的重要组成部分。

谢超平

妙盈科技联合创始人&CTO 刘涛

我们的客户

打开研发管理黑盒,数据驱动研发效能
立即试用
立即预约
在线客服
扫码添加咨询微信
售前电话
在线客服
免费试用
扫码添加咨询微信
长按二维码下载

取消