當前項目開發管理中的問題

第一個問題就是項目開發時間安排問題。

時間安排規劃給詳細設計文檔和編碼的時間太短，明顯的認為軟體都是借用之前版本的設計和代碼，僅僅進行一些移植工作，所以給這麼一點點時間。這樣的話，留給重構的時間實在太少，代碼太爛了，想重構，可是進度又這麼緊張，逼迫著開發人員沒有辦法只好沿用一個被修補了千百遍的老架構，而不能徹底的進行重構重寫。

 

第二個問題就是敏捷的皮毛

只學了頻繁發布的皮毛，驅趕著開發人員頻繁發版本，不給一個相對較長的時間讓開發人員進行重構。

 

第三個問題就是原始的原始程式碼控制方式

使用的原始程式碼控制工具倒是流行的SVN，但是卻沒有領略原始程式碼控制工具最基本的精神：協同工作、原始碼變更管理和分支管理等。簡直就是最原始最簡單的那種管理方式，把原始碼不斷的拷貝一份給個版本號碼放在那裡。問題1 系統各部分的代碼存放在不同的伺服器，從單一伺服器上checkout出來的代碼是不完整不能編譯的，這是個小問題，我分別把各部分checkout出來不就OK了；要命的是 問題2 開發人員只有他所負責部分所在伺服器的存取許可權，要命吧，你checkout不出其他部分的代碼；問題3，每個月只給1到2次commit代碼的機會，每次一兩天，除去這幾天，開發人員只能自行管理代碼，這TMD的哪裡是SVN啊，還不如棄用SVN使用最原始的拷貝代碼的方式得了。當然開發人員自有應對之策，自己建立個為自己或小組服務的代碼管理服務唄，這個問題倒是大大促進了部分開發人員的原始程式碼控制能力，svn、git、bazaar等五花八門的的工具使用的溜熟。（說個小竅門，若項目使用SVN，你使用非svn工具可以針對同一套代碼同時使用兩種工具）

 

第四個問題是變更管理

變更管理工具本是和原始程式碼控制工具聯合使用效果最佳的，但是公司的變更管理工具（簡單抄襲CQ自己實現的）是不能和svn關聯的。若要管理只能依靠開發人員在不同的系統上手工填寫用於聯絡的資訊，比如提交代碼時手工在comments中填寫相應的變更實施活動的細節，在變更實施活動結束時再在此手工填寫提交代碼時的svn revision號等細節。這個不是項目的問題的，是公司的問題，抄襲了皮毛，沒有抄襲組態管理工具的靈魂。人家CQ是和CC關聯的，你抄襲CQ但是卻又不能和你的svn關聯，這不是折騰人麼，為啥抄襲CQ，而不是抄襲bugzilla（可以和svn整合），bugzilla都不叫抄襲，人家是開源的，叫二次開發，你只要不賣不發布只是自用，不用太理會著作權協議，就是需要尊重協議了你害怕開源嗎？這有什麼可怕的呢，你對bugzilla的開發只能叫非語言的本地化工作，人家都不一定待見你二次開發出來的功能。

不過麼，手工能實現就手工唄，反正我的時間你付錢的（可惜的是我的時間本來可以更有用的）。項目由於存在上面說訴第三個問題，每月只能提交一兩次代碼，典型的變更管理流程是走不了了，變更實施活動的的驗證等都是在開發人員個人或小組的伺服器上進行的。等TMD的變更活動實施完了，才等到每月一次的代碼提交。不過這個嘛，有問題就有問題唄，本來部分不諳變更管理之道的人就抱怨變更管理流程，你沒有能完整實施倒正和他的心意。第三個問題都忍了，這第四個問題還有啥不能忍的。

 

第五個問題軟體項目盲目平台化

以為平台化是神器什麼的，至少是現在怨聲載道啊，產品開發備受拖延（好在我們軟體開發人員都是神仙，如此惡劣的環境還在繼續工作）。你提供了軟體平台，那我們產品部門願不願意是我們的事情。其實這裡有個很好的生態系統可供借鑒，Linux，發行版那是種類繁多啊，你開發的軟體平台代碼也只是一個產品（類比linux發行版，比如debian）的一部分，我產品願意使用你的東西那我就使用，不願意使用就不使用了唄。這就好比debian可以採用linus大神發布的的linux核心，也可以採用bsd核心,甚至hurd核心。也比如案頭，KDE和GNOME是linux發行版最常用的案頭系統，而除此之外還有xfce等等案頭存在，而ubuntu即將發布的11.04版本將採用unity shell，應該是gnome基礎上發展出來的。

有這些參照物，其實軟體平台和最終產品的關係其實很好確定，軟體平台項目交付代碼後，產品項目可以決定使用特定版本的平台代碼，然後再在該平台代碼基礎上自由修改。除非產品不願意跟隨平台升級了，產品項目一般是不會大幅修改平台代碼的。但是一定要給予產品維護小組這樣的權利：決定使用某個版本的平台代碼，決定使用平台代碼的哪些模組，對已交付的平台代碼任意修改。

可以這麼理解吧，把平台代碼暫訂位主分支，而各產品的代碼也是這個主分支上分支出來並不斷自我演化的其他分支。類似於linux發行版的發行方式。