‍

阅读本文你将收获：

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

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

3、技术栈的决策要点

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

5、一些延伸思考

‍

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

‍

为什么以全栈为方向提升研发效能？

‍

成本问题

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

‍

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

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

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

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

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

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

‍

从 DevOps 原始问题展开去

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

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

‍

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

往全栈式团队前进

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

‍

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

‍

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

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

‍

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

‍

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

‍

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

‍

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

‍

敏捷开发流程：从最轻量开始

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

‍

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

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

‍

• Day 1 进行本期迭代的计划、上期迭代的回顾

• Day 6（图中标注错误，红色高亮 Day 7 应为 Day6 ）进行backlog 梳理。backlog 梳理能够大幅减少 Day 1 的工作量

• 减少大块的会议时间，将工作的细致拆分和 review 分散到日常中，按需进行；尤其是在远程协作的情况下，减少会议时长、明确会议主题能够明显减轻成员的心智负担

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

常被遗忘的 Ops

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

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

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

‍

Ops 向 SRE 延伸

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

‍

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

‍

技术栈的决策要点

‍

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

• 少即是多：降低工具本身的学习门槛，贴合团队本身的使用需求，不新增非必要工具

• 经过验证：降低维护成本

• 一切皆代码：减少非必要组件，运维友好，配置驱动

• 要家畜不要宠物：健壮性较强，出现问题可以较低成本解决

‍

团队的持续改进

‍

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

‍

选取关键研发效能指标

‍

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

‍

迭代级：反映敏捷过程

• 燃尽图：评估交付需求稳定性和故事分解合理性

• 速率图：建立团队的交付能力基线，使迭代计划与项目估算有据可依

‍

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

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

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

交付级：反映响应速度

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

‍

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

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

‍

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

‍

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

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

‍

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

‍

一些延伸思考

‍

以下分享一些延伸思考。

（1）自治团队 VS. 组织治理

‍

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

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

‍

（2）应对疫情冲击

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

• 常态化远程协作：会议、代码的review、纯电子化看板等。长期来看，尽早适应纯电子化的工具能够帮助团队应对不确定性的冲击

• 分布式团队：团队分布更广，能够对冲疫情等风险，也会扩大可用人才的范围

• 避免过多、过长的会议：避免过多过长的会议，减少心智负担，让员工集中精力

• 知识与技能的共享：内部知识分享、结对编程，帮助团队成员共同成长，培养全栈能力

• 保持稳定：从工作方式、工具、流程等角度未雨绸缪，保障交付产出稳定，并通过度量持续验证稳定性

‍