當前位置:學問君>人在職場>企業管理>

敏捷項目管理流程圖

學問君 人氣:1.2W

敏捷項目管理流程是怎麼樣的?你知道嗎?各位,看看下面,瞭解一下吧!

敏捷項目管理流程圖

敏捷項目管理流程圖

敏捷項目管理模式的結構:構想—推測—探索—適應—結束,重點在交付(執行)和適應(參見圖4-1)。

圖4-1 敏捷項目管理流程架構

1.     構想:確定產品構想、項目範圍、項目社團以及團隊共同工作的方式。

構想階段爲客戶和項目團隊創造構想,該構想包括提供什麼、誰提供和如何提供。如果沒有構想,其他的項目啓動活動都是無用之功。用商業話語來說,構想是項目早期“成功的關鍵因素”。首先,我們需要構想提供什麼,即產品及項目範圍構想;其次,我們需要構想參與的人是誰:客戶、產品經理、項目團隊成員和利益相關方組成的社團;最後,項目團隊成員必須構想他們打算如何共同工作。

2.     推測:制定基於功能的發佈計劃、里程碑和迭代計劃,確保交付構想的產品。

“推測”一詞首先讓人們想到不計後果的冒險景象,但實際上字典對它的定義是“根據不完全的事實或者資訊猜測某事”,這正是這個階段要做的事情。“計劃”一詞具有確定和預測的含義,而計劃的更有用的定義,至少對於探索性項目來說,是基於不完全的資訊推測或者猜測。我的同事肯·德科爾提出了他的偉大看法:“人們認爲制定計劃可以產生確定性,但事實遠非如此。他們帶來的只不過是衡量他們績效的東西,而一旦這個衡量尺度與現實出現偏差,他們又不能重新計劃。”

敏捷項目管理更多的是構想和探索,而不是計劃和執行,它迫使我們面對這樣的現實:不穩定的商業環境和變化多端的產品開發環境。推測階段實際上是構想階段的延伸並與它相互影響,它包括:

收集初始的、廣泛的產品要求;

將工作量定義爲一個產品功能清單;

制訂一個交付計劃(發佈、里程碑和迭代),其中包括那些功能的進度表和資源分配;

在估計項目成本這個計劃中加入風險降低策略,並生成其他必要的行政管理和財務資訊。

3.     探索:在短期內提供經測試的功能,不斷致力於減少項目風險和不確定性。

探索階段提供產品功能。從項目管理的角度看,在此階段,有三個關鍵的活動區域:第一是透過管理工作量和使用適當的技術方法和風險降低策略,交付計劃的功能;第二是建立協作的、自我組織的項目社團,這是每個人的責任但需要由項目經理推動;第三是管理團隊與客戶、產品經理和其他利益相關方的相互交流。

控制和糾正是這個週期階段常用的術語。計劃制訂了,結果監控了、糾正也完成了:這個流程暗示着計劃是正確的,而如果實際結果與計劃不同,則是錯誤的。

4.     適應:審覈提交的結果、當前情況以及團隊的績效,必要時做出調整。

“適應”意味着修改或改變而不是成功或失敗。如果項目的指導哲學認爲適應變化比執行計劃更重要,則將失敗歸罪於計劃的變更是不會有任何結果的。非常特別的流程並不能從錯誤中吸取教訓,而吸取教訓是敏捷項目管理的關鍵。

自構想階段以後,其循環通常是推測—探索—適應,每次迭代都不斷對產品進行提煉。但要是團隊收集到新的資訊,定期地回到構想階段也很有必要。

在適應階段,需要從客戶、技術、人員和流程績效、以及項目狀況等方面對結果進行評估。該分析將會對比實際結果和計劃的結果,但更重要的是,要根據項目得到的最新資訊,思考實際的與修訂後的項目前景。修改後的結果將返回、融入到重新計劃工作中,開始新的迭代。

5.     結束:終止項目、交流主要的學習成果並慶祝。

在某種程度上,項目根據開始和結束來界定。許多組織由於沒有明確項目的終結點,通常在客戶之間會造成理解問題。項目應該以慶祝方式結束。結束階段以及每次迭代末尾的“小型”結束的主要目標是:學習並將學到的東西融入到下一次迭代工作中,或者傳遞給下一個項目團隊。

須具備的判斷力

產品和項目管理長期以來受順序開發流程的薰染,像圖4-1那樣的圖看起來都像是順序開發。儘管項目可能遵照一般的構想、推測、探索、適應和結束這個次序,但我們不應該將整個模式看作是固定的。生產型模式所用的階段詞語暗示着一個線性模式:開始、計劃、管理、控制,而這裏選用的`敏捷項目管理術語是用來表示迭代演變的:推測、探索、適應。

過分強調線性會導致停滯不前,而過分強調演變會導致無休止的、最終證明是愚蠢的變化。對於任何一種模式,開發團隊成員、客戶團隊成員和進階主管在應用時都需要作出敏銳的判斷。

項目規模

敏捷項目管理的核心價值觀和原則適用於任何規模的項目,在後面章節描述的做法同樣適用於任何規模的項目。但對於超過50人的項目團隊,可能除了本書描述的做法外,還需要其他的做法或者做法的延伸,其中一些在第9章有所論述。隨着項目團隊不斷壯大,通常需要有更多的文檔、有其他的協調做法、增加資金或者其他合規活動(如財務控制),這些擴展的做法同樣應受敏捷項目管理的價值觀和原則的指導。例如,簡化原則仍適用於一個大型項目,只不過在那裏它意味着採用最簡單的、適於150人而非15人的團隊的做法。

一個500人的團隊可能不如一個10人團隊那樣敏捷,但它可以比競爭對手的500人團隊更敏捷。只要將重點放在交付、自我組織和自律,即使團隊再大,面臨的協調問題再複雜,它也能隨時應對商業、技術和組織的變化。

敏捷做法

在敏捷項目管理的每個階段中都有與敏捷價值觀和指導原則相一致的具體做法。這些做法應該看作是一個“做法系統”,因爲它們作爲一個系統相互補充,與價值觀和原則保持一致。但它們並不侷限於保持一致,它們還着眼於實施。沒有做法的原則只是個空殼,而沒有原則的做法往往會毫無判斷地被生搬硬套。沒有原則,我們就不知道“如何”實施做法,比如說,沒有簡單原則,我們往往會過多地看重做法的形式和儀式。原則指導做法,做法用實際例子證明原則,它們是相輔相成的。

使原則和做法保持一致向我們昭示了這樣一個現實:“最好做法”這個聖盃是虛假的。對於某個項目團隊非常奏效的做法也許對另一個團隊是極其糟糕的做法。做法就是具體做法,它僅僅是實現一些目標的方式。一個具體做法只有在特定的環境中,才能知道它是好是壞,這個特定環境可能包括原則、問題類型(如探索性)、團隊動力和組織文化。