2.2　采用生命周期創建WBS

在項目的實施過程中，可以采用不同的項目生命周期。項目生命周期指的是項目從啟動到結束所經歷的一系列階段，它為項目管理提供了一個基本框架。不論項目涉及的具體工作是什么，這個基本框架都適用。這些階段可以是順序的、迭代的或交疊的。所有項目都可以映射到如圖2-1所示的通用生命周期。

項目管理團隊要確定各個項目最適合的生命周期。項目生命周期需要具有足夠的靈活性，以應對項目中包含的各種因素。可以通過以下方法實現生命周期的靈活性：

◆ 識別需要在各個階段實施的過程。

◆ 在合適的階段實施已識別的過程。

◆ 調整階段的各種屬性（如名稱、持續時間、退出標準和準入標準）。

WBS有助于項目經理、項目領導者、相關方和參與者對項目產生的最終產品、可交付成果或輸出（輸出可以是產品、服務或結果）建立清晰的愿景。更準確地說，WBS為項目提供了包括交付產品、服務或結果所涉及工作的清晰愿景。

WBS的創建因每個項目所選擇的生命周期而異，而項目和子項目集組成了項目集WBS。

項目生命周期可以是預測型的、迭代型的、增量型的或敏捷型的：

◆ 在預測型生命周期中，在生命周期的早期階段確定項目范圍、時間和成本。對任何范圍的變更都要進行仔細的管理。預測型生命周期也可能指的是瀑布型生命周期。

◆ 在迭代型生命周期中，項目范圍通常在項目生命周期的早期被確定，但時間及成本估算將隨著項目團隊對產品理解的不斷深入（滾動規劃）而定期修改。迭代通過一系列重復的循環活動來開發產品。

◆ 在增量型生命周期中，通過在一定時間內的一系列迭代，漸進地增加產品的功能以產出可交付成果。只有在最后一次迭代后，可交付成果具有了必要的和足夠的能力，它才能被視為完成。

◆ 在敏捷型生命周期中，通過一系列的迭代來交付所需的功能。這些迭代的持續時間很短，通常持續1～4周。迭代通過一系列重復的循環活動來開發產品。

混合型生命周期是預測型生命周期和敏捷型生命周期的組合。那些已知的或有確定需求的項目可遵循預測型開發生命周期，而那些仍在發展變化的項目可遵循敏捷型生命周期，這更易于適應范圍的蔓延和變更。

在所有的項目生命周期中，WBS包括由項目領導者、相關方、內部和外部參與者（如團隊成員和分包商）要完成的所有工作。WBS對要執行的工作的目標和可交付成果提供了清晰的陳述。項目團隊使用WBS與相關方進行溝通。

不同的項目生命周期具有以下特點，如《敏捷實踐指南》中的表3-1所示：

WBS層次的深度取決于項目的規模、復雜性及計劃和管理它所需的詳細程度。WBS由執行組織要完成的整個范圍的多級層次結構組成。但是，具體的層次數量應便于有效地管理、執行和監控項目。

2.2.1　在預測型（瀑布型）生命周期中使用WBS

在具有較高的確定性、穩定的需求和低風險的情況下，可以采用預測型生命周期。因此，在預測型生命周期中，項目活動通常按順序執行。當采用預測型生命周期時，團隊需要詳細的計劃來知道要交付什么及如何交付。在項目的開始階段，團隊創建詳細的需求、范圍說明書、WBS、WBS詞典和計劃。通常，團隊直到項目結束才交付商業價值（見圖2-2）。

在預測型生命周期中，項目范圍、時間和成本在生命周期的早期階段被確定。通過正式的變更管理流程來對范圍的任何變更進行仔細的管理。預測型生命周期也被稱為瀑布型生命周期。

典型的預測型生命周期WBS遵循以下慣用做法：

◆ 項目名稱出現在WBS的第一層次。

◆ 項目階段或主要項目可交付成果通常出現在第二層次。

◆ 第三層次和其他下級層次（取決于第二層次）可以用來表示可交付成果、控制賬戶或工作包。

