如何度量前端项目研发效率与质量（上）-InfoQ



 写点什么

引言

在 DevOps，有个很流行的说法是 XX 项衡量 DevOps 是否成功的指标。通过对研发流程各个阶段的关键数据进行度量，来判断一个项目是否完成 DevOps 转型。

这个思路非常正确，因为要想改进它，就要度量它。

而对于前端项目大部分也可以套用 DevOps 的部分衡量指标，我基于本身的项目实践，结合前端项目研发流程的特殊性和差异点，梳理出更适合判断前端项目是否高效高质的衡量指标。而衡量指标大部分都是可以通过工具实现自动化采集，从而可以很容易建立出适合团队本身的交付看板，用于日常项目管理改进。

本文适合前端项目 leader，和尝试前端工程实践的工程师们。

前端研发流程

我将前端研发流程分为：设计、开发、个人验证、版本验证、线上验证 5 个阶段。下面我分别解释下这几个阶段的含义与区别。

设计：前端研发流程最特别的阶段，由于前端业务特点，前端工程师不可避免的将会与设计师和产品尽力进行协同。无论是产品设计的技术可行性评估还是产品体验的讨论，产品设计的阶段将决定业务的实现方式，这是所有需求的源头。与设计师和产品经理的协同效率越高，前端团队的交付效率也会越高。

开发：前端工程师的核心编码输出阶段，这个阶段的代码质量、开发效率、协同联调效率都将决定后续版本的质量和返工成本。在这个阶段有非常多的自动化工具或 cli，来协助开发者提升效率和编码质量。但这也是最不好控制得阶段，因为他与个人开发环境和个人技术水平与习惯息息相关。

个人验证：前端工程师开发完成后，在正式提交前，都会有个人验证的阶段。也就是自我验证确保无问题后，再提交入库，启动版本验证阶段。虽然每个开发工程师都会自我验证，但因为开发者思维的存在，这往往是最容易忽视的一个环节。我们需要在这个环节加入很多的自动化验证能力，来帮助开发者在个人开发阶段完成质量的提升。因为，在整个研发流程中，越在前面环节发现问题，其修复成本越低。

版本验证：在前端团队中，各个开发人员完成自我验证后，提交至版本分支后，将启动版本验证阶段。在这个阶段，优秀的前端团队会通过自动化的流水线完成编译打包、静态检查、质量门禁、用例测试等一系列自动化的版本验证动作，完成版本的质量与安全的保障。这个阶段应该是整个研发流程中自动化率最高的环节。效率高、自动化程度高、执行速度快的流水线，将极大提升前端项目的质量和效率。

线上验证：前面四个阶段都是站在开发团队的视角，最后一个阶段是站在用户的视角。也就是说，当你完成了版本发布后，你的产品真实表现如何，用户是否按照期望的方式在使用，有无漏测，有无在开发阶段忽略的质量漏洞，能否先于用户发现问题，能否快速定位到问题。这些都需要在线上验证阶段进行监控与拦截，在该阶段，前端监控，还有各种告警、拨测等工具的应用，都是比较好的优秀实践。

那么到此，整个前端研发流程也就完整闭环。

衡量指标

说完了前端研发流程。那么，在这个流程的各个阶段，我们用哪些可度量的指标来判断每个阶段是否做到了最好，是否还有改进空间？度量指标体系的建立，不仅帮助你了解目前项目的基线情况，更大的价值是能够根据客观的度量数据，牵引团队往达标的方向改进，方向清晰，效果明显。

设计

在设计阶段，我们需要考虑的是如何提升前端人员的效率。这个阶段在很多团队如果设计师与产品经理比较专业，通过设计平台的协同，都能达到很高的效率。但是如果设计师与产品在设计阶段的混乱，可能会导致需求不清晰、设计反复、一句话需求，所以在这个阶段，更多的是衡量产品经理与设计师，通过指标反向约束，避免设计成本转移给前端开发人员。通过项目管理的工具，前端开发者很容易给对应需求打上标签和填写对应信息，从而度量相应指标。

前置时间（Lead?time）

前置时间是供应链管理中的一个术语，也被应用于敏捷与 devops 中，在供应链管理中，是指从采购方开始下单到供应商交货所间隔的时间。而对应到敏捷和 devops 中，往往指用户提出需求到发布上线的时间。一般情况下，在交付人力稳定的情况下，交付效率都是恒定的，所以前置时间的缩短还要着重审视设计阶段的效率。也就是说，从用户提出需求，到最终设计稿定稿的时间是否存在优化空间。

需求修改频次

由于前端交付产品与交互体验息息相关，存在设计稿和原型频繁改变的情况。需求修改频次，可以记录前端产品需求被修改的次数，从而反应产品经理与设计师在产品设计的规范程度与协作效率。

需求规范度

提交的需求是否满足约定的规范。比如，复杂特性需要有详细的高保真标注图、杜绝一句话需求、杜绝描述不清楚的需求。在收到不满足规范要求的需求，开发人员有权打回需求，以避免后续的开发成本浪费。而规范度遵循度差的团队，应该审视相应角色的协作是否存在优化点。

开发

开发阶段是工程师核心编码输出阶段，在这个阶段，我们关注的主要是交付效率与质量。

迭代人均交付需求数

在单位迭代内，每个开发人员能完成的人均需求数。由于团队划分需求颗粒度习惯是延续的，可能存在个别迭代不同开发人员需求颗粒度不一致的情况，但放在一个较长的时间段内相关误差基本可控。所以平均迭代交付需求数越高，且呈上升趋势的团队，可以理解为团队交付效率高。

迭代人均问题数

而对应的，单位迭代内产生的现网问题数越多，也代表其交付版本质量较差。而如果该指标长期未成收敛趋势，那么也需要同步审视相应的质量保障体系是否存在优化空间。

个人验证

在个人验证阶段，主要是开发人员对自己编写的代码进行合入版本前的自我验证。主要包含功能测试与代码检视等一系列质量活动。当然，在一些优秀实践里，也会引入大量自动化工具和插件，辅助开发人员提前发现质量问题。

代码检查遵从度

良好的代码规范和基础的静态检查能够避免很多低级问题，在这方面基于 eslint 等一系列工具，可以很容易建立起代码检查的要求。而遵从度的指标，要求开发人员必须满足我们的代码检查要求，比如，严重问题清零，或者问题 100%清零等指标。

自动化用例覆盖率

无论是单元测试用例还是 E2E 的测试用例，在个人验证阶段，开发人员应该编写对应的测试用例，并基于本次代码提交的影响范围，运行相关自动化用例，以确保新功能和历史功能的质量。尤其对于大型的前端业务系统，必须建立自动化用例体系保障长时间积累的大量特性得到质量保障。在此阶段，自动化用例覆盖率越高，越能保障版本的质量。

自动化用例成功率

而用例覆盖率对应的是，自行的成功率。频繁失败的测试用例，要么反应业务功能的不完善，要么反应测试用例的不严谨，从而影响版本质量的验收，应尽力避免。