項目管理

在尋找項目管理軟件以前，應該先明確一下咱們的目的，但願軟件可以帶給咱們什麼價值，價值來源於需求，那麼咱們的需求是什麼呢？需求簡單來講，就是但願一款軟件可以幫助咱們進行管理性工做，如今的項目管理工做其實分爲「項目管理」、「敏捷項目管理」這兩種方式，這兩種管理方式雖然在管理流程存在差別，但目標是一致的，都是讓項目儘量的實現商業價值。咱們的項目適用於以上哪一種方法，這個須要按照項目的特性、以及團隊的水平來肯定。

「項目管理」是一種預測型的管理方式，它提倡在項目開始前，儘量的預測並計劃咱們要作的每一件事情，好比：

1） 預測一個商業問題能夠轉化爲機會；

2） 預測咱們設計的項目範圍可以抓住商業機會；

3） 預測咱們須要在3個月內交付項目才能取得較大的商業價值；

4） 預測咱們依照指定的質量政策纔可以知足質量要求；

5） 預測咱們須要10個開發人員才能保質保量的交付；

6） 預測咱們可能遇到風險有哪些、預測完成這個項目須要500萬人民幣。

以上的預測，是對範圍、時間、質量、資源、風險、成本這幾個因素的預測，它們相互制約着，而且最終影響到客戶的滿意度，如圖：

 

相互制約的例子：

1） 小張原本一週內只能完成10個功能，但由於項目急，開發時間短，如今須要小張在1周內完成15個功能，小張加班加點，勉強完工，雖然進度是遇上了，但質量可能會出現問題。這是時間、範圍、質量之間的制約。

2） 而後仍是小張，小張在一週內可以完成10個功能，這個速度沒法使咱們按時交付項目，因此咱們決定增長一個開發人員老王，若是老王加入後，團隊每週能夠完成25個功能，這樣能夠達到項目的進度要求，可是受限於成本緣由，咱們請不起老王，那老王就來不了了。這就是資源、時間、成本之間的制約。

3） 老王一我的獨立開發項目，開發過程當中發現某個功能的實際開發工時超出了預期工時，這致使了項目關鍵路徑的改變，若是咱們想要按時交付項目，在不加入小張的狀況下，只能砍掉幾個沒必要要的功能，延後至下一個版本上線。這是範圍、時間、成本之間的制約

項目管理就是對於這些制約因素的管理，在這些制約因素的相互影響下，幫助企業實現最高的價值收益。

 

項目管理是一套管理體系，主要包括5大過程組：啓動、規劃、執行、監控、收尾。在前面說到的預測，就是啓動與規劃，咱們能夠在規劃後，獲得詳細的計劃，計劃包括但不限於：

1） 範圍管理計劃；

2） 進度管理計劃；

3） 成本管理計劃；

4） 質量管理計劃；

5） 人力資源管理計劃；

6） 風險管理計劃。

這些計劃就是項目的基準，指導團隊執行項目活動，有了基準就是有了目標與規範，你們在規範的指導下，向着明確的目標共同努力完成項目。

當項目執行中，咱們還須要及時監控項目的執行狀況，保證項目的執行方向與目標方向保持一致，這個時候就有了績效，經過對於績效的把控，來衡量項目團隊當前時間點的任務完成狀況，若是發現誤差，須要及時調整，發現誤差的方法能夠是：

1） 趨勢分析

2） 誤差分析

3） 掙值績效

4） 統計抽樣

可能存在的誤差有：進度誤差、質量誤差、成本誤差、範圍誤差，咱們經過修正這些誤差，保證項目是可控的，以實現商業價值。

範圍、進度、質量、成本，這幾個制約因素，在這裏就被稱做爲「多快好省」， 由於多快好省正是衡量幾個指標的目的，除掉「多快好省」以外，項目管理還須要對團隊成員進行管理，管理他們的指望，管理他們的工做狀態，這就要求項目經理具備必定的軟技能，和人力資源相關的方法論。

風險管理，積極和消極的風險一般被稱做爲機會和威脅。若是風險在可承受範圍以內，而且與冒這些風險可能獲得的回報相平衡，那麼項目就是可接受的，咱們經過識別風險、定性風險、定量風險、制定風險應對策略、控制風險，這樣的處理流程對風險進行監控。