◆ 根據項目的規模和復雜性，WBS分解可以繼續進行。

◆ WBS組件的最低層次被稱為工作包。

圖2-3展示了基于階段WBS的常用做法。

圖2-4展示了基于可交付成果WBS的常用做法。

隨著項目范圍的逐步細化，迭代地演化WBS，直到整個項目的范圍已經被基準化。

在預測型生命周期中，項目的范圍基準是經過批準的項目范圍說明書、WBS和相應的WBS詞典。基準僅通過正式的變更控制程序進行變更，并在項目實施期間作為比較的基礎，如圖2-5所示。

2.2.2　在迭代型生命周期中使用WBS

在迭代型生命周期中，通過連續的原型法或概念證明來改進產品或結果。每個新的原型都能帶來新的（或額外的）相關方反饋和團隊見解。在下一個周期中，團隊集成這些新的信息，并通過重復一個或多個項目活動來重新構建原型。

當項目的復雜性高、變更頻繁，或者項目范圍受到相關方的不同觀點、技術進步或期望的最終產品的支配時，采用迭代型生命周期更有優勢。當采用迭代型生命周期時，可能需要更長的時間，因為它是為學習而優化的，而不是為交付速度而優化的。在迭代型生命周期中，通常直到項目結束都不會交付實質性的商業價值。在某些情況下，采用迭代型生命周期可提高進入下一個里程碑或為下一階段獲得關鍵批準的可能性。

在迭代型生命周期中，項目范圍通常在項目生命周期的早期確定，但時間及成本估算將隨著項目團隊對產品理解的不斷深入而定期修改。迭代方法通過一系列重復的循環活動來開發產品，而增量方法通過漸進地增加產品功能來開發產品，如圖2-6所示。

在迭代型生命周期中，WBS的表示通常遵循以下慣用做法：

◆ 項目名稱出現在WBS的第一層次。

◆ 第二層次表示項目階段（迭代）。重復項目的多個初始階段（迭代），直到相關方對分解達成一致。此外，項目的后期階段（迭代）會重復進行，直到項目交付最終的輸出。

◆ 第三層次和其他下級層次可以用來表示可交付成果或工作包。

◆ 根據項目的規模和復雜性，WBS分解可以繼續進行。

◆ WBS組件的最低層次被稱為工作包。

圖2-7展示了基于階段WBS的慣用做法。

隨著項目范圍的逐步細化，WBS迭代地演化，直到范圍中的每次迭代分別被基準化。

在迭代型生命周期中，項目的范圍基準是經過批準的項目范圍說明書、WBS和相應的在項目生命周期中詳細闡述的WBS詞典。基準僅通過正式的變更控制程序進行變更，并在項目實施期間作為比較的基礎，如圖2-8所示。

2.2.3　在增量型生命周期中使用WBS

有些項目會對交付速度進行優化。許多企業和項目無法等待所有的事情全部完成，在這種情況下，客戶愿意接受整個解決方案的一個部分。這種對少量可交付成果的頻繁交付被稱為增量型生命周期。

在增量型生命周期中，可交付成果是通過一系列迭代產生的，這些迭代在預定的時間框架內連續地添加功能。只有在最后一次迭代后，可交付成果具有了必要的和足夠的能力及價值，它才能被視為完成，如圖2-9所示。

與一次交付一個最終產品相比，在增量型生命周期中，將更頻繁地優化工作，以為項目發起人、相關方或客戶交付價值。只有在最后階段（迭代）完成后，項目的最終產品才被認為是完成的。

在增量型生命周期中，WBS的表示通常遵循以下慣用做法：

◆ 項目名稱、產品名稱或方案名稱出現在WBS的第一層次。

◆ 項目階段（也被稱為迭代）出現在WBS的第二層次。在每個階段（迭代），都將分析、設計、構建、測試，并向客戶交付價值。

◆ 第三層次和其他下級層次可以用來表示可交付成果和/或工作包。

◆ 根據項目的規模和復雜性，WBS分解可以繼續進行。

