登录/注册
CODING 仪表盘最佳实践

关于工程效能

不同于其他工业领域(例如制造、建筑),软件工程的研发效能没有一个非常明确的度量属性和度量方式,也很难有一个所有研发团队都认可的度量体系。不同的团队都会结合自身业务特点、组织文化、工程水平来制定自己的指标体系。虽然在具体指标上有些许区别,但大部分都包含在这三个方面:交付质量、交付速度、人员效率。

常见的指标包括:

交付速度

  • 迭代速率
  • 代码合入频率
  • 构建频率
  • 部署频率
    ……

交付质量

  • 冒烟测试通过率
  • 代码单元测试覆盖率
  • 构建成功率
  • 部署成功率
  • 缺陷平均修复时间
    ……

人员效率

  • 技术日常分享频率
  • 自主完成工作占比
  • 辅导他人频率
    ……

这些指标还可以按照作用分为健康性指标、诊断型指标;也可以按照度量的对象分为对人的度量指标、对事的度量指标。指标的解读角度非常丰富,但度量的目的只有一个——改进。我们不推荐将指标与团队或者个人绩效挂钩,因为不同团队的习惯、特点以及成熟度是不同的。

正确度量

在进行度量时,每个指标需要有清晰的定义,完整的数据来源,准确的统计方式,否则很难给研发效能改进带来指导意义。完美的工具替代不了统一的认知,在使用工具之前,需要团队对度量目标达成共识。另外,在数量上指标一定是越多越好吗?盲目追求看似完美的指标体系也会给团队带来额外的管理成本,所以抓住自身团队在研发流程中的核心指标,才能够帮助团队聚焦研发重点环节。

CODING 仪表盘针对研发流程的重点环节,为基于 CODING 实践敏捷研发以及 DevOps 工程实践的团队提供了丰富的统计维度。通过自动化的仪表盘,更低成本辅助研发团队进行工程效能的度量分析与改进。在具体实践中,你可以结合多个指标以及多个维度的数据来进行分析。

CODING 仪表盘目前内置了 15 种卡片,根据类型可分为以下三大类别:

  • 项目协同:包含「项目列表」、「近期事项数」、「进行中的迭代」、「迭代概览」、「长期滞留事项列表」和「近期事项趋势」
  • 代码仓库:包含「近期合并的 MR 数量」、「近期 MR 列表」、「近期代码提交统计」、「代码提交排名」和「合并请求排名」
  • CI/CD:包含「近期构建次数」、「近期构建趋势」、「近期发布次数」和「近期发布趋势」

对于“稳”中求进的研发团队

如果你身处金融、工业等对安全生产有着极高的要求研发团队中,确保软件研发质量是团队工作的重中之重,那么建议你的团队重点关注仪表盘中的 CI/CD 版块。该版块的四种仪表盘可以帮助你监测构建及发布次数,或者构建与发布趋势,掌握特定或全部项目/应用最近 3 个月至 1 周内的发展态势,并根据「构建/发布成功率」,指导团队加强研发质量管控:

  • 构建成功率

在持续集成中除了基本的构建打包之外,还会执行代码扫描(代码规范和代码安全)、单元测试、自动化用例测试等等质量环节。当构建频繁失败,构建成功率总是低于预期时,意味着提交的代码在质量上难以满足要求。

  • 部署成功率

即使代码开发、构建得很快,如果不能成功地部署到测试环境、生产环境中,那么价值就没法交付到用户手中。特别是大规模或者是复杂应用的部署场景,如果部署成功率较低,建议团队排查并及时解决这些常见阻塞点,如应用编排、环境配置、服务伸缩、安全防护等。

对于唯“快”不破的研发团队

对于广泛实践了敏捷研发的互联网、游戏等行业的研发团队,往往对于交付速度有着极为快速的要求。那么你的团队可以重点关注代码合入频率、迭代速率、构建频率、部署频率等方面,这些统计数据将会反应出如下趋势:

  • 迭代燃尽、迭代事项完成

我们通过团队在一个迭代中完成的用户故事点数量来衡量交付速度,这意味着每个团队需要定义好 DoD(Definition of Done),团队成员对“完成的标准”需要有统一的认知。比如有的团队以代码通过自动化用例作为标准,有的则以成功合入代码作为标准,这可以根据每个团队的能力和项目特点来定义。理想的故事点燃尽曲线是一条向下的曲线,这代表团队的交付速度是匀速的。

  • 近期合并的 MR 数与构建频率

近期合并的 MR 数与构建频率体现了开发的节奏,频繁的合入并构建代码,可以尽早解Bug。如果总是到迭代的最后几天合入大量代码,团队就要疲于解决大量的代码冲突与缺陷。

  • 部署频率

持续部署把制品频繁地部署到测试环境、类生产环境、生产环境中,可以让集成测试尽快开始,也可以频繁地给用户交付价值,得到测试以及用户的反馈。

场景应用

在实际研发过程中,很多团队往往希望又快又稳地发布软件,可能会根据业务节奏来调整每个时期度量的重点方向,如果想要分析研发流程可能存在的瓶颈,应该综合多个指标,根据实际情况作出分析,例如:

1、当代码提交曲线和迭代燃尽的曲线均存在陡峰,可能是因为需求拆分不够细,导致团队都在迭代最后几天提交代码。健康的工作状态应该是通过均匀且高频次的集成,维持稳定紧凑的开发节奏和较高的代码质量。

2、如果出现构建次数增加、构建成功率低、迭代燃尽速度变缓、完成的事项数减少等情况,此时可能是因为代码质量在下降,团队可以进一步抽样查看构建失败的具体原因,及时作出提升代码规范、加强代码检查力度等对策来进行预防与控制。

3、当代码提交显著减少,迭代完成事项速率也在减缓、长期滞留事项越来越多,此时说明团队可能杂事缠身,没办法专注于交付质量,又或者团队遇到了资源上的等待,导致事项滞留。此时需要团队内部及时沟通,支援并推动滞后项目,确保团队目标顺利开展,符合预期。

及时改进

度量的目标是为了形成反馈,从人、工具、流程、文化几个方面进行改进,从而改进整个研发流程。你可以查阅以下内容,让 CODING 帮助你在工具与流程方面得到改进——

如何提高团队交付速率:

1、通过 CODING 的敏捷看板来观察阻塞的用户故事,查看是什么原因造成的等待。

2、利用 CODING OKR 进行团队目标的聚焦,减少因为任务切换导致的精力涣散。

3、有效利用 CODING 一站式的特点,将研发流程的上下文信息有效传递。

如何提升团队交付质量:

1、在自动化测试代码扫描的质量门禁基础上进行代码重构,减少坏味道代码。

2、严格建立质量基线,尽早发现缺陷,尽早解决。

3、将安全问题左移,有效利用 CODING 代码安全扫描、制品扫描提前识别安全问题。

注册即用,体验酣畅的开发流程

立即使用