楚凡科技（www.trufun.net) 10年間致力於做中國最專業的軟體工程解決方案提供商
規範軟體開發過程 優化軟體開發流程
保證軟體開發質量 提高軟體開發效率
trufun uml2建模工具、trufun bacon 需求管理工具、 trufun 研發雲管理工具等
流程也許不如人那麼重要，但它絕非不重要。像其他事物一樣，流程必須與企業目標聯絡起來。如果企業目標是重複性的製造，那麼常規性流程是完全適當的，而如果企業目標是可靠的創新，則流程架構必須是有機的、靈活的和容易改變的。
敏捷流程架構需要體現其核心原則，除了支援企業目標外，該架構還需要：
敏捷專案管理模式的結構：構想—推測—探索—適應—結束，重點在交付(執行)和適應(參見圖4-1)。
圖4-1 敏捷專案管理流程架構
敏捷專案管理階段的命名既反映了活動，也反映了結果。
例如，構想階段產生專案構想。而且這個命名與傳統的階段命名
—— 如開始、計畫、管理、控制—— 徹底分離，意義重大。首先，「構想」代替較傳統的「開始」，表示構想的重要性。
第二，推測階段代替計畫階段。每個詞都傳達一定的意義，而各個意義來自它們長期的系統用法。「計畫」一詞已經與**和相對確定性相關聯，而「推測」表示未來是不確定的。我們知道，任何專案的未來都包含著不確定性，尤其是那些探索係數較高的專案，但我們仍在試圖「計畫」排除該不確定性。我們必須學會推測和適應，而不是計畫和建造。
第三，敏捷專案管理模式用探索代替通常的管理階段。探索，以迭代交付的方式，明確表示它是非線性的、並行的、非瀑布式的模式。在推測階段提出的問題需要「探索」。鑑於你不能完全**結果，推測暗示著需要有靈活性。敏捷專案管理模式強調執行以及這樣乙個事實：它是探索性的而非確定性的。
第四，實施敏捷專案管理的團隊密切關注構想、監控資訊，從而適應當前情況，這就是適應階段。
最後，敏捷專案管理模式以結束階段收尾，在這個階段，主要的目標是傳遞知識，當然它也是乙個慶典。
總之，敏捷專案管理的5個階段是：
1.構想：確定產品構想、專案範圍、專案社團以及團隊共同工作的方式。
構想階段為客戶和專案團隊創造構想，該構想包括提供什麼、誰提供和如何提供。如果沒有構想，其他的專案啟動活動都是無用之功。用商業話語來說，構想是專案早期「成功的關鍵因素」。
首先，我們需要構想提供
什麼，即產品及專案範圍構想；其次，我們需要構想參與的人是誰如何
共同工作。 2.
推測：制定基於功能的發布計畫、里程碑和迭代計畫，確保交付構想的產品。
「推測」一詞首先讓人們想到不計後果的冒險景象，但實際上字典對它的定義是「根據不完全的事實或者資訊猜測某事」，這正是這個階段要做的事情。「計畫」一詞具有確定和**的含義，而計畫的更有用的定義，至少對於探索性專案來說，是基於不完全的資訊推測或者猜測。我的同事肯·德科爾提出了他的偉大看法：「
人們認為制定計畫可以產生確定性，但事實遠非如此。他們帶來的只不過是衡量他們績效的東西，而一旦這個衡量尺度與現實出現偏差，他們又不能重新計畫。」
敏捷專案管理更多的是構想和探索，而不是計畫和執行，它迫使我們面對這樣的現實：不穩定的商業環境和變化多端的產品開發環境。推測階段實際上是構想階段的延伸並與它相互影響，它包括：
在估計專案成本這個計畫中加入風險降低策略，並生成其他必要的行政管理和財務資訊。
3.探索：在短期內提供經測試的功能，不斷致力於減少專案風險和不確定性。
探索階段提供產品功能。從專案管理的角度看，在此階段，有三個關鍵的活動區域：第一是通過管理工作量和使用適當的技術方法和風險降低策略，交付計畫的功能；第二是建立協作的、自我組織的專案社團，這是每個人的責任但需要由專案經理推動；第三是管理團隊與客戶、產品經理和其他利益相關方的相互交流。
控制和糾正是這個週期階段常用的術語。計畫制訂了，結果監控了、糾正也完成了：這個流程暗示著計畫是正確的，而如果實際結果與計畫不同，則是錯誤的。
4.適應：審核提交的結果、當前情況以及團隊的績效，必要時做出調整。
「適應」意味著修改或改變而不是成功或失敗。如果專案的指導哲學認為適應變化比執行計畫更重要，則將失敗歸罪於計畫的變更是不會有任何結果的。非常特別的流程並不能從錯誤中吸取教訓，而吸取教訓是敏捷專案管理的關鍵。
自構想階段以後，其迴圈通常是推測—探索—適應，每次迭代都不斷對產品進行提煉。但要是團隊收集到新的資訊，定期地回到構想階段也很有必要。
在適應階段，需要從客戶、技術、人員和流程績效、以及專案狀況等方面對結果進行評估。該分析將會對比實際結果和計畫的結果，但更重要的是，要根據專案得到的最新資訊，思考實際的與修訂後的專案前景。修改後的結果將返回、融入到重新計畫工作中，開始新的迭代。
5.結束：終止專案、交流主要的學習成果並慶祝。
在某種程度上，專案根據開始和結束來界定。許多組織由於沒有明確專案的終結點，通常在客戶之間會造成理解問題。專案應該以慶祝方式結束。結束階段以及每次迭代末尾的「小型」結束的主要目標是：學習並將學到的東西融入到下一次迭代工作中，或者傳遞給下乙個專案團隊。
產品和專案管理長期以來受順序開發流程的薰染，像圖4-1那樣的圖看起來都像是順序開發。儘管專案可能遵照一般的構想、推測、探索、適應和結束這個次序，但我們不應該將整個模式看作是固定的。生產型模式所用的階段詞語暗示著乙個線性模式：開始、計畫、管理、控制，而這裡選用的敏捷專案管理術語是用來表示迭代演變的：推測、探索、適應。
過分強調線性會導致停滯不前，而過分強調演變會導致無休止的、最終證明是愚蠢的變化。對於任何一種模式，開發團隊成員、客戶團隊成員和高階主管在應用時都需要作出敏銳的判斷。
敏捷專案管理的核心價值觀和原則適用於任何規模的專案，在後面章節描述的做法同樣適用於任何規模的專案。但對於超過50人的專案團隊，可能除了本書描述的做法外，還需要其他的做法或者做法的延伸，其中一些在第9章有所論述。隨著專案團隊不斷壯大，通常需要有更多的文件、有其他的協調做法、增加資金或者其他合規活動(如財務控制)，這些擴充套件的做法同樣應受敏捷專案管理的價值觀和原則的指導。例如，簡化原則仍適用於乙個大型專案，只不過在那裡它意味著採用最簡單的、適於150人而非15人的團隊的做法。
乙個500人的團隊可能不如乙個10人團隊那樣敏捷，但它可以比競爭對手的500人團隊更敏捷。只要將重點放在交付、自我組織和自律，即使團隊再大，面臨的協調問題再複雜，它也能隨時應對商業、技術和組織的變化。
在敏捷專案管理的每個階段中都有與敏捷價值觀和指導原則相一致的具體做法。
這些做法應該看作是乙個「做法系統」，因為它們作為乙個系統相互補充，與價值觀和原則保持一致。但它們並不侷限於保持一致，它們還著眼於實施。沒有做法的原則只是個空殼，而沒有原則的做法往往會毫無判斷地被生搬硬套。沒有原則，我們就不知道「如何」實施做法，比如說，沒有簡單原則，我們往往會過多地看重做法的形式和儀式。原則指導做法，做法用實際例子證明原則，它們是相輔相成的。
使原則和做法保持一致向我們昭示了這樣乙個現實：「最好做法」這個聖杯是虛假
的。對於某個專案團隊非常奏效的做法也許對另乙個團隊是極其糟糕的做法。做法就是具體做法，它僅僅是實現一些目標的方式。乙個具體做法只有在特定的環境中，才能知道它是好是壞，這個特定環境可能包括原則、問題型別(如探索性)、團隊動力和組織文化。
在選擇和使用這些做法時，我採用了如下指導原則：
敏捷專案管理架構 APMF
研讀許秀影博士的 敏捷專案管理 基礎知識與應用實務 一書，其中提到傳統專案管理與敏捷專案管理的混合管理模式 敏捷專案管理架構 agile project management framework,apmf 估計是普遍大部分公司所需要的，也比較認可的模式，可以很好的實現傳統專案管理向敏捷專案管理轉型。...
敏捷專案管理架構 APMF
研讀許秀影博士的 敏捷專案管理 基礎知識與應用實務 一書，其中提到傳統專案管理與敏捷專案管理的混合管理模式 敏捷專案管理架構 agile project management framework,apmf 估計是普遍大部分公司所需要的，也比較認可的模式，可以很好的實現傳統專案管理向敏捷專案管理轉型。...
敏捷開發專案管理流程
前段時間給大家整理了敏捷開發的流程，最近在整理敏捷開發專案的流程和管理制度，其整理的專案管理規程如下，這份規程也不完全算是敏捷專屬的專案管理規程，主要是在結合我們公司實際的情況下編寫出來的，大家在實際嵌入到公司的過程中可以參考下，不能照搬。1.目的 規範網際網路軟體產品開發專案管理過程，指導開展專案...