从 0 开始构建研发高效能全栈式团队

阅读本文你将收获:1、为什么以全栈为方向提升研发效能?2、为啥要建立轻量级团队框架3、技术栈的决策要点有哪些?4、研发团队的关键效能指标5、一些延伸思考

从 0 开始构建研发高效能全栈式团队

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

阅读本文你将收获:

1、为什么以全栈为方向提升研发效能?

2、为啥要建立轻量级团队框架

3、技术栈的决策要点

4、研发团队的关键效能指标

5、一些延伸思考

前言:我们邀请到了 Dell EMC VxRail 的高级主管软件工程师、DevOps 架构师管俊老师,与我们分享研发高效能全栈式团队的建设策略。以下是文字版干货回顾;

01、为什么以全栈为方向提升研发效能?

(1)成本问题

以下是成本等主要指标随版本变化的一系列图片,横轴为产品版本。

第一张图是团队规模随版本迭代的变化。随着公司业务扩张,产品为了保持市场领先地位,需要更多的人手投入去做产品及产品线,团队规模会越来越大,且呈现非线性增长。

第二张图是成本随版本的变化。成本是一个较宽泛的讲法,包括经济成本、时间成本、沟通成本等等,同样且呈现非线性增长。

第三张图是产品代码规模随版本变化。我们可以看到随着版本迭代,代码规模的增速逐渐下降。很可能会出现投入了 3-5 倍的人力,而代码产出只能增加 1.5 倍的情况。

产出效率同样呈大幅度、非线性的下降趋势。

从以上图片我们能看到,如果沟通不够清晰顺畅,会导致大量返工和内耗,损害交付效率,浪费资源。且随着版本迭代,这些负面影响会加速放大。

我们都希望交付更快,‍成本更低,完成更多任务。要实现这一点,唯一的方法是做得更好、更正确。

(2)从 DevOps 原始问题展开去

这张图片展示的是 DevOps 典型生命周期,涵盖了编码、构建、测试、发布、部署、运维、获取反馈等多个环节的闭环过程。但这个软件研发生命周期并非 DevOps 独有,而是长期以来大多数软件系统产品的旅程。

用 DevOps 理念看软件生命周期,更强调各环节之间的连接。DevOps 要解决的原始问题是开发(追求改变)与运维(追求稳定)之间的天堑,而解决方法是每个环节都用更好的方式去做,让研发流程顺畅地流动起来。

总结下,个人对 DevOps 的简洁定义:在每个环节,尽可能拥抱更好的实践

(3)往全栈式团队前进

这些年我们常听到到亚马逊 CEO 贝佐斯提出的“两个披萨原则,即控制项目团队在两个披萨能喂饱的规模以下,是有利于高效达成共识,形成决策。

同时,产品交付会涉及到多个职能,包括开发、测试、运维、专职DevOps、项目经理、产品负责人等等。

这几年受微服务思潮影响,我们在组织结构设计中,会遵从康威定律,组建职能齐全的小型团队,让小型团队负责微服务端到端的交付。这样设计的好处,一是小团队会对其负责的微服务有充分的责任,避免踢皮球;二是能够减少跨团队沟通带来的成本。

这样的小型团队有两种构建思路,一是在小团队中嵌入尽可能多的角色;二是将团队的开发者培养为全栈工程师。

这里我们定义的『全栈』,并不是可前端可后端、熟悉多种语言,而是指了解测试、运维多个环节,甚至可以跳出来承担 Scrum master、面向业务方甚至甲方的角色。

尽管由于业务和技术上的复杂度,第二个构建思路未必能完全实现,但是是值得思考的方向。对于团队发展而言,成员成为全栈工程师,具备更多能力,团队就有更大空间去推行各种研发活动的左移,成为更自治、更具有发展潜力的团队。

前面讲了在团队能力上做加法,接下来讲讲在流程、技术栈和度量上做减法,保障“轻量级”。

02 为什么要建立轻量级团队框架

(1)敏捷开发流程:从最轻量开始

随着团队规模扩张,可以采用先从无到有,再逐步迭代改进的方式去搭建敏捷流程。就我的经验,scrum 模式会比看板这样的长迭代模式更加适合研发团队,因为前者会对交付中间产物做定期的检查,能够尽早暴露风险,也能保障团队的积极性。

以下就是一个典型的迭代周期示意,包含迭代规划、日常冲刺、相关方 review 和终期回顾等阶段。

以下是我们团队当前采用的、最轻量的敏捷模式,以两周为一个迭代周期。以下几个关键点供大家参考:

  • Day 1 进行本期迭代的计划、上期迭代的回顾
  • Day 6(图中标注错误,红色高亮 Day 7 应为 Day6 )进行backlog 梳理。backlog 梳理能够大幅减少 Day 1 的工作量
  • 减少大块的会议时间,将工作的细致拆分和 review 分散到日常中,按需进行;尤其是在远程协作的情况下,减少会议时长、明确会议主题能够明显减轻成员的心智负担

