如何進(jìn)行項(xiàng)目的質(zhì)量管理

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

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

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

　　1、分析階段

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

　　在需求階段"順利"結(jié)束的同時(shí)，問題也隨之留下來，并對(duì)后面的階段起到了"乘數(shù)效應(yīng)"――影響變得越來越大：

　　A. 對(duì)舊系統(tǒng)的理解不足

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

　　B. 對(duì)新需求的分析不夠

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

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

　　2、設(shè)計(jì)階段

　　設(shè)計(jì)階段的問題相對(duì)比較明顯――結(jié)構(gòu)設(shè)計(jì)不合理，或者說還不夠。一個(gè)傳統(tǒng)的C/S結(jié)構(gòu)的系統(tǒng)，基本結(jié)構(gòu)我們采用了經(jīng)典的三層模型來劃分系統(tǒng)。由于是在舊有系統(tǒng)上的改進(jìn)，我們?cè)诒M量不改變?cè)邢到y(tǒng)的基礎(chǔ)上添加新的功能。

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

　　3、編碼階段

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

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

　　4、測(cè)試階段

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

　　大家可以看到，軟件的質(zhì)量可能就是被這一步步的失誤，錯(cuò)誤，粗心等等影響了。這些問題都是在項(xiàng)目管理中暴露出來的，可以說是由于項(xiàng)目經(jīng)理對(duì)于質(zhì)量的要求還不高，有的時(shí)候?yàn)榱似孀非蟪杀九c時(shí)間而忽視了質(zhì)量，從而造成了質(zhì)量的下降。算是個(gè)總結(jié)和教訓(xùn)吧，也希望大家能夠說出你的想法與意見，多多交流，共同進(jìn)步。

　　相關(guān)推薦:項(xiàng)目責(zé)任制下的質(zhì)量管理

　　簡(jiǎn)述施工企業(yè)工程項(xiàng)目質(zhì)量管理中的四抓

　　淺談建筑工程施工質(zhì)量的管理