|
許多有開發(fā)規(guī)范的企業(yè)會采用瀑布模型、V模型或迭代等模型進(jìn)行開發(fā)，但是，當(dāng)出現(xiàn)進(jìn)度緊張的項目時，這樣項目會很自然地采用“Coding & Testing”的開發(fā)模式——上來就編碼、寫完代碼再測試的原始開發(fā)方式。所以那些規(guī)范看起來只是給進(jìn)度寬松的項目用了，進(jìn)一步說，他們認(rèn)為Coding & Testing的開發(fā)模式效率是相對高的，而需求分析、設(shè)計等活動是給那些有時間并且想讓項目看起來開發(fā)過程“漂亮”的項目來做的。
如果Coding & Testing的開發(fā)模式是高效率的，那么不論這個項目的進(jìn)度是否緊張，都應(yīng)該選擇這樣的模式，沒有理由做畫蛇添足的事情，而且也不是開發(fā)過程繁瑣等同于規(guī)范、等同于漂亮，簡單才是美。如果Coding & Testing的開發(fā)模式是低效率的，那么進(jìn)度緊張的項目更沒有理由采用該開發(fā)模式。因此，不論Coding & Testing的開發(fā)模式是高效率還是低效，只有在進(jìn)度緊張的項目采用該模式，這樣的做法邏輯上是講不通的。
那么相對于軟件工程所提出的一些開發(fā)模型，Coding & Testing的開發(fā)模式是高效率還是低效的？其實，回答這個問題就像回答“是馬車跑得快還是汽車跑得快一樣”一樣容易。
軟件開發(fā)過程中，最重要的工作莫過于需求分析了，如果客戶的需求沒有搞清楚，所編寫的代碼同垃圾沒什么兩樣。而需求分析也往往是最有挑戰(zhàn)的工作，要求需求分析人員不僅僅有計算機(jī)知識，更重要的是要有領(lǐng)域知識，接下來要具備很強(qiáng)的溝通能力。軟件不是存在與真空中，它一定是用力幫助我們解決生活和工作中一些問題，比如項目管理軟件是用來輔助項目經(jīng)理進(jìn)行項目管理的；淘寶的商品交易網(wǎng)站軟件為買家和買家提供了遠(yuǎn)程進(jìn)行商品交易安全便捷的手段。如果，要做好項目管理軟件，那么需求分析人員要掌握項目管理的知識；同樣，為淘淘做網(wǎng)站軟件的軟件工程師來說，他們一定要很熟悉B2B/B2C的業(yè)務(wù)模式。計算機(jī)知識好比我們學(xué)會了漢字、掌握了語法和修辭，這些并不能保證我們會成為一個優(yōu)秀的作家，生活的豐富閱歷和對生活的深度思考才是一個優(yōu)秀作家的關(guān)鍵技能，而這項關(guān)鍵技能的獲得需要長久的磨煉和甚至要一定的天賦。相類似的，掌握領(lǐng)域知識遠(yuǎn)比掌握計算機(jī)知識難，比如學(xué)JAVA語言，三個月應(yīng)該可以精通，而要掌握管理知識、掌握金融業(yè)務(wù)流程也許經(jīng)過三年才剛?cè)腴T。因此，一位研究雷達(dá)的教授曾說過：“我寧可要一點計算機(jī)都不懂但是懂得雷達(dá)的人也不要計算機(jī)精通但一點雷達(dá)知識都沒有的人做學(xué)生。”
要做好需求，需求分析人員還要具備很強(qiáng)的通過能力?？蛻粜枨髱缀鯊膩矶疾粫逦財[在項目面前，需求發(fā)生人員首先要識別干系人，然后用合適的方法挖掘干系人的需求和干系人確認(rèn)需求，這個過程需要責(zé)任人要有很強(qiáng)的人際交往能力、語言通過能力和文字通過能力。
最后需求分析人員要掌握一定的計算機(jī)知識，因為需求架起了客戶到設(shè)計人員之間的一個橋梁，需求分析人員最后要把客戶需求以設(shè)計人員能夠理解的技術(shù)語言描述出來，把客戶需求傳遞給設(shè)計開發(fā)人員，這項工作通常體現(xiàn)在軟件需求規(guī)格說明書中。
相比之下，從事編程的程序員，僅僅懂得編程語言就夠了，而一門計算機(jī)語言的掌握對于智商不是很低的人來，花費一兩個月完全足夠，特別是由于硬件的發(fā)展，編程越來越重視程序的可讀性，而不鼓勵使用編程高超技巧讓程序很難維護(hù)。
軟件設(shè)計的重要度介于需求和編程之間了。需求告訴我們軟件要做什么，解決what的問題，而設(shè)計告訴我們軟件是如何實現(xiàn)這些需求的，解決how的問題。簡而言之，良好的需求確保軟件做了正確的事情，良好的設(shè)計確保軟件正確地做事情。軟件設(shè)計是對復(fù)雜問題不斷分解簡化的過程，當(dāng)一個復(fù)雜問題被分解為眾多個簡單的模塊，再去實現(xiàn)各個模塊就會變得很容易。
從軟件需求分析、到軟件設(shè)計、到編碼，越是前期的工作越是重要、越是有難度，對軟件質(zhì)量的影響也是越大。我們來看看建筑行業(yè)是如何做的，也就懂得這個道理。
享譽(yù)全球的華裔建筑大師貝聿名有許多不作，如約翰·肯尼迪圖書館、巴黎盧浮宮玻璃金字塔、香山飯店等等。那么，他的這么多作品中，有哪個是他親手建造的？眾所周之，我國建筑工人大都是的來自鄉(xiāng)下“農(nóng)民工”，是他們一磚一瓦地建起了高樓大廈，甚至是建筑上藝術(shù)品，然而，建筑行業(yè)最需要的和敬仰的是貝聿名建筑大師，而不是建筑工人。程序員就如同這些建筑工人一樣，所做的工作技術(shù)含量不大，依據(jù)設(shè)計去實現(xiàn)就好了，建筑工人依據(jù)設(shè)計按照建筑的技術(shù)要求一磚一瓦地砌，而程序員依據(jù)設(shè)計按照程序語法規(guī)則一個個字符羅列，主要是體力勞動了，復(fù)雜的腦力勞動在前期的建筑師和軟件分析師、設(shè)計師完成了。
我們好像沒有見過哪一幢大樓沒有事先的設(shè)計而直接開建的，這樣的大廈多半在沒有建好前就會倒掉。而許多“軟件大廈”呢，在沒有搞清楚需求、沒有設(shè)計的情況下就開始一一行代碼在建造了，“軟件大廈”是無形，如果它能映射到有形的大廈，那么它們一定是七扭八歪的，可能交給客戶前就倒塌成一片廢墟。
長久以來，編碼工作被視為復(fù)雜的高智力活動，因為在Coding & Testing的開發(fā)模式下的確如此：編程人員已不是純粹的程序員，他/她在編程時候頭腦中要假象出客戶的需求是什么，同時也要考慮設(shè)計問題。哇，一個人在一件事還要考慮其它的很復(fù)雜的事情，這樣工作的確復(fù)雜得很，是否有能力超強(qiáng)的人在做編碼同時能夠把需求和設(shè)計做好？當(dāng)軟件規(guī)模小、復(fù)雜度低時，會有這樣的人，但是對于如今我們普遍面對的軟件，其規(guī)模和復(fù)雜度已經(jīng)不允許一個人同時做幾樣復(fù)雜的工作。搭一個狗窩，不必要把需求、設(shè)計活動獨立出來，而建筑奧運(yùn)鳥巢絕對不會有人敢一邊在建造一邊在考慮需求和設(shè)計。
1998年，華為公司在印度成立印度研究所，學(xué)習(xí)印度先進(jìn)的軟件開發(fā)管理經(jīng)驗。國內(nèi)工程師看到印度人做項目很奇怪，項目已經(jīng)開始了，他們不像中國工程師那樣在電腦前埋頭敲啊敲，而是大家站在白板前“爭爭吵吵”，吵著吵著，需求就吵清楚了，然后再把需求文檔化，之后還要進(jìn)行嚴(yán)格地評審，進(jìn)一步發(fā)現(xiàn)需求理解不錯誤的地方。如果讓中國工程師來做這個項目，此時，估計已經(jīng)把代碼寫得過半了，可是這些印度人居然連一行代碼都沒寫！真不知道這些“效率低下”的印度人如何讓印度成為軟件產(chǎn)業(yè)強(qiáng)國的！接下來，印度工程師會依據(jù)需求設(shè)計系統(tǒng)測試用例，此時還可能發(fā)現(xiàn)少量的需求錯誤。再接下來的設(shè)計、編碼、單元測試、集成測試和系統(tǒng)測試一路通暢！編碼的工作量一般不會超過項目總工作量的15%，最后系統(tǒng)測試活動一般占總工作量的10%。而中國工程師做的項目，典型的情況是，很快地代碼編寫出來了，接著再測呀改呀，改呀測呀，沒完沒了，最后交給客戶，客戶會說這不是他們想要的，那不是他們想要的，再接著改呀測呀……最后當(dāng)客戶拿到了還算滿意的產(chǎn)品時，項目的總工作量已遠(yuǎn)遠(yuǎn)超過了印度人開發(fā)方式所需要的工作量。
見圖2.1，選擇Coding & Testing的開發(fā)模式的人們會認(rèn)為，雖然事先做好需求和設(shè)計的確可以減少編碼、測試以及返工工作量，然而需求和設(shè)計本身所占用的大量的工作量足以超過它為編碼、測試、返工所節(jié)約的工作量。然而，事實與他們的臆想差別很大，見圖2.2，省略了需求和設(shè)計，相當(dāng)于把需求和設(shè)計的問題遺留到了后期去解決，其工作量會以十倍、百倍的膨脹，導(dǎo)致最后的測試和返工工作量非常龐大，項目延期在所難免了。
  圖2.1 臆想的省略需求設(shè)計工作會減少總工作量
圖2.2 實際的省略需求設(shè)計工作會大大增加測試和返工工作量 我曾經(jīng)來到一個軟件項目的開發(fā)現(xiàn)場，該項目正處于需求分析階段，我走進(jìn)他們?nèi)菁{著二、三十人的辦公室，屋里很安靜，大家都各自在電腦前辛勤地工作著，如果這時走進(jìn)來的是總經(jīng)理，這樣的場景也許會讓他很滿意，但作為接觸過許多項目的過程改進(jìn)咨詢顧問，我卻嗅到了項目正走向失敗的氣味。電腦不會告訴我們客戶的需求是什么，如同一個作家，不會抱著字典奢望它會帶來寫作靈感一樣。一個項目如果沒有努力把各個干系人的需求挖掘出來、描述清楚，并和客戶進(jìn)行確認(rèn)，意味著這個項目后期的不得不承受大量失效成本，最終意味著項目的超預(yù)算、延期。 |
|
|
