如何把握中大型軟體開發流程？

11-26

我即將要重寫一組工程（Delphi代碼總量60萬左右），重寫的過程中要做到兩點：一是做到很多我設想的功能優化、類設計優化；二是要實現從Delphi語言到C++語言(用Qt做界面)的轉換。
但是目前我還沒有過做這種中大型項目主負責人的經歷，不知道怎樣才能把控好整個開發過程。因此想請教各位有什麼好的方法來保證項目的成功。
具體到措施上來說，一方面我們公司內部提倡用敏捷開發，藉助迭代開發來降低風險。我也打算用迭代的形式來交付成果。另一方面我又想制訂出UML圖來指導具體的開發過程。
謝謝各位！

補充：
1. 人員上來說與開發人員有兩個（算上我自己）

2. 時間上來說，主管未做要求，我個人想法是一年內做成。

3. 代碼現狀是代碼重複現象很嚴重，維護舊工具往往要修改多處已不耐其煩。業務知識和後台數據結構可以說完全了解，工具中沒有過於複雜的技術，在維護過程中基本沒遇到過看不懂的地方。代碼沒有完全看過，有大概一年半的開發和維護經歷。

4. 部門經理等人對項目的語言切換不贊成，也不反對，所以加人手之類的不可能，他們也不會檢查進度。我和主管之所以做這個是考慮到公司轉換語言的大環境下組內不切換語言將來對開發人員不利，另外工具中的問題太多（代碼重複之類的）也想藉機重新整理下工程的結構。

5. 看到有人說要用工具自動翻譯，這方面我最初的想法是基本重新構造，在做具體的功能的時候再參照原來的代碼翻譯。也歡迎大家分析利弊。

敏捷迭代開發顯然是最佳選擇，何況還是一個非正式的2-3人年項目。

建議你先把Product Vision、Development Plan、Project Management Plan等文檔草案寫出來，做到規劃在先、心中有數，網友也好參與評論。

選擇合適的項目管理和開發方法論很關鍵。敏捷開發方法有許多流派，純Scrum+XP估計不適合你們兩人吧，建議參考下AUP和Taij/BP。

//但是目前我還沒有過做這種中大型項目主負責人的經歷，不知道怎樣才能把控好整個開發過程。因此想請教各位有什麼好的方法來保證項目的成功。具體到措施上來說，一方面我們公司內部提倡用敏捷開發，藉助迭代開發來降低風險。我也打算用迭代的形式來交付成果。

這種項目本身還是有一定難度的，其中最大的難點還是由於需要重寫，那麼就需要在重寫下掌握所有原有的代碼實現邏輯和底層數據模型結構，最大的還原原有的需求，才談得上進一步的功能優化和類優化，其中要注意的關鍵點在於。

1. 好好研究原來的資料庫設計和數據表結構，表和表之間的關係，每一個數據表的每一個欄位屬性的含義和起到的作用。前台的每一個功能點要列成詳細的功能清單，每一個功能點對於後台資料庫包括欄位的CRUD影響都要分析清楚，確保沒有遺漏。

2.詳細的Review原來Delphi程序的所有代碼，要知道第一步分析是容易遺留大量的業務規則和處理邏輯的，因此在第二步的重點就是造成代碼裡面的業務規則和邏輯，把這些也全部羅列清楚，每一個邏輯點的實現描述清楚。

3.根據第一步和第二步完成的內容，開始整體總體架構設計文檔，注意這一步不能去迭代，總體架構設計文檔的重點還是在於底層的資料庫設計的完整性，上層核心類邏輯模型的完整性和優化。這一步做完後應該新的應用的組件劃分，介面識別，復用識別應該全部搞清楚。

4.最後一步即到了真正的重寫和實現階段，有了前面的基礎你會發現所有的需求都可以列成詳細的features功能點，這些需求功能點清單即可作為敏捷開發中的product backlog，再根據迭代周期的安排來劃分為spint backlog和詳細的迭代版本計劃。前面真正把控好了到這一步基本不會再出大的方向性的問題。

再次說明下類似這種項目的成功關鍵還是在於技術和架構把控能力，其次才是項目管理能力。

之前參加過IBM的培訓，講師講到複雜項目的定義，不在乎項目是大是小，凡是項目經理看不清楚的項目，都是複雜項目
你這個就是典型的複雜項目

你的描述還是比較概略的，這樣很難提出具體的建議
結合我的經驗，只能給出一些問題
那麼問題來了
第一層
你對這個項目的業務有個整體的把握了嗎？
有完整的業務流程圖嗎（脫離的技術實現的）？
業務流程中每個環節是怎麼劃分的，環節與環節之間對接是怎麼樣的（圖示，結合數字）？
每個業務環節的詳情是怎麼樣的（圖示，結合數字）？
對每個業務環節有性能要求嗎（精確到數字）？

