不做认知界的王语嫣-研发效能度量的谬误(续)

上次讲到了“代码行,一个被用坏的高端指标”,也许标题应该改为 “代码行,其实也可以很高大上”。本文将接着介绍一些你已听过的无数遍,且应该“放弃的指标”。 从一个案例,重新思考指标的应用。

接下来,和大家解密一个10年前,悍马机器人项目的度量指标,看看HW的项目是如何进行度量的。

在正式介绍之前,先说一说如何看待当前知识大爆炸的年代。你曾经或现在,通过搜索引擎、线上线下、收费的、免费的获取大量的知识。如何把获取的知识构建自己的知识体系,不做认知界的“王语嫣”。这个,也许比度量本身更有用。

项目背景:这是一个全新的项目,从0开始构建,项目启动之后,客户提供的一个叫OR的东西,给我们讲解了一遍,后由开发和测试人员共同编写用户故事,并进行反串讲,客户项目经理和总架构师作为需求验收方听我们对用户故事讲解,理解存在差异的,及时提出修正或讨论,这个过程持续了三周左右。 后面基本按迭代的方式进行,在研发二个月后,我们还现场参观了生产线,了解现在机器人的运作方式,回来后对一些场景进行了修正,这也是当时客户架构师未识别到的。

我们来看一下,当时这个项目主要使用以下13个指标进行度量。 本文着重介绍和代码行作为基数参考的单元测试个数、CodeReview缺陷个数,SDV测试缺陷个数,SIT测试缺陷个数,SDV用例个数,SIT用例个数。

你是否觉得很奇怪,我写多少个单元测试、设计多少用例、发现多少个缺陷,与代码行有啥关系?

你是否还发现,居然发现缺陷的数据还有一个最小值,这又是什么神奇的东西。

为什么需要把千行代码行(KLoc)作为参考:我个人理解这是一个经验值,如果不以代码行参考,我们估计只能凭想像我们的案例是否写得差不多了,你是写10个案例呢,还是100个案例呢,要不要继续思考一下有没漏什么呢,等等都是一个问题。 当然你写够了数,也不代码你就真的覆盖全了,还是需要进行评审的。

为什么要设计最小值:拿缺陷来说,我们相信,是个开发就会埋下缺陷,聪明的会埋下聪明的缺陷,初级的会埋下低级的缺陷。没有找到只是你还没有发现,并不是你不会犯错。

再来看看这几个指标的责任人

指标责任人说明

看到此处,你是否明白了什么?我能不能少写几行代码,实现同样的功能。既节约自己寻找缺陷、编写SDV案例等的时间,也节约测试人员编写案例和执行案例时间。

如果哪位大哥有copy paste, 恭喜你,开发和测试是一样受累的,这里不详述。 测试也充分理解开发, 若非必要,他也不会难为自己,一起加班努力提高质量吧。

这些指标如何落地,真心不太容易。我们是经历过一个痛苦的过程去学习才最后得以达成的。前置指标达成,不能往后一步流程走。这又何尝不是一个实实在在的质量内健的案例。

团队里最开心的事:开发自己找到缺陷,测试自己找到缺陷,相互找到缺陷... 其实我们最开心的事,这个缺陷不会在生产上发生。

相信你也许看明白了,我们鼓励发现缺陷,我们认为本身就应该有这么多缺陷是正常的,我们也不相信神话。我们同时指标设计也是相互约束的,无公害的,高度协同的。

不再赘述太多,如果对你有所感,请思考未来如何有效在你所在场景的度量。也期望你能够成为高手,建立自己的知识体系。借用一代宗师里面的一句话:见自己,见天地,见众生

也以此文献给一起在悍马机器人项目上奋斗的15位兄弟姐妹。一起让代码覆盖率、可维护指数超过了80%。

你可能感兴趣的:(不做认知界的王语嫣-研发效能度量的谬误(续))