BUG数量和项目成本

  这篇文章,不是讨论怎么提升程序员的能力避免BUG,因为程序员的能力不足造成的BUG,短期是无法避免的。这里主要探讨的是因为程序员疏忽大意和不良的开发习惯,产生的低级BUG,对项目成本影响。 首先了解下软件测试流程,mantis是跟踪BUG的一种工具,具体流程如下图:

BUG数量和项目成本 

  根据流程图可以发现,测试组发现的BUG和程序员自己发现并修改BUG(绿色),会多出6个节点(紫色)。每个节点对工作量的影响有多少呢?或许有人会说,这些紫色部分消耗时间很少,1到2分钟最多5分钟能完成,理论上是这样。在从事高脑力劳动的工作时,每一项工作在开始之前都会有工作切换的时间损耗,2分钟的工作,你的切换和思考进入另一种工作流的时间同样也需要2分钟(阅读《人件》,关于时间碎片和工作流的介绍),那么每个流程节点至少需要5分钟。也就是说经测试组发现的BUG比程序员自己发现BUG,要多消耗30(5x6)分钟的公司人力成本。

  你是否有了解你所在的公司,2个程序员3个月开发周期的小项目,有多少个BUG呢?以CMMI3的标准,每千行代码可以有2.39个BUG,则BUG数是50个左右。实际上你所在的公司BUG数不会少于70个,可能在70-100甚至更多(本人曾遇到过刚工作一年的程序员,这种规模的BUG数达到150个)。按统计规律这些个BUG中,有1/3个应该是比较低级的,程序员自测就可以发现的,比如界面错误等等。这些低级别的BUG将消耗600(30X20)到1500(30X50)分钟,相当于2-4人天的项目人力成本。刚才说的是3个月开发周期,那1整年下来,额外项目成本就是8-16人天。如果公司有5个开发小组,10来个人,则1年 的额外项目总成本将达到是40-80人天。因为程序员的小小疏忽或不良开发习惯,放大到整个公司,1年将多消耗2-4人月的人力成本,如果是一个中型的软件公司,成本将非常庞大,注意这个成本是可以避免的,但却最容易被管理层忽视。

   显而易见,BUG越少,公司的项目成本越低。程序员在平时的开发过程中,做好白盒测试,杜绝低级错误,在交付前投入一定的时间测试并修复,不要把测试工作全部依赖测试组,更不要把测试组作为你的专职测试。项目经理在这个阶段可以把好最后一关,同时进行适当的测试,清除显而易见的BUG后,再交付给测试组,由测试组进行更深入的测试,将大幅减少整个公司的项目成本。

你可能感兴趣的:(bug)