工作了幾年也參加了多個專案開發，經歷了好幾種的開發模式；有傳統的瀑布式，有螺旋式，有迭代式等等開發模式。最近在研究敏捷開發裡的xp開發模式並針對這幾年的專案開發總結出專案管理的四個持續：持續整合、持續測試、持續重構和持續溝通。
一、 持續整合
持續整合是xp裡面的概念，在此我不想將xp裡面的copy出來，要是這樣的話就浪費讀者的時間了，要是想看的話可以到google上go下。這裡我就用我的觀點來闡述下持續整合。
持續整合就會使你的專案持續的走向成功，持續遠離風險。
二、 持續測試
持續測試和持續整合差不多，也是一直測試、不間斷的測試，也是要「自動測試」。程式的每次更新都要自動執行所有測試用例（也叫回歸測試），將執行測試用例的結果用mail形式或其他形式自動的發給專案組成員。目的在於讓組員對更新**的正確性充滿信心，而不用擔心更新的**會不會對原來**產生什麼影響，當然了前題是你要有寫測試用例。
編寫測試用例少不了工具，有junit、dunit等。但是這些工具要嵌入到你的專案開發工具裡，並且要有測試用例的模板如：專案工程測試用例模板、單元測試用例模板，不能寫個測試用例從頭開始吧。
三、 持續重構
持續重構就是持續的對你或組員裡的**進行調整從而改善軟體的質量、效能，提高軟體的擴充套件性和維護性。為什麼要重構呢？因為要知道乙個完美得可以預見未來任何變化的設計，或乙個靈活得可以容納任何擴充套件的設計是不存在的，現在是乙個高速發展的社會，計畫是永遠趕不上變化的。
需求變更是我們要持續重構的原因。乙個軟體總是為解決某種特定的需求而產生，時代在發展，客戶的業務也在發生變化。有的需求相對穩定一些，有的需求變化的比較劇烈，還有的需求已經消失了，或者轉化成了別的需求。在這種情況下，軟體必須相應的改變。有一本四個老外寫的《設計模式》書，是經典中的經典（作者認為）。寫到這裡讓我想起了以前給程式設計師培訓設計模式說的一句話：
設計模式可以讓你的生活更美好、身體更健康，是程式設計師的必備「良藥」。
四、 持續溝通
溝通是現在所有軟體公司一直提倡，是的，乙個專案沒有溝通的話，後果「外星人」都知道。而我這裡的持續溝通不僅僅是軟體工程裡面講的客戶溝通、組員溝通等等，而是持續溝通。中國的很多軟體企業都存在這樣的一種情況就是專案經理不能確切的知道專案的進度和組員的工作情況，持續溝通就是為了解決這種情況。持續溝通是每天、每週、每月直到專案驗收為至的溝通會議。（以下是對敏捷方法的scrum開發模式進行更詳細的闡述）
．每天用10~15分鐘時間對昨天工作完成情況及今天工作內容進行組員的交流，提出相關問題；
．每週用30~60分鐘時間審核專案計畫及進度，討論專案的任務及相關問題；
．每月用1~2個小時來跟蹤專案是否按原定的目標進度，使每個組員都了解整體專案的進展情況，討論下個月（因為一般來說將乙個月作為乙個週期）專案程序。
這些溝通會議要以文件的形式放入配置庫，以便以後查閱。
持續溝通也可以作為績效管理的一種依據。
上面寫的幾種技術我也會陸陸續續的寫在我的blog上的，如：《用finalbuilder來構造「自動整合」》（作者是用delphi），《將dunit嵌入delphi中並如何設定測試用例模板》，《我對設計模式的一些看法》等等。
花了我乙個晚上的時間終於把這編看是管理又不像管理的文章寫完了。這裡要感謝下我的同學linxin，是他叫我寫點東西的。他的blog:
linxin.csai.cn。
軟體專案管理（四）
對於軟體專案估算來說 估算不是很準確，有誤差 不要太迷信某些數學模型 專案經驗資料非常重要 軟體專案成本由軟體專案規模決定，軟體專案規模即工作量，一般的單位有loc lines of code有效 行數 fp function point系統功能數量 人月 人天 人年 軟體專案成本包括 完成軟體規模...
工作中任務管理的四個原則和四個技能
這是前一陣給團隊培訓，提高團隊工作績效時寫的。四個原則 l 瓶頸性任務最優先解決原則 l 高不確定性的任務優先解決原則 l 前置性原則 l 複雜多變任務的處理原則 比如說，上面這個任務分解，b c f這條線是瓶頸線。是最優先解決的線。滿足下列兩條之一的任務是高不確定性任務 困難的 沒有實現方案的 無...
研發管理的基礎 四個重組
這篇文章是一本非常好書籍 產品研發管理 的讀書筆記，書籍作者是周輝 曾任華為專案管理部總經理 億陽信通coo 青牛軟體ceo 是關於ipd整合研發管理的一本佳作，本人拜讀多次，看到書中滿滿的精華，每次都有新的收穫。為了使瞬間的感悟得以保留，特記錄筆記備查。這本書非常好的一點，是在每一章開頭都會有 本...