BUG数量和项目成本

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

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

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

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