大家知道，項目的時(shí)間、成本及質(zhì)量的三大要素是缺一不可。這三方面的符合程度直接決定了項目的成敗與否。但事實(shí)上，想達到一個(gè)完美的等邊三角形幾乎是不可能完成的任務(wù)。這次的項目就讓質(zhì)量這個(gè)角短了很多，質(zhì)量的問(wèn)題暴露地很明顯。所以，接下來(lái)，我就從項目的流程角度出發(fā)，一步步地分析到底是哪里出了質(zhì)量問(wèn)題。 

　　又一個(gè)項目結束了，終于閑出空來(lái)寫(xiě)些東西。有了以前的經(jīng)驗教訓，這次在做項目的時(shí)候，我對時(shí)間的控制很關(guān)注，最后也基本上達到了計劃的要求。但最終交付產(chǎn)品的質(zhì)量卻讓我不太滿(mǎn)意：客戶(hù)在做接受測試的時(shí)候發(fā)現了很多的問(wèn)題，而且在我們進(jìn)行修改的同時(shí)，又有BUG源源不斷的報過(guò)來(lái)。甚至把更新的版本發(fā)給客戶(hù)以后，還會(huì )發(fā)現不少問(wèn)題，給客戶(hù)留下了很不professional的印象。為什么問(wèn)題總是要到項目快結束的時(shí)候才會(huì )出現呢？軟件的質(zhì)量為何不好？究竟是誰(shuí)動(dòng)了項目的質(zhì)量？

　　1、分析階段

　　項目的開(kāi)始階段，也是質(zhì)量控制的開(kāi)始。在這個(gè)階段中，主要的工作是從客戶(hù)方獲得足夠多的項目需求，并準確地記錄在案，而且要使得項目組的成員對于需求足夠得了解。先說(shuō)說(shuō)這個(gè)項目的基本情況：一個(gè)信息管理系統，而且是在原來(lái)的版本上進(jìn)行的功能增加。項目組的成員，除了我以前參加了前一個(gè)版本的開(kāi)發(fā)，其它的人員都不了解這個(gè)項目。就是這樣的一個(gè)項目，在開(kāi)始階段，我先是安排了組員對以前版本的需求文檔進(jìn)行了閱讀，并安裝使用了軟件。隨后對新的需求進(jìn)行了研究，分析了它們對于原有系統的影響。由于是在舊有系統的文檔進(jìn)行增加，所以加入的新內容并不是很多，需求文檔很快就完成了。所謂的分析階段的里程碑也就結束了。

　　在需求階段＂順利＂結束的同時(shí)，問(wèn)題也隨之留下來(lái)，并對后面的階段起到了＂乘數效應＂――影響變得越來(lái)越大：

　　A.對舊系統的理解不足由于開(kāi)發(fā)人員沒(méi)有參與過(guò)上一個(gè)版本的開(kāi)發(fā)工作，他們對于舊系統并不了解．雖然在閱讀了以前的需求文檔以及使用了軟件之后，大概對系統的功能有了一個(gè)初步的認識．但是對于系統中出現的各種邏輯關(guān)系并沒(méi)有深入了解下去．作為項目經(jīng)理，在這項工作中，失誤之處在于任務(wù)的結果（即輸出）沒(méi)有事先定義清楚，從而也就導致無(wú)法確認目標是否已經(jīng)達到，再加上需求文檔描述的也不是十分清晰。最后，只是在開(kāi)發(fā)人員覺(jué)得已經(jīng)理解該系統的基本上，進(jìn)行了下一步的工作．沒(méi)有進(jìn)行進(jìn)一步的確認工作，不知道組員進(jìn)行舊系統已經(jīng)了解到了什么樣的程度。這個(gè)問(wèn)題的結果，就是直接導致了后期的開(kāi)發(fā)過(guò)程中，由于對于原先系統的邏輯關(guān)系不是很清楚。對于舊代碼理解和新代碼編寫(xiě)進(jìn)行地不是很順利。

