如何度量前端项目研发效率与质量(上)

阅读数:1 2020 年 3 月 25 日 20:28

如何度量前端项目研发效率与质量(上)

引言

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

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

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

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

前端研发流程

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

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

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

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

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

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

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

衡量指标

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

设计

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

前置时间(Lead?time)

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

需求修改频次

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

需求规范度

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

开发

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

迭代人均交付需求数

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

迭代人均问题数

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

个人验证

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

代码检查遵从度

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

自动化用例覆盖率

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

自动化用例成功率

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

总结

到个人验证结束,我们将进入版本验证的阶段。

版本验证阶段将是客观衡量指标最多,自动化程度最高,也是度量体系最核心的部分。整体衡量指标大部分都将在该阶段通过自动化的实践呈现,用于评估前端版本的质量与效率。而驱动项目改进,大部分可以基于版本验证阶段收集的度量指标,驱动整体项目改进。

相应内容,我将在第二篇详细展开。

未完待续,敬请期待。

评论

发布