◆ WBS組件的最低層次被稱為工作包。

圖2-10展示了基于階段WBS的慣用做法。

隨著項目范圍的逐步細化（通過滾動規劃），WBS迭代地演化，直到范圍中的每個階段（迭代）分別被基準化。

在增量型生命周期中，項目的范圍基準是經過批準的項目范圍說明書、WBS和相應的特定迭代的WBS詞典。基準僅通過正式的變更控制程序進行變更，并在項目實施期間作為比較的基礎，如圖2-11所示。

2.2.4　在敏捷型生命周期中使用WBS

對于需求不斷變化或不確定性高的項目，在項目開始時通常無法完全明確項目的范圍，而需要在項目期間逐漸明確。敏捷實踐特意在項目的早期階段縮短定義和協商范圍的時間，同時花費更多的時間來建立用于不斷探索和完善的過程。在多數情況下，不斷涌現的需求往往導致期望的商業需求與最初描述的商業需求間存在差異。

敏捷實踐有目的地構建并評審原型和發布版本以細化和完善需求。因此，范圍在整個項目中被定義和重新定義。在敏捷方法中，產品待辦事項列表構成了已知的需求。敏捷方法中的需求代表了史詩、特性或用戶故事。

產品負責人在團隊、相關方和商業分析專業人士的幫助下，創建產品待辦事項列表。產品代辦事項列表幫助團隊了解如何在不產生浪費的情況下交付最高價值。

在敏捷型生命周期中，項目發起人和客戶代表會定期參與項目，在創建可交付成果時提供反饋，并確保產品待辦事項列表能反映當前的需求。

WBS通常與預測型生命周期相關聯，并支持對項目的整個范圍進行分解。當采用敏捷實踐時，要將整個范圍分解為更小的部分，從而支持待辦事項列表或產品待辦事項列表。

在敏捷型生命周期中，WBS包含商業價值項，這通常被稱為需求、待辦事項列表或用戶故事。每個需求、待辦事項列表項或用戶故事都代表了交付該項所描述的用戶功能所需的工作。每個需求、待辦事項列表項或用戶故事都交付了一個功能的小增量、輸出或可交付成果。工作包代表了WBS中分解的最低層次。用戶故事是敏捷項目中分解的最低層次。工作包和用戶故事都向客戶交付功能。工作包和用戶故事都是關于做什么而不是如何做的。工作包大致等于用戶故事。

對于在敏捷環境中執行的項目，團隊期望需求會發生改變。迭代和增量方法能夠提供反饋，以更好地規劃項目的下一部分。圖2-12顯示了實現增量交付的兩種可能的方法（基于迭代的敏捷方法和基于流程的敏捷方法），這都有助于敏捷項目與客戶的需求保持一致，并可以根據需要進行調整。

在基于迭代的敏捷方法中，團隊通過迭代（使用Scrum框架時的沖刺，它具有相同持續時間的時間盒）來交付完整的特性。在使用迭代的敏捷型生命周期中，有一個關于用戶故事（工作包）規模的目標：用戶故事應該在單次迭代（沖刺）中交付。如果用戶故事不能在單次迭代（沖刺）中交付，則將用戶故事拆分為更小的用戶故事。

在基于流程的敏捷方法中，團隊將根據自身的能力，從待辦事項列表中提取若干功能開始工作，而不是按照基于迭代的進度計劃開始工作。

下面是一些分解敏捷項目的不同方法，但不限于此：

◆ 產品、迭代、用戶故事。

◆ 產品、發布、迭代、用戶故事。

◆ 產品、發布、特性、迭代、用戶故事。

◆ 產品、特性、發布、迭代、用戶故事。

◆ 產品、史詩、特性、迭代、用戶故事。

◆ 產品、特性、史詩、迭代、用戶故事。

對于敏捷項目，存在各種各樣的WBS場景。

第一種場景如圖2-13所示。

◆ 項目名稱或產品名稱出現在WBS的第一層次。