　　B.對新需求的分析不夠這還是個(gè)老問(wèn)題，但又不是一個(gè)問(wèn)題．說(shuō)它是個(gè)老問(wèn)題，因為分析需求要求考慮細致全面，并且能引導客戶(hù)，啟發(fā)客戶(hù)提供更有價(jià)值的信息。事實(shí)上，需求分析我們做的算是很盡力了，同時(shí)客戶(hù)把需求一條條的列出來(lái)給我們，相對來(lái)說(shuō)需求已經(jīng)很清楚了。我們在接到這些需求后，不僅研究了新功能，還把他們對于舊系統的影響都做了分析。但還是有些問(wèn)題沒(méi)有能在需求文檔中反映出來(lái)，后面的影響也是可想而知的了。我以前的文章中才曾提到過(guò)相關(guān)的問(wèn)題，在這里就不再重復了。不過(guò)，從另一個(gè)角度來(lái)看，它又不是一個(gè)問(wèn)題。為什么這么說(shuō)呢，因為需求實(shí)在不是能夠在分析階段就能完全理解透徹的，甚至有的需求客戶(hù)也模模糊糊，直到交付以后才提出了改動(dòng)的要求。軟件開(kāi)發(fā)經(jīng)過(guò)這么多年的發(fā)展，大家已經(jīng)認識到了一點(diǎn)：需求是變化的。要達到能夠擁抱變化的要求，我們要對開(kāi)發(fā)方法進(jìn)行改進(jìn)，相關(guān)的問(wèn)題我在后面也會(huì )提到。

　　需求分析階段出現的問(wèn)題，解決的可操作性不是很大，更多的是從思想或經(jīng)驗上解決，而后面幾個(gè)階段出現的問(wèn)題都相對具體一些。

　　2、設計階段

　　設計階段的問(wèn)題相對比較明顯――結構設計不合理，或者說(shuō)還不夠。一個(gè)傳統的C/S結構的系統，基本結構我們采用了經(jīng)典的三層模型來(lái)劃分系統。由于是在舊有系統上的改進(jìn)，我們在盡量不改變原有系統的基礎上添加新的功能。

　　主要的問(wèn)題可能就是體現在沒(méi)有對舊系統進(jìn)行改進(jìn)。舊系統本身有一些復雜的功能，邏輯關(guān)系也比較復雜，耦合度非常高。所以，在新需求來(lái)臨的時(shí)候，我們的第一反應就是盡量不去動(dòng)原來(lái)的設計與代碼，保證原有系統功能不會(huì )發(fā)生變化。這一點(diǎn)就暴露出了我們沒(méi)有去擁抱變化的決心與膽量。雖然舊系統很復雜，但是我們不能去故意回避它。對于舊系統中設計的不合理的地方，應該主動(dòng)大膽的去進(jìn)行重構。其實(shí)重構的作用就是對不合理結構的進(jìn)行改進(jìn)，設計模式更是在設計結構的變化改進(jìn)中才能體現它的價(jià)值。而這些東西，在我們的項目中都沒(méi)有應用．這可能跟我們的保守心理有關(guān)：只要不出問(wèn)題，我們就不去動(dòng)它，哪怕結構是多么的錯綜復雜。這種消極的觀(guān)念在當今的充滿(mǎn)變化的世界中是不太有前途的。項目經(jīng)理要有足夠的決心去做，同時(shí)，也不要擔心去變化。當然，可能有人會(huì )說(shuō)，時(shí)間緊怎么辦，其實(shí)這種付出對于項目的整體是只有好處沒(méi)有壞處的，因為結構合理會(huì )讓開(kāi)發(fā)人員會(huì )更少的時(shí)間去理解代碼，減少代碼開(kāi)發(fā)的復雜度，提高代碼編寫(xiě)的質(zhì)量。唯一需要考慮的就是如果改動(dòng)的話(huà)，如何來(lái)保證這種變化對原有系統的功能不產(chǎn)生影響。這就需要有更多的測試，最好是單元測試來(lái)保證，這就是下面會(huì )談到的問(wèn)題。