在开发活动中,同样建议开发者采用最轻量级的框架,对业务场景进行分析,给出业务描述、验收标准、技术分解等,保障信息充足且同时不占用过多时间。

(2)常被遗忘的 Ops

下面这张图片更细致地呈现产品交付所包含的完整链条。

产品设计、开发、容量规划、测试与发布,监控设计、都属于计划性为主的敏捷开发部分;而运维支持,包括容量规划、问题根因分析、事故响应、监控等,则以突发性为主。

我们能看到两者在很多环节都是相互重叠的,高效的运维依赖于前期开发环节的有效设计。因此,尽管运维支持常被遗忘,它依然应当是全栈型团队乃至全栈工程师工作职责的一部分。

(3)Ops 向 SRE 延伸

同时我们还看到一个趋势:运维正在向 SRE 延伸。相比传统运维,SRE 会更向前跨一步,不仅关心服务是否运行,还关心服务运行得如何,例如与关联服务的调用关系带来了哪些影响等等。这就要求 SRE 对于业务和开发有更加深入的理解。

运维体系本身非常庞大,我们的实践是先引入可用的 SRE 框架,做适当裁切,并结合开发的投入为SRE建立自动化体系。其中,左侧是规则和流程,右侧是各类工具和实现。

03 技术栈的决策要点

框架到位后,需要进行一些技术栈决策。这里有几个我们的决策参考原则,供大家参考:

  • 少即是多:降低工具本身的学习门槛,贴合团队本身的使用需求,不新增非必要工具
  • 经过验证:降低维护成本
  • 一切皆代码:减少非必要组件,运维友好,配置驱动
  • 要家畜不要宠物:健壮性较强,出现问题可以较低成本解决

04 团队的持续改进

要做到持续改进,团队首先需要结合业务现状,选取关键少数的效能指标;其次需要持续度量、合理使用这些指标。

(1)选取关键研发效能指标

我们使用的指标分为迭代、代码、交付级。

迭代级:反映敏捷过程

  • 燃尽图:评估交付需求稳定性和故事分解合理性
  • 速率图:建立团队的交付能力基线,使迭代计划与项目估算有据可依

代码级:反映是否小步快跑

反映代码相关环节是不是足够快,编码实践是否优秀。

在这个层级上,思码逸提供了优于传统代码行数指标的度量,能够排除空行、死代码等噪音,能够更好地指导代码级的效能现状。

交付级:反映响应速度

包括故事平均开发时长、流水线平均运行时长、bug平均修复时长、bug 平均验证时长。

(2)指标的持续度量与合理使用

首先,效能度量的使用中,最重要的是避免内卷。指标并非越高越好,人的能力都是有边界的,以内耗为代价的高指标不可持续。其实,对于敏捷团队而言,高效率且稳定的产出才是最优的。

基于这些判断,我们的实践是持续度量几个迭代,形成研发效能的基线与可信区间;在迭代回顾中对异常点进行下钻分析,并基于分析结果落实改进。同时,我们会每半年更新基线与可信区间,实现稳定、可预测的交付。

值得注意的是,度量指标也并不是一成不变的。随着研发团队关注重心的转移,需要定期更新或淘汰指标。

合理使用度量,我们需要先建立这样的理念 :一切度量都是以团队为视角,不是为了谴责任何人,而是为了成长。一旦发现问题,问题是归属于整个团队的,改进责任也是整个团队的。

作为全栈型组织,我们需要通过度量推动成员和团队一同成长,而不是相互推诿。

05 一些延伸思考

以下分享一些延伸思考。

(1)自治团队 VS. 组织治理

全栈型团队已经具备一定的自治能力,那么如何平衡团队自治与组织治理之间的关系,二者的边界在哪里?

我们的实践是,团队基于自身需求,尽量采纳组织统一提供的工具、服务、规范,降低运维和资产成本,也降低心智负担;在效能指标、规范上保持与组织的向心力,在内部自治部分保持灵活性和自由度。

(2)应对疫情冲击

在疫情冲击下,我们采用了这些实践来保障效能:

  • 常态化远程协作:会议、代码的review、纯电子化看板等。长期来看,尽早适应纯电子化的工具能够帮助团队应对不确定性的冲击
  • 分布式团队:团队分布更广,能够对冲疫情等风险,也会扩大可用人才的范围
  • 避免过多、过长的会议:避免过多过长的会议,减少心智负担,让员工集中精力
  • 知识与技能的共享:内部知识分享、结对编程,帮助团队成员共同成长,培养全栈能力
  • 保持稳定:从工作方式、工具、流程等角度未雨绸缪,保障交付产出稳定,并通过度量持续验证稳定性

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

------结束------

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

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

与先进研发团队并肩

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

Mars Sun

腾讯CODE平台产品负责人

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

杨永强

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

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

唐洪山

原京东科技研发效能部

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

应阔浩

自如基础架构部总监

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

杨扬

和讯网CTO

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

朱文雷

长亭科技CTO

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

周彦斌

云货优选 研发部门负责人

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

谢超平

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

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

谢超平

王蕾 贝壳工程效率负责人

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

谢超平

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

我们的客户

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

取消