在實際工做中，傳統團隊中的高級管理者一般承認上面這種項目管理方式，他們關注的問題諸如：

1） 項目可否完成預期價值？

2） 項目何時可以交付？

3） 當前的進度如何，可否按時完成里程碑？

4） 質量是否達標？

5） 咱們是否須要作出調整？

他們但願以可控的方式來對待項目，這種項目管理方式在定製化項目中很是適用，由於它知足PDCA的管理循環理論，以SMART的方式制定項目計劃，以掙值管理的方法監控過程，最終獲得預期的結果並進行復盤。而且這套流程一樣符合企業管理的流程，可以監控團隊的績效，得到團隊的執行狀況，這是高層管理者最但願看到的，因此必然會在企業內獲得承認和推廣。可是如今的互聯網企業基本不作定製化項目了，若是套用這一套項目管理體系，在執行過程當中會很是的難受，他們會發現來自用戶、市場、銷售的需求範圍隨時都在發生變動，沒法創建詳細的執行計劃，若是讓團隊作一個月的計劃是能夠實現的，可是若是作半年的計劃，那是痛苦的，沒有詳細的計劃，就沒有完善的監控過程，也就沒法準確的評價績效。

不一樣類型的項目須要不一樣的對待。就像咱們的生活同樣，吃中餐的時候咱們使用筷子比較方便，而吃西餐時咱們使用刀叉比較便捷。而咱們再進行開發工做時，也會基於不一樣的環境選擇不一樣的方法。

「敏捷項目管理」是一種適應型的管理方式，它以價值驅動交付，項目團隊須要保證最有價值的功能最早被交付，而後經過用戶的反饋獲得改進的意見，及時調整適應，整個開發過程遵循計劃->執行->調整的環狀結構流程，在敏捷團隊中，個體和交互大於流程和工具，這要求每一個團隊成員都具備良好的溝通能力和專業技能，若是每一個成員都是T型人才，可以勝任產品設計、開發、測試中的每一個崗位，那敏捷團隊將會表現的很是高效。這樣看起來，敏捷團隊就像是一個特種部隊，每個成員都擁有普遍的專業技能，隨時可以填補團隊中的空缺，保證任務的穩定執行，若是想要嘗試敏捷項目管理的，能夠了解如下敏捷方法（只作介紹不作詳細說明）：

Scrum：

 

Scrum特指一種敏捷開發的模型。它是一個迭代小、增量性的流程，適用於任何的產品開發以及工做管理。Scrum將軟件開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具有的最佳典範與技術，具備高度自主權，緊密地溝通合做，以高度彈性解決各類挑戰，確保天天、每一個階段都朝向目標，明確的推動。

Scrum三大支柱：

1） 高透明性：信息的高度透明，任何方面都能被觀察到

2） 檢查：常常性的檢查，防止重大誤差

3） 適應：當發現可交付成果不合格時，應該及時修正，減小誤差

Scrum 團隊：

1） 開發團隊：是自組織的、跨職能的、他們擁有創造產品增量所須要的所有技能，包括設計，相似特種部隊。

2） 產品負責人：是管理產品待開發項的惟一負責人，相似軍隊中的軍長。

3） Scrum Master：確保Scrum被理解並實施，相似軍隊中的政委。

Scrum 事件：

1） 迭代：一個迭代就是一個時間盒（有時間限制），在這個時間盒中至少應該有產品發佈，這個時間盒的長度通常爲1~6周的時間。

2） 迭代計劃會議：肯定在這個迭代中須要交付哪些產品以及如何達成目標。

3） 每日立會：天天15分鐘的時間，開發團隊須要同步他們的活動，彼此進行溝通以及提出問題。

4） 迭代評審：迭代結束時舉行的會議，產品負責人決定本次迭代是否完成。

5） 迭代回顧：回顧反思整個迭代過程須要改進的地方。

Scrum 工件

1） 產品待開發項：全部須要開發的功能。

2） 迭代待開發項：產品待開發項的分解，一次能夠交付的最小迭代目標。

3） 燃盡圖：翻譯工做量完成狀態的趨勢圖。

極限編程（XP）：

XP是敏捷方法中的一種軟件開發方法。若是說Scrum更加關注項目管理工做的話，那麼XP更加關注軟件開發的良好實踐。XP的核心價值是監督、溝通、反饋、勇氣、尊重，這些價值體如今XP的整個生命週期中。

