“小测，明天的周例会，请你先准备项目的质量测试报告。我重点要看一下缺陷密度的数据”，项目经理找到测试组组长说到。
“额......缺陷密度......经理，说实话，因为项目上要求缺陷密度要达标，所以我们组员都在尽量测试bug。”小测紧张的说到。“但是目前看，数量确实是上来了。但是bug的质量不高，很多bug我认为都是可提可不提的。”
“为什么会这样呢？”项目经理有点疑惑不解。
“不知道。缺陷密度的指标一下来，大家都不想指标达不成，所以都在拼命的测试bug。但是功能数量和复杂度有限，确实没办法测试出那么多bug。”小测也无奈的叹了叹气。
在实际的项目上，你们是否也遇到这样的情况呢？
所谓“上有政策，下有对策”。没人敢于对看似不合理的指标或者管理方式提出质疑，而是找到一种自认为比较合理的办法做事。这样的处理办法不但无法暴露真实的项目情况，更会给项目员工一种假象，即质量是假的，是不真实的。而这些由他们亲手制造的假象，最终也会害了他们自己。轻则会进行多次的返工、加班修补质量。重则将导致项目因质量不合格而失败。
我们说度量，其实它的原则是很清晰的。以目前团队所能掌握的信息，制定一个目前来看可执行的制度或者计划。再将制度或者计划拆分到足够细致，细致到可以做到每天出现成果。再在执行的过程中，将实际成果与计划进行比较。如果此时所有人仍旧认为原来的计划或者制度是正确的，那么分析出实际与计划的偏差在哪里并做针对性的改进。此时如果能够给出量化的数据将会很有说服力。而如果团队都认为，实际的执行情况是正确的，当初定计划的时候，缺少了必要的考虑，那么此时重要的将不再是坚持原来的计划，而是适时的调整计划即可。
而“缺陷密度”只是度量的一个手段。
度量的真正意义是持续改进。
先制定标准。这个标准犹如一把尺，一把标准的尺。而度量就是用这把尺去丈量。丈量的结果是否符合预期呢？如果不符合预期，就要寻找与之相匹配的方法进行改正。改正之后，再使用这把尺子进行丈量，直到丈量不出任何问题。这个过程就叫做持续改进。如果所有的事物全部都是一成不变的，那么这个世界运转的规律将非常简单。但显示世界往往就是变幻莫测，不经意间的风云突变，往往是人生常态。所以持续改进将是应该如今复杂环境的万金油，是一套行之有效的法门。
缺陷密度的概念通常可以理解为：每千行代码中的bug数量。如果一套软件系统的缺陷密度是5，通常说明每一千行代码中，将产生平均5个bug。当然缺陷密度只是度量标准中的一个，还有很多其他的度量的指标。但是万变不离其中，计划与实际比较，就差异进行分析，并做相应的修改。
但为什么项目实际情况中，会出现文章开头处对话说描述的样子呢？
我认为大多数人并不愿意理解事物背后的复杂原因，而且真实的原因并不易于传播，否则流言蜚语就会不攻自破。人的天性是厌倦思考的。如果你还记得缺陷密度的定义的话，你应该知道它只是一个相对变量。它是由代码行数和bug数量共同决定的。它代表的是一种趋势，即写的代码越多，代码复杂的程度的概率会增加。而复杂度的增加，会增加测试的难度，也就间接的增加了缺陷发生的概率。概率大了，bug的数量也会多了。它揭示了简单的道理，干的越多，错的越多。这是放诸四海皆准的道理。
而文章开头的情况下，人们并不会时时刻刻的将这样一长串的逻辑因果想起来。他们只记得想要缺陷密度上升，bug数量越多越好。久而久之，在后续的不断传播的过程中，所有人都会简单的记得，提高bug数量就会提升缺陷密度的数值，而忘却了代码量的问题。而且代码量并不是那么的显而易见，需要专业的开发人员利用工具才可以得到，并没有bug的数量更加直观而已。
所以，缺陷密度也好，圈复杂度也罢。都只是度量项目质量的方法和工具，他们都是一种趋势，一种反应纯粹物理现象的一种规律。我们要做的只有通过度量去发现问题并解决问题，找到根本解。而不是寻找一个自己易于理解的原因，停留在表面解上。
网友评论