前置时间是供应链管理中的一个术语，也被应用于敏捷与devops中，在供应链管理中，是指从采购方开始下单到供应商交货所间隔的时间。而对应到敏捷和devops中，往往指用户提出需求到发布上线的时间。一般情况下，在交付人力稳定的情况下，交付效率都是恒定的，所以前置时间的缩短还要着重审视设计阶段的效率。也就是说，从用户提出需求，到最终设计稿定稿的时间是否存在优化空间。
需求修改频次
由于前端交付产品与交互体验息息相关，存在设计稿和原型频繁改变的情况。需求修改频次，可以记录前端产品需求被修改的次数，从而反应产品经理与设计师在产品设计的规范程度与协作效率。
需求规范度
提交的需求是否满足约定的规范。比如，复杂特性需要有详细的高保真标注图、杜绝一句话需求、杜绝描述不清楚的需求。在收到不满足规范要求的需求，开发人员有权打回需求，以避免后续的开发成本浪费。而规范度遵循度差的团队，应该审视相应角色的协作是否存在优化点。
开发开发阶段是工程师核心编码输出阶段，在这个阶段，我们关注的主要是交付效率与质量。
迭代人均交付需求数
在单位迭代内，每个开发人员能完成的人均需求数。由于团队划分需求颗粒度习惯是延续的，可能存在个别迭代不同开发人员需求颗粒度不一致的情况，但放在一个较长的时间段内相关误差基本可控。所以平均迭代交付需求数越高，且呈上升趋势的团队，可以理解为团队交付效率高。
迭代人均问题数
而对应的，单位迭代内产生的现网问题数越多，也代表其交付版本质量较差。而如果该指标长期未成收敛趋势，那么也需要同步审视相应的质量保障体系是否存在优化空间。
个人验证在个人验证阶段，主要是开发人员对自己编写的代码进行合入版本前的自我验证。主要包含功能测试与代码检视等一系列质量活动。当然，在一些优秀实践里，也会引入大量自动化工具和插件，辅助开发人员提前发现质量问题。
代码检查遵从度
良好的代码规范和基础的静态检查能够避免很多低级问题，在这方面基于eslint等一系列工具，可以很容易建立起代码检查的要求。而遵从度的指标，要求开发人员必须满足我们的代码检查要求，比如，严重问题清零，或者问题100%清零等指标。
自动化用例覆盖率
无论是单元测试用例还是E2E的测试用例，在个人验证阶段，开发人员应该编写对应的测试用例，并基于本次代码提交的影响范围，运行相关自动化用例，以确保新功能和历史功能的质量。尤其对于大型的前端业务系统，必须建立自动化用例体系保障长时间积累的大量特性得到质量保障。在此阶段，自动化用例覆盖率越高，越能保障版本的质量。
自动化用例成功率
而用例覆盖率对应的是，自行的成功率。频繁失败的测试用例，要么反应业务功能的不完善，要么反应测试用例的不严谨，从而影响版本质量的验收，应尽力避免。
总结到个人验证结束，我们将进入版本验证的阶段。
版本验证阶段将是客观衡量指标最多，自动化程度最高，也是度量体系最核心的部分。整体衡量指标大部分都将在该阶段通过自动化的实践呈现，用于评估前端版本的质量与效率。而驱动项目改进，大部分可以基于版本验证阶段收集的度量指标，驱动整体项目改进。
相应内容，我将在第二篇详细展开。
未完待续，敬请期待。