“5步”做好研发效能度量，打造DevOps研发管理闭环

当前位置：首页 > 百科 >

来源：博客园时间：2023-04-03 12:34:31

效能度量，对于实施DevOps研发团队来说并不是一个陌生的话题。非常多的研发团队都想要通过效能度量提升研发团队的效率。关于软件研发效能度量，也有一些标准的框架，分为交付价值、交付效率、交付质量、交付成本、交付能力五个维度

研发效能度量的目标

研发效能度量的目标是为了帮助研发团队了解自身的工作效率和质量，及时发现问题并采取相应措施进行改进，以实现高效、高质量的产品交付，满足业务需求，实现业务价值。

识别瓶颈：通过度量研发过程中的关键指标，可以及时识别生产效率的瓶颈和短板，从而有针对性地对研发流程进行优化。

【资料图】

监控进度：研发效能度量可以帮助团队实时监控项目进度，发现问题和风险，并及时采取措施加以解决。

提高效率：通过度量工作量和工作效率，团队可以识别工作流程中的低效环节，并采取相应的措施进行优化，提高工作效率。

提高质量：通过度量产品质量和测试覆盖率等指标，可以发现产品质量问题，及时进行修复和改进，从而提高产品质量。

研发效能度量的思路和路径

那么如何进行研发团队的效能度量呢？那就围绕指标分为五大步骤展开。

确定指标：团队和企业管理者要根据项目需求和团队情况选择合适的指标进行度量。
设定目标：团队和企业管理者要共同设定目标，例如每个迭代的交付频率、产品质量指标等。
收集数据：团队和企业管理者要共同收集数据，例如每个迭代的缺陷数量、交付时间等。
分析数据：团队和企业管理者要对收集到的数据进行分析，找到问题和改进方向。
反馈和改进：团队和企业管理者要将分析结果反馈给团队成员，共同讨论改进方向并进行优化。

1、确定指标

行业内有结构化的指标体系，从需求、设计、开发、测试、发布、运维等不同的阶段，对应着不同的指标。但是需要提醒一点，搭建指标体系不是越全越好，而是要根据团队所处的不同阶段，遇到的不同问题，最主要的是想要通过指标解决哪些问题，然后进行指标的设计与体系的搭建。

效能度量可以采用多种指标，可以分为质量、效率、成本、客户满意度等方面。以下是众安常用的效能度量指标：

这些指标不是固定的，团队和企业管理者可以根据项目需求和团队情况选择合适的指标进行度量，同时也可以结合其他指标和方法进行分析和改进。

2、设定目标

设定目标一定要遵循SMART原则：

Specific（具体的）：目标应该是具体且明确的，能够清晰传达出想要达到的结果，避免模糊和含糊不清的描述。

Measurable（可衡量的）：目标应该是可衡量的，可以使用数据和指标进行可视化，跟踪进展情况，避免主观性和无法量化的目标设定。

Achievable（可达成的）：目标应该是可达成的，要考虑到实际情况和可用资源，确保目标是可实现的，并且具有挑战性和激励性。

Relevant（相关的）：目标应该是相关的，与业务需求和战略一致，能够对实现业务目标产生正面影响，避免无意义的目标设定。

Time-bound（有时间限制的）：目标应该是有时间限制的，要设定明确的截止日期和时间表，以确保目标得到及时实现和跟踪。

但是，设定目标之前，要对研发团队进行现状分析，比如：当前团队的需求平均交付周期是20天（需求从创建到上线），部门例会上研发负责人会经常被业务负责人挑战，20天太久，为什么提一个需求，需要做那么久。迫于压力，研发负责人做出承诺，要在几月份之前，将需求的平均交付周期从20天缩短到10天。这个承诺，就是为团队设定了一个明确的、有时间限制、具体可衡量的目标。

3、收集数据

收集数据有很多方法，可以通过一些工具获取指标需要的数据，也可以通过脚本直连数据库获取相应的数据。众安团队搭建效能度量驾驶舱时，通过集智BI工具拉取数据源的数据，然后经过加工处理后进行可视化配置。

4、分析数据

软件研发效能的提升是复杂的，受到诸多因素的影响，因素与结果之间存在相关关系而不是因果关系。即使我们发现两组数据之间有关联，也不意味着其中一组必然会导致另一组。例如，如果某个团队 “代码技术债率”指标很高，一般情况下代表着代码中存在的很多问题被暂时搁置，未来持续维护的成本和技术风险很大，那么从较长时间周期来看，很有可能 “交付周期”的指标会持续增长，即两组指标之间存在相关性。但这并不是必然的因果关系，虽然技术债很多，但很有可能因为人员能力、突击加班等其他因素暂时掩盖了问题，表面上冲抵了这种趋势。

但从研发效能分析的角度来看，我们仍然可以从历史数据中分析相关性，然后通过实验的方式进行探索，找到能够切实驱动效能提升的因素进行持续干预。比如，想提升线上质量、降低缺陷密度，经验告诉我们应该去加强单元测试的覆盖、完善 Code Review 机制、做好自动化测试案例的补充。但是，这真的有效么？我们通过数据来看，很可能没有任何效果！并不是说这些实践不该做，而是可能做的不到位。也许只是为了指标好看，编写缺少断言的单元测试、找熟人走过场分分钟通过的代码评审，覆盖一些非热点代码来硬凑测试覆盖率目标等等。所以，我们需要实验思维，要不断检视、反思、检讨所采用的实践，哪些实践的确有效，哪些实践效果不大，哪些实践方向正确，但因执行不到位所以效果才不及预期。我们要通过实验找到那些真正有用的改进活动及其与结果之间的相关性关系，有的放矢采取行动才会更有效率和有效果。