關(guān)于軟件開(kāi)發(fā)方案的一些想法，經(jīng)?？吹胶芏嗳擞嘘P(guān)項(xiàng)目管理的經(jīng)驗(yàn)，而且都是長(zhǎng)篇大論，侃侃而談；總是看得我暈頭轉(zhuǎn)向，總感覺(jué)，都是停留在人的作用上，總是強(qiáng)調(diào)管理中的人為因素，幾乎很多條目都是帶有很強(qiáng)的人為色彩，看完后，總是覺(jué)得這些經(jīng)驗(yàn)很不錯(cuò)，但是自己往往卻很難在自己的項(xiàng)目中具體實(shí)施。        相關(guān)文章：《常見(jiàn)軟件開(kāi)發(fā)設(shè)計(jì)方案的比較研究》

自己在項(xiàng)目管理中，總是嘗試拋開(kāi)人為因素的困擾，利用一些簡(jiǎn)單通用的工具來(lái)協(xié)助項(xiàng)目管理，通過(guò)這些工具的運(yùn)用，讓它們自動(dòng)來(lái)推動(dòng)項(xiàng)目管理的進(jìn)程，減少人為因素的問(wèn)題，形成一條無(wú)形的推動(dòng)項(xiàng)目進(jìn)程的生產(chǎn)鏈條。
 

核心鏈條：

源代碼管理工具 => Bug追蹤工具 => 每日編譯工具

WinCVS/CVSNT => Bugzilla => BAT和Perl腳本

下面是這些核心工具的運(yùn)用經(jīng)驗(yàn)：

1. 必須建立源代碼的版本控制系統(tǒng)，就是cvs，基本的代碼提交原則：

1) 程序員盡量每天只在下班前提交一次;

2) 提交的代碼必須是在自己的機(jī)器上是正常運(yùn)行的；

3) 每次提交都必須用簡(jiǎn)短的話說(shuō)明自己提交代碼的功能描述。

2. 建立錯(cuò)誤追蹤系統(tǒng)，用Bugzilla就很好，配置好郵件系統(tǒng)，使Bugzilla成為測(cè)試人員與開(kāi)發(fā)人員溝通的橋梁。

3. 用BAT和Perl腳本，以cvs中的源代碼為核心實(shí)現(xiàn)簡(jiǎn)單的每日編譯工具，將這個(gè)自己寫的自動(dòng)化工具放到一臺(tái)專門的編譯機(jī)器上，在每天的半夜開(kāi)始自動(dòng)下載代碼，自動(dòng)編譯代碼，自動(dòng)打包安裝程序，自動(dòng)記錄各種編譯日志，自動(dòng)將安裝程序放置到一個(gè)固定的以日期為目錄名的公共區(qū)。（用cvs2cl.pl得到程序員上傳的代碼更新日志，以便測(cè)試人員參考）

4. 測(cè)試人員的第二天，應(yīng)該到公共區(qū)取得頭天的最新版本，并根據(jù)ChangeLog進(jìn)行新版本的測(cè)試。并將測(cè)試中發(fā)現(xiàn)的Bug，通過(guò)Bugzilla反饋給程序員。程序員可以根據(jù)自己的情況，或公司的規(guī)定來(lái)決定修改這些Bug的時(shí)間。并將這些Bug的修改情況，在代碼提交時(shí)，寫入代碼日志。

5. 開(kāi)發(fā)人員的第二天，應(yīng)該到公共區(qū)查看編譯日志，看看自己的模塊是否正常編譯，及時(shí)更正，看看自己的郵箱有沒(méi)有Bug報(bào)告，及時(shí)修改。

6. 管理人員的第二天，在綜合項(xiàng)目需求與頭天版本進(jìn)度的上，可以判斷產(chǎn)品的發(fā)展方向，如果有偏航或理解錯(cuò)誤或有新需求時(shí)，可以根據(jù)當(dāng)前情況及時(shí)調(diào)整。

這樣，通過(guò) cvs => bugzilla => daily-build，就能將程序員與測(cè)試員，進(jìn)行互動(dòng)，各施其責(zé)。減少溝通與人為的麻煩。對(duì)于管理層，也能做到心中有數(shù)：因?yàn)槊刻於加行掳姹?，隨時(shí)掌握產(chǎn)品的走向……等等。

另外有關(guān)項(xiàng)目管理中與客戶、與公司上層、成本、進(jìn)度等等，這里沒(méi)有具體談，但如果切實(shí)運(yùn)用以上經(jīng)驗(yàn)，會(huì)在一定程度上簡(jiǎn)化這些關(guān)系的復(fù)雜度，使得各個(gè)環(huán)節(jié)變得相對(duì)簡(jiǎn)單。