编写背景：
今年的测试任务，开发工期非常紧张，导致开发提测的版本质量很差，每个月的bug总数都过百，对测试工作进度有一定影响；时间长了，对于这个现象突然觉的已经习惯了，对开发质量的改进工作已经不抱希望；但对测试工作的质量和效率改进还是很有期待。
这篇文章多少反馈了IT项目中的一些真实现象，在此收藏供以后查阅，题目我给改了！！
文章出处：http://www.blogjava.net/zbw25/archive/2005/11/07/20897.html
在探寻软件开发以往的方法论背后的假设之前，首先要指出的是，这些假设很难被发现，不是说它们不存在，而是这些加上很少被看成是假设，往往作为理所当然的一部分，被排除在常规的思考范围之外。让我们来看几段大家都很熟悉的文字吧。
“大多数大型软件项目都没有达到预期的目标，交付推迟，预算超支，功能不完善。许多软件项目彻底失败了。”
——FDD
“当前，软件开发的情况并不理想。很多系统最终不能交付，或者最终交付的系统经常性地发生延期或者超出预算；系统常常不能满足用户的需要，其结果是不得不一遍又一遍地开发。”
——AM
“许多软件项目，或许应该说大部分软件项目实际的开发周期比预期的要长，实际的花费比预期的要多，实现的功能比预期的要少。这造成了严重的质量问题。”
——某一本CMM的书籍
怎么样，是不是似曾相识？我敢肯定，你不只在一本书的序言部分，看到过类似的文字。无论这本书写于70年代、80年代、90年代还是21世纪。情况一直都是这么“糟糕”。有趣的是，这些书都会在“痛说软件开发现状”之后，转而兜售自己的方案。当然，在Brooks的《没有银弹》之后，他们兜售的语气谦虚了很多。作为一个文化现象来说，这非常值得细细品味。但是，我们需要追问的是：为什么？
难道软件开发是全世界最难的事情吗？为什么失败率如此之高？如果我们在使用了层出不穷的手段之后，还是不能提高成功率，我们应该怎么办？其实也很容易，当年我的一个老板就想出了一个绝妙的办法，绝对简单，就是将我自己的工作量估算乘2！我们的项目几乎从不失败，总是能够在计划时间内完成。于是我想，如果我们把全世界的软件项目估算都乘以2的话。也许软件开发这个行当，也能成为一个有尊严的职业。大家都会生活得更加幸福。
“这实在是太过分了！”也许有人会说：“你这是自欺欺人、掩耳盗铃、移靶就箭！”但是且慢生气，生气的人应该冷静下来反思：如果目标如此难以达到，会不会是目标有问题呢？当然，事情没有这么简单，如果把目标直接乘2来提高成功率，全世界的老板都会发疯的！我们要做的，是提高估算的准确性。
“啧啧，还以为是什么了不得的结论呢！这个问题早就有人研究了，不就是IT度量吗？”一定会有人站出来这么说。但是，IT度量的研究，提高了估算的准确度了吗？思路在这里被卡住了。直到有一天，我看到了量子力学中的“测不准原理”！
“测不准原理”告诉我们，在物理学中存在着很多对变量，当我们想要精确测量其中一个变量时，对另一个变量的测量误差就会越来越大。但是，在软件开发里，我们是进行估算，而不是进行测量，而且也不存在一个和工作量相对的变量，当工作量估算准确时，它会变得模糊。简单地套用物理定律是行不通的，思路又卡住了。
突然有一天，我问自己：“假设工作量已经估算精确到了99.9999％会出现什么情况？”“不可能！”“如果真的达到了这个精确度了呢？”我对自己穷追不舍。“那只有一种情况，就是项目已经接近完成了！”“我们估算完成时，项目接近完成，这意味着什么呢？”“这毫无意义，没有一个项目会花这个多时间来估算，而且如果要这样估算，估算本身要花多少时间都不知道。”停！我已经想通这个问题了。
估算工作量也是一种工作，同样也需要工作量。对于大多数任务来说，估算所花费的工作量，相对与总的工作量来说，几乎可以忽略不计，或者说：为了能够得到一个有指导价值的估算值，所花费的工作量，几乎可以忽略。但是，对于软件开发来说，这只是一个假设。我们假设对于软件开发的工作量估算，同样只需要花费极少的工作量。但事实上，当我们花费三五天时间得出结论，这个项目需要20个人月时，我们估算的误差，可能（甚至一定）会大于200%这就是我们这个行业显得如此失败的原因。
为什么这个行业与其它行业不同呢？在建筑行业，工程概预算的费用，不超过总费用的百分之一、甚至千分之一。为什么软件项目的估算做不到这一点？因为两个原因：
一是由于技术的复杂性，以及这个行业技术的飞速发展（也可说尚未定型），同样的需求，采用不同的设计，不同的技术实现，工作量相差极大。仅仅根据需求，无法估算出工作量。而随着概要设计、详细设计的层层分解，工作量估算的精确度的确会提高，但是对于软件开发来说，项目也越来越接近完成了。
二是由于需求的变动性以及不可预测性。早期的估算、设计甚至代码，都有可能作废。一个项目实际上重做了N遍，在软件开发领域也是常有的事。估算的误差，自然也就大到不可思议了。
然而，绝大多数人没有想过这个问题，大家都自然而然的根据最初的工作量估算，来评价以后的工作。
工作量/人员效率＝项目时间
工作量×单位成本＝项目成本
缺陷总数/工作量＝软件质量
我们根据最初估算的工作量，来推出项目的时间、成本和质量目标，我们假设工作量估算只花费可以忽略不计的工作量，我们依据这些目标来衡量项目的成败，然后我们发现大多数项目都失败了，然后我们研究技术、改进过程、寻找银弹！最终，我们发现自己还是这么失败！
是到了彻底反省我们的假设的时候了。