◆ 迭代（沖刺）出現在WBS的第二層次（如1.1、1.2、1.3、1.4、1.5等）。

◆ 用戶故事出現在WBS的第三層次。敏捷項目中的用戶故事是分解的最低層次，具有與工作包相似的特征。用戶故事和工作包都可產生一個或多個可交付成果或功能。

第二種場景如圖2-14所示。

◆ 項目名稱或產品名稱出現在WBS的第一層次。

◆ 發布出現在WBS的第二層次（如發布1、發布2、發布3等）。

◆ 迭代（沖刺）出現在WBS的第三層次（如1.1.x、1.2.x、1.3.x、1.4.x、1.5.x等）。

◆ 用戶故事（工作包）出現在WBS的第四層次。

還有其他發布、特性和迭代的組合。在敏捷型生命周期的項目中，WBS隨著需求的更新而更新，這意味著WBS的基準不會在項目的開始時出現。WBS的最終版本只有在項目完成時才知道，如圖2-15所示。

2.2.5　關鍵概念/特征

以下術語和定義（按字母順序排列）是在《PMI項目管理術語詞典》、《PMBOK?指南》和《敏捷實踐指南》中定義的與WBS相關的術語。這些術語和本實踐標準的術語表中列出的其他術語都有助于理解WBS在項目管理實踐中所起的整體作用。

◆ 活動（Activity）。在進度計劃中所列，并在項目過程中實施的工作組成部分。

◆ 控制賬戶（Control Account）。一種管理控制點。在該控制點上，把范圍、預算、實際成本和進度加以整合，并與掙值比較，以測量績效。

◆ 可交付成果（Deliverable）。為完成某一過程、階段或項目而必須產出的任何獨特并可核實的產品、成果或服務能力。

◆ 獨立型活動（Discrete Effort）。能夠予以規劃并測量，且會產出特定輸出的活動。（注：獨立型活動是用于計算工作績效的三種掙值管理活動之一。）

◆ 支持型活動（Level of Effort）。一種不產生明確的最終產品，而按時間流逝來度量的活動。（注：支持型活動是用于計算工作績效的三種掙值管理活動之一。）

◆ 規劃包（Planning Package）。控制賬戶可以包括一個或多個規劃包。規劃包是一個工作內容已知但詳細進度活動未知的，低于控制賬戶的WBS組件。

◆ 范圍（Scope）。項目所提供的產品、服務和成果的總和。

◆ 范圍基準（Scope Baseline）。經過批準的范圍說明書、WBS和相應的WBS詞典，能夠通過正式的變更控制程序進行變更，并被用作與實際成果進行比較的依據。

◆ 工作分解結構組件（Work Breakdown Structure Component）。工作分解結構任意層次上的任何要素。

◆ 工作分解結構元素（Work Breakdown Structure Element）。包含在單個工作分解結構中的任何單個工作分解結構組件及其關聯的WBS屬性。

◆ WBS詞典（WBS Dictionary）。針對WBS中的每個元素，詳細描述可交付成果、活動和進度信息的文件。

◆ 工作包（Work Package）。WBS最低層次的工作，針對這些工作來估算并管理成本和持續時間。

在實踐中有多種類型的WBS分解。不同的來源將WBS標識為行動導向型、代辦事項導向型、合同導向型、可交付成果導向型、階段導向型、產品導向型、項目集導向型，甚至是一種組合，從而產生了一種混合方法。雖然在分解的類型中沒有特別提到，但是一種新興的類型是位置導向型。

只采用一種分解類型的WBS比較少見，在通常情況下，一個WBS會融合多種分解的類型。七種分解的類型代表了在實踐中發現的典型WBS。表2-1提供了有關分解的類型及WBS示例的重點描述，以幫助讀者應用這些概念。

不管分解的類型是什么，WBS的第一層次都表示項目名稱、產品名稱或計劃名稱。這些分解的類型適用于預測型、迭代型、增量型和敏捷型的生命周期或混合方法。在本實踐標準的后續部分，將說明如何組合不同的分解類型。