隨談項目管理之傳統和敏捷項目管理

　　隨着計算機、互聯網的興起，軟件研發行業的項目管理變得愈來愈重要。咱們在工做的過程當中，特別是初融合的團隊，會發如今項目研發過程當中出現各類問題，這個時候，項目管理就會被天然而然地須要。

　　項目管理是有多多種模式的，主要分爲傳統式項目管理和敏捷項目管理，而每一個項目管理模式中還有不一樣的項目管理框架。

在工做過程當中，對不一樣的模式不一樣的框架，老是看不到總體的全面的東西，非常疑惑。在工做的同時，也去找了一些參考資料對各個模式的項目管理框架進行比較，現作一個總結。因爲我本人是從事軟件開發類，因此談論的角度均是站在軟件開發的角度展開。

 

1、各個項目管理模式的認識和理解

一、PMP：傳統型

有項目經理

PMP的框架是基於知識點出發的，它的知識框架基本能夠覆蓋全部的領域，便是其框架是綜合和通用的，而不是徹底的軟件開發項目管理，因此咱們常常也會發如今工程領域的PMP框架運用，如：建築工程類、硬件類、軟件開發類等等。

傳統型的項目管理模式，分爲五大階段，十一個領域。

五大階段分別爲：啓動、規劃、執行、監控、收尾

十一個過程領域：範圍管理、時間管理、質量管理、成本管理，（多快好省），人力資源管理、干係人管理、採購管理等。

每一個階段和過程領域都會有必定的概念介紹、輸入輸出內容、工具，提供給項目人員進行合理運用。

好比大家公司是純軟件類公司，且所作的軟件/app等是自營的，無須與客戶糾纏成本，那麼你的重點要在需求範圍、進度管控、質量交付等其餘領域，而不須要過分關注直接成本，你管控的進度、時間已經間接地管控了成本。

在PMP中，項目經理的做用，便是五個階段的控制者、領導者，同時也是須要對結果負責的。

 

 

二、SCRUM:

在scrum中是項目經理的這一角色的，可是有scrum master.

Scrum的目標是可以使開發過程可以及時審視，更加透明，並達到持續開發。

Scrum 的核心是sprint，每一個sprint即爲一個迭代，或者一個類似工做的重複週期，爲產品或系統產出增量。同一個產品的每一個sprint週期是固定的。

基於sprint，咱們制定product backlog，即待辦事項列表，根據產品的不一樣，咱們能夠定製不一樣形式的backlog。核心目標是相同的，即明確目標、檢查任務完成及時度，審視過程當中存在的問題。

SCRUM的敏捷性在於，每個sprint都是連續性的，在每一個sprint的時間窗內，都會有15%的時間來制定sprint計劃，而且每相鄰的sprint之間沒有時間間隔，即開發是連續性的，上一個sprint結束以後當即啓動下一個sprint。

Scrum的團隊在這裏不作多的描述，主要說明一下Scrum Master的職責。

 Scrum master 的職責：

一、並非項目經理、IT經理的角色，是一個服務型的指引人。

二、負責scrum流程，使其正確使用並達到最大的效果。

三、根據sprint的執行狀況，組織回顧會議，整個團隊討論剛剛完成的sprint能夠作哪些優化使得下一個sprint更有效率

 

 

三、IPD（Integrated Product Development）集成產品開發：

如今在實行和推廣的公司有：華爲、海康、大華、聯想、長虹、美的、步步高等。大華和海康推行得不是特別完全，主要是由於每一個項目管理模式的選取與實施和自身的產品性質有關。

我的認爲IPD比較適合軟硬件結合或純硬件的產品，因爲接觸很少，不作過多的闡述和我的意見發表。

若是之後工做有須要接觸此項目管理模式，能夠深刻研究學習。目前不作研究。

 

 

2、對敏捷項目管理的理解（敏捷的理解內容部分比較少）

　　對於互聯網行業來講，行業發展速度比較快，傳統的項目管理模式已經再也不適用。

　　就拿健身app來講吧，隨着健身觀念的普及，愈來愈多的大衆投入到健身的隊伍中，可是咱們會發現，有一大部分人都是未健身成功的。緣由就在於他們沒有合理的健身觀念，標準的健身動做，而請私教又是一大筆錢，不少人不會捨得投入這麼多錢到健身私教中去。這個時候，咱們只要抓住了用戶的需求點，健身app就能夠應時而生。產品經理規劃了不少東西，戶外跑步記錄、大卡計算、跑步機跑步記錄、動做教程、網上私教等等，若是按照傳統的項目管理模式，那麼咱們要全部的需求整理出來，再有整套系統的設計文檔，評審，開發等等，等一個整的app作好以後，其餘家看好這個契機的產品早就已經進入市場，吸引流量了，若是再有一些產品亮點，經過用戶與用戶之間的傳播，那你作出來的產品基本上就沒什麼機會了，很大狀況就成爲了炮灰。

　　由此看來，在互聯網行業，敏捷項目管理是很是重要的。可是純敏捷，對團隊的自管理要求比較高。爲何這麼說呢？一個項目團隊實施純敏捷，以需求的迭代爲核心，更多地關注在需求、進度上，而容易忽視掉技術上或者其餘方面的一些細節，這對初造成的團隊或者新加入的員工就是不太友好的。

　　在接觸項目管理這麼多時間以來，我在工做中接觸更多的是結合了傳統項目管理和敏捷項目管理的模式，一般是將

　　項目管理也是過程的優化，咱們不斷地發現項目中的問題，不斷地根項目所處的狀況調整本身的項目管理模式。

　　其實傳統的項目管理與敏捷項目管理各有優點，在使用的過程當中選取適合本身項目的內容來使用便可。

 

 

3、對現有軟件項目管理的理解

如今咱們來談談站在項目管理角度看，如何使用各個項目管理模版？

1）商業型項目：

     每一個項目都會談價錢，那這個時候就須要更強地控制成本、需求，這個時候，項目經理的做用就會比較明顯，要直接對項目結果負責，包括成本、質量、需求是否按要求完成等等。那麼這裏咱們在起初的時候須要用到傳統型項目，對每一個節點嚴格把控，各個節點進行評審，儘早讓需求方參與項目以及時調整項目的完成方向（固然變動需求除外，變動需求仍是要從新評估的），這裏說的及時調整項目的完成方向是指，咱們在研發過程當中，或多或少會對需求有誤解讀，讓需求方儘早參與能夠起到及時矯正的效果。

　　固然，爲了保證項目的質量，也能夠結合敏捷一塊兒使用，迭代性交付。

2）自研發型項目或：

　　不與外部公司計算項目的價格，作出的產品提供給本身的公司、部門使用，或不受外部需求方的需求時間限制，產品目標即軟件的商業目標。這個時候咱們更重要的是讓整個團隊的目標更加一致，無論怎麼說，提升團隊的凝聚力對團隊都是一種支撐力量。

這種可以本身控制和規劃產品的需求的產品，更多的時候是不須要項目經理的，項目管理的職責由產品經理或研發經理擔任便可。那麼這個時候的敏捷就派上了用場，咱們制定好必定的技術規範、項目管理規範，經過不斷地優化需求溝通，發現項目中的問題、解決問題，經過不斷地優化項目過程便可。

3）結合型項目：

　　有業務方壓時間，也有自研發產品。這種產品咱們在排計劃的時候就須要根據優先級來進行執行。

 

 

　　以上爲我的拙見，歡迎各位項目管理人士指導。