極限誤差的核心實踐：

 

項目團隊使用FDD的方法首先能夠爲產品開發一個總體的模型，構建特性列表和工做計劃，而後對開發的特性進行設計和構建迭代。FDD推薦了一系列的良好實踐，這些都是從軟件工程中延伸而來。這些實踐包括：

1. 領域對象建模

2. 安裝特性開發

3. 類擁有權

4. 特性小組

5. 審查

6. 配置管理

7. 按期構建

8. 可視性進度報告

動態系統開發方法（DSDM）：

 

DSDM倡導以業務爲核心，快速而有效的進行系統開發，其的基本觀點是，任何事情都不可能一次性地圓滿完成，應該用20%的時間完成80%的有用功能，以適合商業目的爲準。實施的思路是，在時間進度和可用資源預先固定的狀況下，力爭最大化地知足業務需求（傳統方法一步是需求固定，時間和資源可變），交付所需的系統。對於交付的系統，必須達到足夠的穩定程度以在時間環境中運行；對業務方面的緊急需求，也要求可以在短期內獲得知足，而後在之後迭代階段中對功能進行進一步完善。

DSDM週期有7個階段

1） 項目準備階段

2） 可行性檢驗局階段

3） 業務研究階段

4） 功能建模階段

5） 系統設計編程階段

6） 實施階段

7） 項目後期階段

精益開發（LEAN）：

精益開發不是敏捷的方法，可是精益和敏捷的價值觀是緊密相關的，精益的一系列原則是從精益生產中來的，並應用於軟件開發。對於精益來講有7個核心的概念：

 

中消除浪費是爲了最大化價值。浪費來自一些沒必要要的功能。爲了提高咱們在項目中得到的價值，咱們必須識別一種方法以消除浪費。

看板方法（Kanban）：

看板開發方法是近年來最熱門的敏捷和精益開發方法。愈來愈多的案例代表，它可以改善協做、優化管理，顯著提升交付速度、質量和靈活性。看板開發方法的規則簡單，但其有效的實施依賴於對原理的理解、對原則的堅持和實踐的應變。

一個看板在敏捷開發中的最佳實踐如圖：

 

每一個卡片表明開發中的各各流程，圖中以 規劃->開發->測試->發佈這樣的流程來進行管理，開發任務在這個工做流中扭轉執行，最終被髮布。整個過程顯的十分靈活可控。

「敏捷項目管理」在質量保證的流程中須要藉助一些自動化方式，如：

1） 持續集成（CI）；

2） 持續部署（CD）；

3） 測試驅動開發（TDD）；

4） DevOps(開發、運維、質量管理一體化)；

經過自動化的流程，提升交付的效率，減小人爲出錯的概率，提高質量。

與預測型項目管理相比，敏捷有他的優點，肯定短時間的需求，快速迭代交付、快速驗證價值，採用週期性評價代替複雜的績效管理、讓整個團隊的目標一致，以價值驅動。

敏捷看似簡單，但想要達到真正意義上的敏捷是比較困難的，好比敏捷提倡「擁抱變化 高於 遵循計劃」這在不少團隊執行時每每會陷入兩個極端，要麼根本不作規劃，要麼就在計劃上投入大量的精力直到本身確信計劃是正確的，不作基本規劃的小組可能連什麼時間交付產品都沒法回答，而作了大量計劃的小組會自欺欺人地認爲某個計劃是「正確的」，他們的計劃也許更全面，但並不意味更準確或更有用。這兩種極端都是敏捷須要避免的，「咱們實施敏捷，再也不須要計劃和文檔了」的論調是極其錯誤的。敏捷不是不須要計劃，相反它須要更多的規劃。不肯定性是影響計劃正確的主要因素，對大部分不肯定而言，獲取知識、減小不肯定性的惟一辦法是開發獲得一些原型，收集反饋，而後分析其價值，最後作出調整，這是規劃-執行-調整的方式。一個項目的不肯定性越高，敏捷開發方法對取得成功就越相當重要，不斷學習和調整是敏捷開發的核心。

 

四、太長不看的結論性總結

 

在選擇項目管理工具前，須要肯定咱們使用的是項目管理方法仍是敏捷項目管理方法。若是使用的是項目管理方法，我推薦「project」；若是使用的是敏捷項目管理方法，我推薦使用

「日事清」。