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