項目管理作為一門獨立的學科，已經發展了很多年，并為實踐提供了豐富的理論依據。而軟件開發的項目管理，雖然也屬于傳統項目管理的范疇，但是由于軟件工業本身的特點，很多在傳統項目管理理論中被證明行之有效的理論和方法，拿到軟件開發的項目實踐中卻常常達不到預期的效果。軟件開發的項目管理與傳統項目管理的這種差異究竟在哪里呢？這個問題已經有很多人在研究并成果豐富，一致的結論性的原因就是：軟件開發中的項目管理本質是人的管理。
 
　　人作為項目管理的主要素主導著整個項目的成功和失敗，所以對于軟件項目開發管理者來說，需要引起足夠重視的一點就是要重視人——在軟件開發中，這將主導技術、效率、質量。
 
　　本文內容上沒有闡述敏捷項目管理與普通項目管理的區別，也沒有完全按照計劃——分工——執行三個環節來論述，更多的是作者隨想隨寫的一些經驗之談。軟件的項目管理也是整個軟件工業沒有“銀彈”的一個重要方面，很多時候，經驗比理論占據更重要的地位。文中的很多內容對于有實際項目管理經驗的同行來說，可能能夠產生一些共鳴，如果這樣，本文就起到總結經驗的作用。對于那些尚未有取得這些經驗的同行來講，本文中的實際案例和場景可以幫助增進這些讀者的感性認識。
 
第2部分   讓人的資源多起來
 
軟件項目開發的核心資源就是人，在一定的項目規模和資本規模下，人的資源是受限的。項目中考慮人的資源常常以人數來計，但是實際中我們都清楚，工作量是以任務來分解和總和的。這就說明人和任務之間存在一個關系，這個關系就是角色。
 
1.1. 角色（Role）
　　角色是對工作任務的職責抽象，與具體的職位有著區別。一般情況下，角色和職位是多對一的關系。敏捷風格的項目管理認為在產品（軟件）開發過程中，成員所承擔的角色雖然有其固定的一面，但是可以賦予它更多變化來改變工作的分配模式。舉例來說，A的職位是項目經理，但是同時也是優秀的設計師，那么，可以認為A承擔了項目經理和設計師兩個角色。
 
　　在軟件開發管理中，角色其實非常豐富。常見的角色如：項目經理、需求分析師、系統設計師、開發工程師、測試工程師。對于大型項目，比如基于J2EE的項目，根據實際項目中的技能需求，需要各種類似專家的角色，比如人機界面工程師，部署工程師，配置管理員，DBA等。
 
　　敏捷的項目管理中要求角色不是固定的，一人可以擔任多個角色，這樣才可以充分利用已有的資源。如同電網的電力資源一樣，資源的存在和分布有時是難以改變的，但是其是否充分利用依賴如何調度。
 
　　角色是項目中任務的具體承擔對象，從角色角度而不是職位角度考慮資源的分配，有利于合理分工，保持資源的平衡。對于存在多個項目并行工作的情況，這一點非常有意義。我們知道，一個公司的DBA不會太多，多個項目并行工作的時候，可能各個項目都需要DBA的協助，但是從人員編制上，DBA可能僅隸屬于某個具體的項目組。這個時候如何解決資源的分配呢？同樣，優秀的架構師對于整個公司來說也會是稀缺資源，我們如何讓這些稀缺資源發揮更大的作用呢？當然，可以考慮從人力資源編制上解決這個問題，比如成立獨立于跨項目組的專門的架構師組，總體設計組等。但是，實際情況往往是人力資源制度的改革步伐永遠會遠遠落后于實際需要。況且，從資源模型本身來看，資源本質上是與角色捆綁的而不是與職位捆綁的。
 
　　從管理的角度，我們希望資源可以最佳利用。繞過人力資源編制，實際上可以采取特殊的運作模式來達到這一目的。方法就是，賦于比職位多得多的角色，讓人具備多個可分配的單位。在這一點可以用CPU的多線程來比喻。
 
