工期太紧,能按期提测不错了,Bug多一点正常。质量好不好?不好说。如何提升?不知道,QA会保证呀。
我的粉丝里大部分程序员对自己代码质量要求还是很高的。可当遇到赶工压力,尤其Deadline前,就很可能把完成度很低的代码交出去,心想“反正有人CR,到时再说”。但此时,这些代码好比“行走的Bug制造机”,后患无穷。
我曾在一个技术债严重部门,面向各级程序员做过一轮抽样访谈调研。结果程序员只有27.2%时间在做真正产生价值的编码工作。但他们花20.7%的时间,进行需求质量和代码质量问题所引发的Bug修复、返工和紧急上线工作。
质量成本分两类:
近年,越来越多公司严格控制测试人员比例,鼓励开发通过各类技术手段从上游保障质量,因为越发认识到:事后检查处理代价最高。
质量是规划、设计、建造出的,而非检查出的。 预防高于检查,预防错误的成本通常比在检查中发现并纠正错误的成本低得多。
我们都懂一次性把事做对的成本最低。而一次把事做对意味着,我们要有意识提升预防类工作的占比,从根本降低内部Bug率、外部Bug率。在这质量改进过程中,开发是绝对关键力量,而非测试。
作为项目管理,如何更好规划质量管理活动?
规划质量,是识别项目及产品的质量要求和标准,并确定用哪些质量保障方法、过程改进措施来达到这些标准的过程。
在业务生命周期的不同阶段,质量标准应动态变化。如业务初创期追求最小化MVP模型快速迭代,质量不是最关键因素。但规模扩张一定程度后,质量要求就很高了。不同项目对质量要求也相差甚远,不能一概而论。 只能结合具体项目和具体阶段的质量诉求,对质量的标准进行合理定义。
定义好质量标准,之后要思考整个项目进程中,需规划好哪些质量保障活动,以很好达标。
特别关注研发过程中的质量保障手段,制定适当编码规范、提交规范和分支规范,同时设计代码准入标准,CR、UT、接口验证和UI验证,确保这些手段与你的项目质量要求匹配:
项目经理的视角始终聚焦项目整体目标。在项目经理看来,质量作为目标的一部分,达到要求最重要,无需追求质量的无止境提升。因为,质量也要代价,是否够用取决于项目目标和要求。
质量分析,是指识别项目运行期间,整体质量上遇到的问题和制约因素,分析根本原因,并制定相应的预防措施和解决方案。
曾给一个底层核心模块的技术团队做项目管理,上层模块经常抱怨它的质量,有时甚至在关键流程都有问题,团队内外都对其质量失去信心。
数据上看,该模块线上Bug量占项目总Bug量17%,给上层其他模块和运维都带来大量麻烦。随越来越多外部应用接入,若这问题得不到解决,内部矛盾可能升级为外部矛盾!
根据用户调研结论,用户对底层核心模块的期望更多是稳定,对新需求,用户普遍表示暂无需要。因此,盲目增加复杂功能不明智,保持产品简单可靠是王道。
坚持2m后,整体质量状况好多了。总体来说,质量分析最重要是追根溯源,找到问题症结。
质量分析要点在追根溯源,质量控制是将一些明确的质量规范和做法,落地在各环节的过程。
从需求到发布的整个过程中的质量活动:
要推动质量改进措施落地,相匹的工具配套不可少。大厂都自主设计开发企业效能平台,来完成持续集成和持续交付,并在需求到发布的整个链条,设置质量卡点。可根据需要,逐步为自己的应用定制持续集成方案,指定代码准入阈值,如静态扫描、单元测试、覆盖率测试、冲突检测、Jar包版本检测的通过条件等。
质量控制及卡点行为,是结合项目的质量要求、团队的质量成熟度,层层加强质量把关和收口。即便同项目的不同应用,也因线上要求不同,而对质量卡点有不同侧重。通过质量卡点的在线工具化,才能做到真正有效质量保障。如某些团队在特定阶段,会按静态代码扫描问题级别分级计算缺陷值(如上图),提交测试申请时,如果系统检测到缺陷值有升高,就无法成功提交。
项目经理在质量管理过程中的工作,可从如下方面入手:
要想一次把事情做对,你首先得明确什么是对,然后要分析差距,找到相应的质量保障方法,并不断迭代。这三个方面是个螺旋式循环上升的过程,你需要不断地根据质量分析的结果,设置合适的质量卡点,直到达到规划中的质量标准。