IT項目管理的方法分享-項目管理軟件

作為一名從事應用軟件開發很多年頭的IT老兵，從個人編程、開發小軟件，到組織開發大大小小的各類應用系統，從最傳統的瀑布模型開始入門，在實踐中又接觸、使用過不少的軟件工程模型、開發過程方法、組織級成熟度模型、管理體系等等，近幾年敏捷開發又成為熱門?各種各樣的新鮮名詞和套路也是應接不暇。項目管理軟件

面對層出不窮的新生事物，回顧自己多年來的開發經歷，發現很多東西確實在不斷變化著，而有些東西其實并沒有發生根本的改變，而且各自有各自的適用場合�，F將有關的觀點歸納如下，拋磚引玉，與大家探討：

1、不變的是工程過程，變化的是管理過程。

在所有的軟件開發活動中，各種活動可以被歸為兩大類，一類是工程類活動，一類是管理類活動。這是借用了美國項目管理學會(PMI)在PMBOK中的概念。工程類活動是指那些直接制造產品的活動，這類活動是受到產品生產工藝約束的，是產品制造中的“硬邏輯”，最典型的就是蓋樓必須先打地基。管理類活動則是指其他那些輔助性活動，是用來保障工程類活動高效實施的，可以根據各方面因素的實際條件而靈活掌握的，是生產過程當中的“軟邏輯”，比如施工工期和資源如何安排、是三人干兩個月還是兩人干三個月等等。      

按照類似的概念，在軟件開發當中也存在著這樣兩種不同的活動——具有硬邏輯特征的軟件工程活動和具有軟邏輯特征的軟件開發管理活動。仔細推敲就會發現，雖然現在各種開發方法名目繁多，但其核心的工程過程并沒有發生變化——就是最基本的瀑布式軟件工程過程。

2、需求、設計、編碼、測試、發布。

無論是那種開發方法，無論開發的是大型軟件還是一個小功能，無論開發項目組人數多與少，上述這個過程都是始終有效的，這個就是應用軟件開發中的“硬邏輯”。但是，圍繞這樣一個工程過程，在具體實施過程的管理方式上，卻可以是千差萬別：

A、按照上述這個工程過程，一步一個腳印的穩步前行，就是常說的“瀑布式”方法(瀑布式工程過程并不等同于瀑布式管理過程，不能混為一談，必須加以區分);項目管理軟件

B、先根據粗略的需求快速實現一個原型系統，然后在此基礎上進一步導出正式的需求，再嚴格按照上述的工程過程實現，就是所謂的“原型法”;

C、將整體需求分成許多個部分，反復使用上述工程過程，每一次只實現一部分目標功能，使之能夠快速投入使用，從而形成“快速迭代”;

D、在互聯網速度的推動下，進一步細分需求，并極力促成技術、業務等相關人員的密切溝通，進一步加速迭代，縮短開發周期，大幅提升應用開發的響應速度，這就是“敏捷”;

因此，縱觀這些年來軟件開發方法的變化，軟件產品的制造工藝并沒有發生根本性改變，更多的變化則是在制造過程的組織管理方式上不斷尋求新的出路，以適應不斷提高的快速響應的要求。

既然不同的是管理方式，那么不同的開發管理模式下，開發過程的組織方式自然也就應該有所不同。如果采用傳統的瀑布式開發管理過程，那么軟件工廠的管理方式可能較為合適，而如果采用敏捷方法，那么軟件工作室的組織方式也許更適應(請參見《軟件工廠、軟件作坊、軟件工作室》一文)。

這里順便說一下對CMMI的看法。作為一個組織級的、系統化的模型，是許多專家的經驗教訓的結晶，具有非常高的參加價值。在這個模型中試圖把各方面相關工作的實質、必須的關鍵點都識別出來并建立起有機的聯系。但是它并沒有給出在某個實際環境中的具體操作要求，這是實施者需要解決的問題。有些企業實施CMMI之后叫苦不迭，我認為問題不是出在CMMI本身，而是出在實施環節，沒有能夠掌握CMMI的實質，沒有能夠結合實際條件活學活用，很多情況下是在操作層面上機械照搬了別人的“成功模板”，結果削足適履，這樣結果當然會難受。我認為的正確姿勢是，把CMMI模型的內容看做組織級能力中的“硬邏輯”，然后根據自身條件的實際情況，設計相應的“軟邏輯”，因地制宜制定各種制度流程，來推動那些“硬邏輯”的實現。在這些軟邏輯當中，前面提及的各種管理方式都是可以根據實際需要而采用的。

從這個角度來說，與其從敏捷出發考慮如何解決組織級“大敏捷”的問題，不如考慮在類似CMMI的組織級模型中如何運用“敏捷”的管理思路和管理方法，也許會有意想不到的收獲。

無論是“傳統”的瀑布方法，還是“現代”的敏捷方法，目標只有一個，就是以最優的效率完成軟件開發任務。沒有必要為了敏捷而敏捷，而是應該掌握敏捷的思想、方法、技巧，活學活用。基于上述這樣的認識，不同的軟件開發管理方法，都有各自的特點和適用場景，并非存在絕對的優劣。作為軟件開發的管理者，在具體的軟件開發項目中，始終牢牢抓住軟件工程過程的基本規律，結合實際條件，靈活運用不同的管理方式。