案例：
 
　　2001年的時候，公司有Milkyway和Apollo兩個項目在同時運行，兩個項目都是電子政務項目，采用J2EE技術實現。當時公司是首次接手電子政務項目，對于Web頁面所需要的大量美工雖有考慮，但是最終只招聘到一個合適人選。在Milkyway項目組中，大家都知道開發人員Alen喜好攝影，其實是一個圖形制作愛好者，Photoshop高手。當美工資源已經成為事實上的開發瓶頸時，我給領導提出了一個建議：是否可以讓Alen也充當美工角色呢？可以在開發任務上為Alen消減一半，讓他有另一半的時間去讓我們的工作產品漂亮起來。后來跟Alen商量讓他兼美工這一角色，他愉快地答應了。我想，對于一個圖形制作愛好者來說，還有什么工作比干自己喜歡的事情更愉快呢！
 
1.2. 虛擬團隊(Virtual Team)
　　虛擬是相對現實而言。虛擬團隊一經發明，已經在互聯網上廣泛流傳。所謂虛擬團隊，是指沒有實際的組織形態，但是有具體的任務目標；團隊成員雖然來自各方，但是為著共同的任務目標而進行工作。

　　虛擬團隊和實際團隊比較，優勢在于：組建靈活，反應快捷。
 
　　實際的團隊往往根據長遠的任務目標而設立，一經設立，成員即往往有了固定的身份。比如，項目組往往根據產品模塊的任務目標而設立，一般來說在項目的生命周期中會一直存在下去。但是實際的項目工作開展過程中，一方面存在很多跨項目組的工作要做，另一方面存在很多短期的任務需要調度資源完成，這個時候固定的團隊就難以勝任工作任務的分配。
 
　　虛擬團隊本質上是根據任務對資源的臨時性組建。前面我們已經通過角色把資源獨立化了，現在通過虛擬團隊，我們可以把獨立的資源再通過任務目標而集中起來。
 
案例：
 
　　在上面談到的Milkyway和Apollo兩個項目案例中，當Milkyway項目推進到開發完成60%的時候，系統的基礎框架已經基本可以在瀏覽器中看到。這個時候，架構師發現系統的響應很不理想，這個發現其實并不出乎意外。盡管公司是首次接手基于Web的項目，根據多年的經驗還是預測到了可能存在的性能瓶頸。目前的任務就是需要立即組織部分專家來診斷性能瓶頸的準確所在，并敦促項目組成員調整代碼。可是面臨的問題是公司的測試工程師并不熟悉基于Web項目的性能測試，如何尋著額外的資源呢？另外，還有一個問題，性能問題來源于架構和代碼，需要對系統結構和代碼最熟悉的系統設計師和開發人員參與才行。這個時候Apollo項目正進入詳細編碼開始階段，根據任務分配情況，管理層覺得部分設計師可以抽調部分時間來參與Milkyway項目的性能優化。為此，成立了Milkyway項目性能優化虛擬團隊。
 
Milkyway性能優化虛擬團隊
 
組成成員：
 
1.所有Milkyway項目的開發成員和設計師
 
2.Apollo項目組的Wiki和Polo（兩位經驗豐富的設計師）
 
負責人：
 
Wiki擔任負責人和組織者。
 
目標：
 
全方位優化Milkyway的性能，達到客戶認可的各項系統響應時間指標
 
任務：
 
1.一周內給出Milkyway項目的性能測試報告和性能優化具體指標
 
2.三周內給出一期優化分析報告
 
3.持續跟蹤性能，從第四周起，每兩周給出性能測試報告
 
執行：
 
1.Milkyway的所有成員需要配合Wiki的組織工作，并接受安排的合理任務
 
2.Milkyway項目經理Cobo協助Wiki安排工作
 
3.測試部經理Anny，配合Wiki安排測試設備和數據準備。