　　3、編碼階段

　　編碼主要還是受了設計的限制，我們的主要工作就只是在原有的結構上添加一些類(lèi)與方法，以及對原有的代碼進(jìn)行修改。前面也提到了，我們采用了比較保守的作法，沒(méi)有對代碼進(jìn)行重構，放任這種高耦合的代碼存在，導致我們在編碼過(guò)程中花費了不少精力和時(shí)間去理解它們，并在其中加上一兩條更加加深耦合度的代碼。其實(shí)到了編碼階段，很多問(wèn)題都糾纏到了一起，已經(jīng)分不清因果了。比較說(shuō)單元測試，首先我需要承認的一點(diǎn)就是沒(méi)有足夠的決心去做充分的單元測試，思想上也沒(méi)有做好充分的準備。除去主觀(guān)的因素之外，還有一點(diǎn)就是設計的結構不合理，很多的邏輯被處理在表示層中，數據處理則被加到了邏輯層中。沒(méi)有劃分出更多的接口供單元測試來(lái)驗證。但反過(guò)來(lái)說(shuō)，沒(méi)有單元測試用例的支持，也降低了我們想要進(jìn)行重構的決心。除了上述的問(wèn)題之外，還有一些細節的地方，如硬編碼，命名規則等都在一定程度上對代碼的質(zhì)量產(chǎn)生了影響。

　　改進(jìn)的辦法，一是從主觀(guān)上接受變化的現實(shí)，主動(dòng)的對代碼進(jìn)行改動(dòng)。單元測試一定要進(jìn)行，最好結合統計覆蓋率的工具一并進(jìn)行，這樣對于每個(gè)接口，都保證有充分多的測試用例來(lái)跑完盡可能多的路徑。在項目的質(zhì)量管理上面，要求還需要更加嚴格一些，一定要按照規范來(lái)進(jìn)行編碼。

　　4、測試階段

　　代碼完成之后，測試的工作也隨之展開(kāi)。但是由于成本的原因，我們并沒(méi)有再加入專(zhuān)業(yè)的測試人員來(lái)進(jìn)行，而只是用開(kāi)發(fā)人員自己來(lái)進(jìn)行系統測試，讓開(kāi)發(fā)人員互相測試別人實(shí)現的功能。由于開(kāi)發(fā)人員與測試人員所需的專(zhuān)注點(diǎn)不同，造成了開(kāi)發(fā)人員很多問(wèn)題在測試中沒(méi)有被發(fā)現，缺乏測試的經(jīng)驗。從另一個(gè)方面說(shuō)，是開(kāi)發(fā)人員不能夠及時(shí)的轉換自己的角色，而是還把自己定位在開(kāi)發(fā)人員上面，更加關(guān)注的問(wèn)題出在什么地方并立刻去解決它，而不是設法去發(fā)現隱藏的Bug。當然，還有一些細節的地方，比如說(shuō)測試都應該是開(kāi)發(fā)人員發(fā)布一個(gè)安裝包，然后單獨進(jìn)行測試，但有的時(shí)候為了圖省事，有的功能在調試狀態(tài)下發(fā)現通過(guò)了，在安裝包中就沒(méi)有再驗證，有時(shí)也會(huì )出現意想不到的情況發(fā)生。

　　大家可以看到，軟件的質(zhì)量可能就是被這一步步的失誤，錯誤，粗心等等影響了。這些問(wèn)題都是在項目管理中暴露出來(lái)的，可以說(shuō)是由于項目經(jīng)理對于質(zhì)量的要求還不高，有的時(shí)候為了片面追求成本與時(shí)間而忽視了質(zhì)量，從而造成了質(zhì)量的下降。算是個(gè)總結和教訓吧，也希望大家能夠說(shuō)出你的想法與意見(jiàn)，多多交流，共同進(jìn)步。