許多有開發(fā)規(guī)范的企業(yè)會采用瀑布模型、V模型或迭代等模型進行開發(fā)，但是，當出現(xiàn)進度緊張的項目時，這樣項目會很自然地采用“Coding & Testing”的開發(fā)模式——上來就編碼、寫完代碼再測試的原始開發(fā)方式。所以那些規(guī)范看起來只是給進度寬松的項目用了，進一步說，他們認為Coding & Testing的開發(fā)模式效率是相對高的，而需求分析、設計等活動是給那些有寬裕的時間并且想讓項目看起來過程“漂亮”的項目來做的。
如果Coding & Testing的開發(fā)模式是高效率的，那么不論這個項目的進度是否緊張，都應該選擇這樣的模式，沒有理由做畫蛇添足的事情，而且也不是繁瑣的開發(fā)過程才能讓項目看起來規(guī)范漂亮，簡單才是美；如果Coding & Testing的開發(fā)模式是低效率的，那么進度緊張的項目絕對沒有理由采用這種低效的開發(fā)模式。因此，不論Coding & Testing的開發(fā)模式是高效率還是低效，只有在進度緊張的項目采用該模式，這樣的做法邏輯上是講不通的。
那么相對于軟件工程所提出的一些開發(fā)模型，Coding & Testing的開發(fā)模式是高效率還是低效的？其實，回答這個問題就像回答“是馬車跑得快還是汽車跑得快一樣”一樣容易。
軟件開發(fā)過程中，最重要的工作莫過于需求分析了，如果需求沒有搞清楚，好比目的地不清楚在哪了，此時車開得再快意義也不大。當年，華為為了學習印度優(yōu)秀的軟件開發(fā)過程，在印度成了研究所，國內派了一批工程師到印度取經(jīng)。國內軟件工程師看到印度軟件工程師做項目很奇怪，項目已經(jīng)開始了，他們不像中國軟件工程師那樣在電腦前埋頭敲啊敲，而是大家站在白板前“爭爭吵吵”，吵著吵著，需求就吵清楚了，然后再把需求文檔化，之后還要進行嚴格地評審，進一步發(fā)現(xiàn)需求理解不錯誤的地方。如果讓中國軟件工程師來做這個項目，在印度軟件工程師一行代碼還沒寫出的時候，估計我們工程師已經(jīng)把代碼寫得過半了！真不知道這些“效率低下”的印度人如何讓印度成為軟件產(chǎn)業(yè)強國的！接下來，印度工程師會依據(jù)需求設計系統(tǒng)測試用例，此時還可能發(fā)現(xiàn)少量的需求錯誤。再接下來的設計、編碼、單元測試、集成測試和系統(tǒng)測試一路通暢！編碼的工作量一般不會超過項目總工作量的15%，最后系統(tǒng)測試活動一般占總工作量的10%。而中國工程師做的項目，典型的情況是，很快地代碼編寫出來了，接著再測呀改呀，改呀測呀，沒完沒了，最后交給客戶，客戶會說這不是他們想要的，那不是他們想要的，再接著改呀測呀……最后當客戶拿到了還算滿意的產(chǎn)品時，項目的總工作量已遠遠超過了印度人開發(fā)方式所需要的工作量。
選擇Coding & Testing的開發(fā)模式的人們會認為，雖然事先做好需求和設計的確可以減少編碼、測試以及返工工作量，然而需求和設計本身所占用的大量的工作量足以超過它為編碼、測試、返工所節(jié)約的工作量。然而，事實與他們的臆想差別很大，省略了需求和設計，相當于把需求和設計的問題遺留到了后期去解決，其工作量會以十倍、百倍的膨脹，導致最后的測試和返工工作量非常龐大，項目延期在所難免了。
長久以來，編碼工作被視為復雜的高智力活動，因為在Coding & Testing的開發(fā)模式下的確如此：編程人員已不是純粹的程序員，他/她在編程時候頭腦中要假象出客戶的需求是什么，同時也要考慮設計問題。一個人在做一件事的同時還要考慮其它的很復雜的事情，難怪一般人編不了程序，或者一般人編了質量也很差。其實，如果軟件規(guī)模很小、復雜度很低時，不需要什么軟件工程一樣可以編出可用的程序，如同搭一個狗窩，還需要什么建筑工程嗎？然而，今天我們普遍面對的軟件，其規(guī)模和復雜度已經(jīng)超出了人們同時進行幾方面工作的能力，此時，必須把需求、設計活動從編碼活動中獨立出來才可能把工作做好，比如建筑奧運鳥巢絕對不會一邊在建造一邊在考慮需求和設計。
作為漢捷研發(fā)管理咨詢顧問，我常常在培訓和咨詢過程中強調，一個IT企業(yè)能夠把軟件需求需求分析做到位了，那么他們的開發(fā)能力一定會有一個質的飛躍！最后引用軟件工程領域的經(jīng)典著作《人月神話》，看看大師們是怎樣看待軟件需求的：
開發(fā)軟件系統(tǒng)的過程中，最困難的部分是確切地決定搭建什么樣的系統(tǒng)。沒有其他任何工作比確定詳細的技術需求更加困難。需求對系統(tǒng)的影響比其他任何一個部分的失誤都大…軟件開發(fā)人員為客戶所承擔的最重要的職能是不斷重復地抽取和細化產(chǎn)品的需求。