关于工程效能
不同于其他工业领域(例如制造、建筑),软件工程的研发效能没有一个非常明确的度量属性和度量方式,也很难有一个所有研发团队都认可的度量体系。不同的团队都会结合自身业务特点、组织文化、工程水平来制定自己的指标体系。虽然在具体指标上有些许区别,但大部分都包含在这三个方面:交付质量、交付速度、人员效率。
常见的指标包括:
交付速度
- 迭代速率
- 代码合入频率
- 构建频率
- 部署频率
……
交付质量
- 冒烟测试通过率
- 代码单元测试覆盖率
- 构建成功率
- 部署成功率
- 缺陷平均修复时间
……
人员效率
- 技术日常分享频率
- 自主完成工作占比
- 辅导他人频率
……
这些指标还可以按照作用分为健康性指标、诊断型指标;也可以按照度量的对象分为对人的度量指标、对事的度量指标。指标的解读角度非常丰富,但度量的目的只有一个——改进。我们不推荐将指标与团队或者个人绩效挂钩,因为不同团队的习惯、特点以及成熟度是不同的。
正确度量
在进行度量时,每个指标需要有清晰的定义,完整的数据来源,准确的统计方式,否则很难给研发效能改进带来指导意义。完美的工具替代不了统一的认知,在使用工具之前,需要团队对度量目标达成共识。另外,在数量上指标一定是越多越好吗?盲目追求看似完美的指标体系也会给团队带来额外的管理成本,所以抓住自身团队在研发流程中的核心指标,才能够帮助团队聚焦研发重点环节。
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 代码安全扫描、制品扫描提前识别安全问题。