敏捷專案管理(摘錄)——敏捷流程架構
阿新 • • 發佈:2019-02-14
流程也許不如人那麼重要,但它絕非不重要。像其他事物一樣,流程必須與企業目標聯絡起來。如果企業目標是重複性的製造,那麼常規性流程是完全適當的,而如果企業目標是可靠的創新,則流程架構必須是有機的、靈活的和容易改變的。敏捷流程架構需要體現其核心原則,除了支援企業目標外,該架構還需要:
1.構想:確定產品構想、專案範圍、專案社團以及團隊共同工作的方式。
構想階段為客戶和專案團隊創造構想,該構想包括提供什麼、誰提供和如何提供。如果沒有構想,其他的專案啟動活動都是無用之功。用商業話語來說,構想是專案早期“成功的關鍵因素”。首先,我們需要構想提供什麼,即產品及專案範圍構想;其次,我們需要構想參與的人是誰:客戶、產品經理、專案團隊成員和利益相關方組成的社團;最後,專案團隊成員必須構想他們打算如何共同工作。
2.推測:制定基於功能的釋出計劃、里程碑和迭代計劃,確保交付構想的產品。
“推測”一詞首先讓人們想到不計後果的冒險景象,但實際上字典對它的定義是“根據不完全的事實或者資訊猜測某事”,這正是這個階段要做的事情。“計劃”一詞具有確定和預測的含義,而計劃的更有用的定義,至少對於探索性專案來說,是基於不完全的資訊推測或者猜測。我的同事肯·德科爾提出了他的偉大看法:“人們認為制定計劃可以產生確定性,但事實遠非如此。他們帶來的只不過是衡量他們績效的東西,而一旦這個衡量尺度與現實出現偏差,他們又不能重新計劃。”
敏捷專案管理更多的是構想和探索,而不是計劃和執行,它迫使我們面對這樣的現實:不穩定的商業環境和變化多端的產品開發環境。推測階段實際上是構想階段的延伸並與它相互影響,它包括:
- 支援構想、探索、適應文化;
- 支援自我組織、自律的團隊;
- 根據專案的不確定性程度,儘量提高可靠性和連貫性;
- 保持靈活和易於變化;
- 支援流程的透明化;
- 與學習結合起來;
- 將支援各個階段的做法包括在內;
- 提供管理檢查點、對該構架進行評估。
敏捷專案管理模式的結構:構想—推測—探索—適應—結束,重點在交付(執行)和適應(參見圖4-1)。
圖4-1 敏捷專案管理流程架構 敏捷專案管理階段的命名既反映了活動,也反映了結果。 例如,構想階段產生專案構想。而且這個命名與傳統的階段命名—— 如開始、計劃、管理、控制—— 徹底分離,意義重大。首先,“構想”代替較傳統的“開始”,表示構想的重要性。 第二,推測階段代替計劃階段。每個詞都傳達一定的意義,而各個意義來自它們長期的系統用法。“計劃”一詞已經與預測和相對確定性相關聯,而“推測”表示未來是不確定的。我們知道,任何專案的未來都包含著不確定性,尤其是那些探索係數較高的專案,但我們仍在試圖“計劃”排除該不確定性。我們必須學會推測和適應,而不是計劃和建造。 第三,敏捷專案管理模式用探索代替通常的管理階段。探索,以迭代交付的方式,明確表示它是非線性的、並行的、非瀑布式的模式。在推測階段提出的問題需要“探索”。鑑於你不能完全預測結果,推測暗示著需要有靈活性。敏捷專案管理模式強調執行以及這樣一個事實:它是探索性的而非確定性的。 第四,實施敏捷專案管理的團隊密切關注構想、監控資訊,從而適應當前情況,這就是適應階段。 最後,敏捷專案管理模式以結束階段收尾,在這個階段,主要的目標是傳遞知識,當然它也是一個慶典。 總之,敏捷專案管理的5個階段是:- 收集初始的、廣泛的產品要求;
- 將工作量定義為一個產品功能清單;
- 制訂一個交付計劃(釋出、里程碑和迭代),其中包括那些功能的進度表和資源分配;
須具備的判斷力
產品和專案管理長期以來受順序開發流程的薰染,像圖4-1那樣的圖看起來都像是順序開發。儘管專案可能遵照一般的構想、推測、探索、適應和結束這個次序,但我們不應該將整個模式看作是固定的。生產型模式所用的階段詞語暗示著一個線性模式:開始、計劃、管理、控制,而這裡選用的敏捷專案管理術語是用來表示迭代演變的:推測、探索、適應。 過分強調線性會導致停滯不前,而過分強調演變會導致無休止的、最終證明是愚蠢的變化。對於任何一種模式,開發團隊成員、客戶團隊成員和高階主管在應用時都需要作出敏銳的判斷。專案規模
敏捷專案管理的核心價值觀和原則適用於任何規模的專案,在後面章節描述的做法同樣適用於任何規模的專案。但對於超過50人的專案團隊,可能除了本書描述的做法外,還需要其他的做法或者做法的延伸,其中一些在第9章有所論述。隨著專案團隊不斷壯大,通常需要有更多的文件、有其他的協調做法、增加資金或者其他合規活動(如財務控制),這些擴充套件的做法同樣應受敏捷專案管理的價值觀和原則的指導。例如,簡化原則仍適用於一個大型專案,只不過在那裡它意味著採用最簡單的、適於150人而非15人的團隊的做法。 一個500人的團隊可能不如一個10人團隊那樣敏捷,但它可以比競爭對手的500人團隊更敏捷。只要將重點放在交付、自我組織和自律,即使團隊再大,面臨的協調問題再複雜,它也能隨時應對商業、技術和組織的變化。敏捷做法
在敏捷專案管理的每個階段中都有與敏捷價值觀和指導原則相一致的具體做法。這些做法應該看作是一個“做法系統”,因為它們作為一個系統相互補充,與價值觀和原則保持一致。但它們並不侷限於保持一致,它們還著眼於實施。沒有做法的原則只是個空殼,而沒有原則的做法往往會毫無判斷地被生搬硬套。沒有原則,我們就不知道“如何”實施做法,比如說,沒有簡單原則,我們往往會過多地看重做法的形式和儀式。原則指導做法,做法用實際例子證明原則,它們是相輔相成的。 使原則和做法保持一致向我們昭示了這樣一個現實:“最好做法”這個聖盃是虛假的。對於某個專案團隊非常奏效的做法也許對另一個團隊是極其糟糕的做法。做法就是具體做法,它僅僅是實現一些目標的方式。一個具體做法只有在特定的環境中,才能知道它是好是壞,這個特定環境可能包括原則、問題型別(如探索性)、團隊動力和組織文化。 在選擇和使用這些做法時,我採用瞭如下指導原則:- 簡單的;
- 再生的而非常規性的;
- 與敏捷價值觀和原則一致的;
- 集中於交付活動(增值)而非合規活動;
- 最少數量(剛剛可以完成工作)的;
- 相互支援的(做法系統)。