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