第二層
整體業務實現要用到哪些技術？
在生產環境、開發環境分別需要部署什麼樣的一套配置（硬體，軟體）可以支撐起整個業務？
根據業務流程、環節劃分、性能要求以及技術實現，在技術上怎麼劃分模塊（大致等同於概要設計）？
模塊之間怎麼通信？
模塊內部怎麼設計（大致等同於詳細設計）？

做到這個程度，基本上開發計劃可以定了，開發任務已經可以出backlog了。
需要注意的是模塊內部設計這個部分，如果經驗很豐富，對於各個模塊內部實現有把握，可以不用一次都做完，需要開工哪個模塊就開始做設計。
相反如果對於某個模塊沒有足夠的把握，最好先期設計做細一點。一般說起來，項目延期大部分是因為開發人員認為事情很有把握，但是實際做的時候發現跟自己想像的不一樣所致，相信很多開發人員都有這種經歷的哈哈哈哈

進入到開發階段
要點就跟隨敏捷的要求就行，比如
每個迭代產出一個可以使用的東西，在迭代開始之前就計劃好的要做什麼
拆任務拆到2人日以下
迭代啟動會集體估時和認領任務
等等等等

這是一個跨語言的重構項目，項目只有兩個人，我覺得倒不涉及過多的項目管理的內容。更多的是看你如何把有效地把握重構過程。

能不能夠尋找到原有delphi系統中的物理模塊邊界？從一兩個與外界耦合較少的模塊開始，C++重寫後與其它原有系統同時運行。如果沒有，推薦先重構原有系統，劃分物理邊界。
在重寫過程中不要過早考慮體系結構的優化問題，風險太大。
強烈推薦重寫過程中使用TDD方式，逐步補充測試用例，以便後期針對體系結構時行重構。
還應該考慮到過度期中，原則系統的業務變更需求。所以應該自底向上地進行重構，與業務需求最緊密的部分最後動。

第一，Delphi 到Qt ，這不叫重構了，應該叫重寫。第二，把「優化」放到最後，先保證功能正常。第三，測試驅動，通過完備的測試用例保證功能正常；第四，原來的代碼質量如何，MVC三個層次清晰嗎？純界面的工作能否分開同時進行？第四，老闆給的時間夠用嗎？要不要爭取更寬鬆的期限？第五，團隊成員的水平如何？能做到合理分配任務嗎？

暫時想到這麼多，僅供參考。

60萬行代碼換種語言重寫，直覺是不要開展這樣的項目！

除非你有把握把這60萬行代碼縮減到6萬行。

如果沒看到代碼大幅度縮減的可能。假設一天的生產率是300行代碼，一年260個工作日，僅僅是把代碼敲出來，兩個人也需要約4年時間。考慮到測試和bugfix，估計要6年時間。考慮還有不少缺陷要產品上線後才能發現，要達到和老版本相同穩定程度，花費的時間會更長。這六年裡面，還會出現新需求，新老兩套班子需要同時工作。更要命的是，你不知道6年後這個產品還有沒有存在的價值。

不過既然題主說是delphi寫的代碼，作為那個時代過來的人，直覺是這60萬行代碼存在縮減為6萬行的可能。那個時代市面上輪子少，每個產品都在自己造輪子。比如我們十多年前做通信產品，從操作系統一直做到應用層協議棧，自己去實現現在linux下唾手可得的各種工具，放到現在，可以直接用現成的OS替代了。所以我的建議是：

最理想的情況，能否用目前現成的軟體加上一些數據配置來實現？
次理想的情況，能否分離出原軟體中的非業務特定功能，用今天的現成軟體來實現？然後只寫業務特定的代碼。

如果題主維護的是信息系統，命中選項一的可能性相當大；如果維護的是比較小眾的領域，選項二的可能性很大。另外，為題主的職業前途考慮，也為公司尋找後續維護人員考慮，如果存在可以使用java或者腳本語言的可能，堅決拋棄c++。

說簡單點，做個翻譯詞典的工具。通過該工具直接把所有代碼先簡單轉換。有錯無所謂，然後一行行校對修改。可以寫個簡單基盤實現許多語言差異導致的功能。目的就是一行代碼對應一行代碼。
不要考慮原來功能。同樣數據跑，走出來一樣效果就ok。測試分支多一點。
一個個類去分析再實現再測試，效率極其低下。而且你能保證你分析肯定不會出錯？