质效度量如何在代码库里挖宝-1团队在高效工作吗

低质效的工作模式包括但不限于：

• 开始了过多的工作项但没有及时结束；
• 码农的工作项在日内被频繁切换；
• 工作开始后又被搁置然后又重新开始；
• 测试反馈弧太长等等。

这些事项在代码库中静静地躺着，直到你去发现。

本文介绍以下三个基于代码库分析的套路。如果关注点赞多的话，会继续出后续的系列。

1）WIP（在制品）:通过精确的时域分析方法来减少浪费、提升软件开发流程的效率和质量。本文讨论了软件项目管理中的时域分析，提出了利用代码库分析来更准确地计算WIP以优化团队效率和响应能力，

2)引入流畅度分析，通过特性分支的代码提交频率来衡量开发进展的连续性。

3)测试反馈速度分析，文章还探讨了测量测试反馈速度的重要性，指出快速反馈对于提高交付质量和缩短缺陷修复周期至关重要。

好了，开始吧

WIP(Work in Process)工作负载分析

精益倡导单件流的工作方式以提高团队应对变化的能力，因此特别关注WIP指标。WIP是指团队或者开发人员已经开始但尚未结束的工作项的数量，反应的是工作负载。而WIP越高，会导致LeadTime等指标的劣化，以及研发人员的工作压力和疲劳度增加，进而影响交付质量。

传统上我们通过需求管理系统来统计和分析WIP，如下图所示。

在项目管理系统中，通常认为某个需求纳入迭代计划就可以纳入在途工作项，计入WIP了。但我们也知道，并不是所有需求在迭代开始就被启动了，存在先后顺序。而通过代码来分析时，则可以在该需求对应的特性分支拉取并首次提交代码后才计入WIP，而将版本发布或者上线作为该项工作的截止。这样，对于WIP的计算更为精准了。

通过分析代码库的集成分支、特性分支上的代码提交，进而统计出团队和个人的在途工作事项。

流畅度分析：（连续commit占比）

精益价值流关注价值的“流动”过程，希望产品或服务在整个价值流中顺畅地移动，避免停顿、等待和浪费。在某个需求的技术实现过程中，如果开发过程是持续和连贯地，则可以认为价值实现了高效地流动。

在WIP分析的基础上，如果关注某个特性分支上的代码提交记录，就可以关注到开发人员开发某个特性的流畅度。如果某个特性分支上某天有至少一次代码提交，则认为该需求在当日有进展，如果没有任何代码提交记录，则记录为当日无进展。在该需求的开发阶段，有如下的公式：

提交日期数量/（有提交日期+无提交日期）=流畅度

也就是说如果某个需求的开发是持续的，则流畅度为100%。

在这个表示中：

·需求A：在10天的开发周期中，有3天（第1天、第8天和第10天）有代码提交。这表示流畅度为30%，意味着在开发周期中大约有30%的天数有进展记录。

·需求B：在10天的开发周期中，有7天（第1天、第2天、第4天、第6天、第7天、第9天和第10天）有代码提交。这表示流畅度为70%，意味着在开发周期中大约有70%的天数有进展记录。

如果WIP高而流畅度低，则说明团队或者某个开发人员开启了过多的工作事项，导致了团队成员在不同工作项之间的频繁切换。这就是精益思想中所希望消除的工作切换所带来的浪费。

测试反馈速度

需求开发完成后进行提测，如果存在缺陷的话，那么在多长多久能反馈并实现开发人员的修复，以实现需求的一次质量反馈过程，这体现了测试响应的能力。随着交付节奏的加快，对于测试反馈的速度的要求也随之提高。过往往往只能通过测试用例执行进度等对反馈速度进行度量。

从代码提交的视角来看，主要体现为对应分支上在经历过开发阶段的密集提交后，存在一段没有提交的静默期，然后又开始有若干次提交。而这些提交就可以被认为是开发人员修复某个缺陷的代码。反馈时长就是这段静默期的时长。