许多有开发规范的企业会采用瀑布模型、V模型或迭代等模型进行开发，但是，当出现进度紧张的项目时，这样项目会很自然地采用“Coding & Testing”的开发模式——上来就编码、写完代码再测试的原始开发方式。所以那些规范看起来只是给进度宽松的项目用了，进一步说，他们认为Coding & Testing的开发模式效率是相对高的，而需求分析、设计等活动是给那些有宽裕的时间并且想让项目看起来过程“漂亮”的项目来做的。

如果Coding & Testing的开发模式是高效率的，那么不论这个项目的进度是否紧张，都应该选择这样的模式，没有理由做画蛇添足的事情，而且也不是繁琐的开发过程才能让项目看起来规范漂亮，简单才是美；如果Coding & Testing的开发模式是低效率的，那么进度紧张的项目绝对没有理由采用这种低效的开发模式。因此，不论Coding & Testing的开发模式是高效率还是低效，只有在进度紧张的项目采用该模式，这样的做法逻辑上是讲不通的。

那么相对于软件工程所提出的一些开发模型，Coding & Testing的开发模式是高效率还是低效的？其实，回答这个问题就像回答“是马车跑得快还是汽车跑得快一样”一样容易。

软件开发过程中，最重要的工作莫过于需求分析了，如果需求没有搞清楚，好比目的地不清楚在哪了，此时车开得再快意义也不大。当年，华为为了学习印度优秀的软件开发过程，在印度成了研究所，国内派了一批工程师到印度取经。国内软件工程师看到印度软件工程师做项目很奇怪，项目已经开始了，他们不像中国软件工程师那样在电脑前埋头敲啊敲，而是大家站在白板前“争争吵吵”，吵着吵着，需求就吵清楚了，然后再把需求文档化，之后还要进行严格地评审，进一步发现需求理解不错误的地方。如果让中国软件工程师来做这个项目，在印度软件工程师一行代码还没写出的时候，估计我们工程师已经把代码写得过半了！真不知道这些“效率低下”的印度人如何让印度成为软件产业强国的！接下来，印度工程师会依据需求设计系统测试用例，此时还可能发现少量的需求错误。再接下来的设计、编码、单元测试、集成测试和系统测试一路通畅！编码的工作量一般不会超过项目总工作量的15%，最后系统测试活动一般占总工作量的10%。而中国工程师做的项目，典型的情况是，很快地代码编写出来了，接着再测呀改呀，改呀测呀，没完没了，最后交给客户，客户会说这不是他们想要的，那不是他们想要的，再接着改呀测呀……最后当客户拿到了还算满意的产品时，项目的总工作量已远远超过了印度人开发方式所需要的工作量。

选择Coding & Testing的开发模式的人们会认为，虽然事先做好需求和设计的确可以减少编码、测试以及返工工作量，然而需求和设计本身所占用的大量的工作量足以超过它为编码、测试、返工所节约的工作量。然而，事实与他们的臆想差别很大，省略了需求和设计，相当于把需求和设计的问题遗留到了后期去解决，其工作量会以十倍、百倍的膨胀，导致最后的测试和返工工作量非常庞大，项目延期在所难免了。

长久以来，编码工作被视为复杂的高智力活动，因为在Coding & Testing的开发模式下的确如此：编程人员已不是纯粹的程序员，他/她在编程时候头脑中要假象出客户的需求是什么，同时也要考虑设计问题。一个人在做一件事的同时还要考虑其它的很复杂的事情，难怪一般人编不了程序，或者一般人编了质量也很差。其实，如果软件规模很小、复杂度很低时，不需要什么软件工程一样可以编出可用的程序，如同搭一个狗窝，还需要什么建筑工程吗？然而，今天我们普遍面对的软件，其规模和复杂度已经超出了人们同时进行几方面工作的能力，此时，必须把需求、设计活动从编码活动中独立出来才可能把工作做好，比如建筑奥运鸟巢绝对不会一边在建造一边在考虑需求和设计。

作为汉捷研发管理咨询顾问，我常常在培训和咨询过程中强调，一个IT企业能够把软件需求需求分析做到位了，那么他们的开发能力一定会有一个质的飞跃！最后引用软件工程领域的经典著作《人月神话》，看看大师们是怎样看待软件需求的：

开发软件系统的过程中，最困难的部分是确切地决定搭建什么样的系统。没有其他任何工作比确定详细的技术需求更加困难。需求对系统的影响比其他任何一个部分的失误都大…软件开发人员为客户所承担的最重要的职能是不断重复地抽取和细化产品的需求。