工作了幾年也參加了多個項目開發，經歷了好幾種的開發模式；有傳統的瀑布式，有螺旋式，有迭代式等等開發模式。最近在研究敏捷開發裏的XP開發模式並針對這幾年的項目開發總結出項目管理的四個持續：持續集成、持續測試、持續重構和持續溝通。
一、 持續集成
持續集成是XP裏面的概念，在此我不想將XP裏面的Copy出來，要是這樣的話就浪費讀者的時間了，要是想看的話可以到google上go下。這裏我就用我的觀點來闡述下持續集成。
持續集成，顧名思義就是一直集成、不間斷的集成，一天可能要集成上十次甚至更多，或者說，只要有組員更新代碼就要集成。目的就是項目組的成員能很快的知道項目變化。但是你可能會說，這樣做不是很浪費時間嗎？那是你用手工來做，而必須做到輸入一個命令，或者點一下鼠標就能完成代碼下載、集成和編譯過程，並且編譯結果不能出現任何錯誤和警告。此時，你可能就想到“自動集成”，沒錯，你可以設定每天的某個時間；像我就是每天7點半自動開機，開機後進行“自動集成”。網上有好幾種工具，如：Java的Ant, MS平臺的FinalBuilder等等。
持續集成就會使你的項目持續的走向成功，持續遠離風險。
二、 持續測試
持續測試和持續集成差不多，也是一直測試、不間斷的測試，也是要“自動測試”。程序的每次更新都要自動運行所有測試用例（也叫回歸測試），將運行測試用例的結果用Mail形式或其他形式自動的發給項目組成員。目的在於讓組員對更新代碼的正確性充滿信心，而不用擔心更新的代碼會不會對原來代碼產生什麼影響，當然了前題是你要有寫測試用例。
編寫測試用例少不了工具，有JUnit、DUnit等。但是這些工具要嵌入到你的項目開發工具裏，並且要有測試用例的模板如：項目工程測試用例模板、單元測試用例模板，不能寫個測試用例從頭開始吧。
三、 持續重構
持續重構就是持續的對你或組員裏的代碼進行調整從而改善軟件的質量、性能，提高軟件的擴展性和維護性。爲什麼要重構呢？因爲要知道一個完美得可以預見未來任何變化的設計，或一個靈活得可以容納任何擴展的設計是不存在的，現在是一個高速發展的社會，計劃是永遠趕不上變化的。
需求變更是我們要持續重構的原因。一個軟件總是爲解決某種特定的需求而產生，時代在發展，客戶的業務也在發生變化。有的需求相對穩定一些，有的需求變化的比較劇烈，還有的需求已經消失了，或者轉化成了別的需求。在這種情況下，軟件必須相應的改變。有一本四個老外寫的《設計模式》書，是經典中的經典（作者認爲）。寫到這裏讓我想起了以前給程序員培訓設計模式說的一句話：設計模式可以讓你的生活更美好、身體更健康，是程序員的必備“良藥”。
四、 持續溝通
溝通是現在所有軟件公司一直提倡，是的，一個項目沒有溝通的話，後果“外星人”都知道。而我這裏的持續溝通不僅僅是軟件工程裏面講的客戶溝通、組員溝通等等，而是持續溝通。中國的很多軟件企業都存在這樣的一種情況就是項目經理不能確切的知道項目的進度和組員的工作情況，持續溝通就是爲了解決這種情況。持續溝通是每天、每週、每月直到項目驗收爲至的溝通會議。（以下是對敏捷方法的Scrum開發模式進行更詳細的闡述）
．每天用10~15分鐘時間對昨天工作完成情況及今天工作內容進行組員的交流，提出相關問題；
．每週用30~60分鐘時間審覈項目計劃及進度，討論項目的任務及相關問題；
．每月用1~2個小時來跟蹤項目是否按原定的目標進度，使每個組員都瞭解整體項目的進展情況，討論下個月（因爲一般來說將一個月作爲一個週期）項目進程。
這些溝通會議要以文檔的形式放入配置庫，以便以後查閱。
持續溝通也可以作爲績效管理的一種依據。
上面寫的幾種技術我也會陸陸續續的寫在我的Blog上的，如：《用FinalBuilder來構造“自動集成”》（作者是用delphi），《將DUnit嵌入Delphi中並如何設置測試用例模板》，《我對設計模式的一些看法》等等。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/Oer/archive/2006/09/04/1175236.aspx