首先我們區分一下產品範圍(Product Scope)、項目範圍(Project Scope)的概念：
- 產品範圍表示你和你的團隊正在構建的產品或服務的特性和功能。
- 項目範圍是建立產品所需完成的全部工作。
- 本章所描述的範圍管理是針對項目範圍，而不是產品範圍。
- 範圍蔓延(Scope Creep)是指導致團隊做額外工作的失控變更(Uncontrolled Change)。
範圍管理(Scope Management)就是要做正確的事，在建立產品之前你必須知道要建立什麼。這意味着明確哪些超出範圍，而不是哪些是屬於範圍的一部分。範圍管理知識領域包括以下6個過程：
- 計劃範圍管理(Plan Scope Management)
- 收集需求(Collect Requirements)
- 定義範圍(Define Scope)
- 創建工作分解結構(Create Work Breakdown Structure)
- 控制範圍(Control Scope)
- 覈實範圍(Validate Scope)
1. 計劃範圍管理(Plan Scope Management)
|
輸入(Inputs)
|
企業環境要素(Enterprise Environmental Factors)
組織過程資產(Organizational Process Assets)
項目管理計劃(Project Management Plan)
項目章程(Project Charter)
|
|
工具或技術(Tools and Techniques)
|
專家判斷(Expert Judgment)
會議(Meetings)
|
|
輸出(Outputs)
|
需求管理計劃(Requirements Management Plan)
範圍管理計劃(Scope Management Plan)
|
- 計劃範圍管理過程需要計劃出一些方法和途徑，用於找出你要做什麼以及什麼超出了範圍，也就是明確指出如何執行範圍管理知識領域其他的過程。
2. 收集需求(Collect Requirements)
|
輸入(Inputs)
|
干係人管理計劃(Stakeholder Management Plan)
需求管理計劃(Requirements Management Plan)
干係人登記表(Stakeholder Register)
範圍管理計劃(Scope Management Plan)
項目章程(Project Charter)
|
|
工具或技術(Tools and Techniques)
|
與干係人討論的工具和技術：
訪談(Interview)
輔助工作室(Facilitated Workshops)
專題小組討論會(Focus Groups)
羣體決策技術(Group Decision-Making Techniques)：
一致同意(Unanimity)
多數同意(Majority)——一件事情多數人同意則通過
少數服從多數(Plurality)——從多件事中挑選多數人認同的事情通過
總裁制(Dictatorship)
羣體創新技術(Group Creativity Techniques)：
思維導圖(Idea/Mind Maps)
德爾菲法(The Delphi Technique)——羣體匿名投票， 適合估算工作量和時間
親和圖(Affinity Diagrams)——需求分組
頭腦風暴(Brainstorming)
名義羣體法(The Nominal Group Technique)——頭腦風暴的一種形式，對頭腦風暴的結果進行投票，排序組織
對比分析(Benchmarking)
文檔分析(Document Analysis)
上下文圖(Context Diagrams)——展示產品範圍內的過程和特性之間的關係，以及用戶如何與之交互
問卷調查(Questionnaire)
觀察(Observation)
原型(Prototype)
|
|
輸出(Outputs)
|
需求文檔(Requirements Document)
需求追溯矩陣(Requirements Traceability Matrix)
|
- 需求文檔要列出所有的功能性需求和非功能性需求。
- 功能性需求(Functional Requirements)一般是指新特性(New Features)、Bug修復(Bug Fixes)、新行爲或不同的行爲(New or Different Behavior)。
- 非功能性需求(Nonfunctional Requirements)主要是指產品質量屬性，包括性能(Performance)、可靠性(Reliability)、錯誤處理(Error Handling)和易用性(Ease of Use)。
3. 定義範圍(Define Scope)
|
輸入(Inputs)
|
需求文檔(Requirements Document)
組織過程資產(Organizational Process Assets)
範圍管理計劃(Scope Management Plan)
項目章程(Project Charter)
|
|
工具或技術(Tools and Techniques)
|
輔助工作室(Facilitated Workshops)
產品分析(Product Analysis)
替代方案識別(Alternatives Generation)
專家判斷(Expert Judgment)
|
|
輸出(Outputs)
|
項目範圍說明書(Project Scope Statement)
項目文檔更新(Project Document Updates )
|
- 項目範圍說明書指出你在項目中將要做以及不應做的工作。
4. 創建工作分解結構(Create Work Breakdown Structure)
|
輸入(Inputs)
|
企業環境要素(Enterprise Environmental Factors)
組織過程資產(Organizational Process Assets)
範圍管理計劃(Scope Management Plan)
項目範圍說明書(Project Scope Statement)
需求文檔(Requirements Document)
|
|
工具或技術(Tools and Techniques)
|
|
|
輸出(Outputs)
|
工作分解結構(Work Breakdown Structure)
WBS字典(WBS Dictionary)
範圍基線(Scope Baseline)
項目文檔更新(Project Document Updates )
|
- 一般有兩種分解工作的方式，基於項目或階段(Project or Phase)和基於可交付成果(Deliverables)。
- 分解出來的最小單位稱爲工作包(Work Package)，工作包必須是可計量的(Measurable)。
- 項目範圍說明書、工作分解結構和WBS字典統稱範圍基線(Scope Baseline)。
- 爲何範圍會變化：
- 好的變化(Good Change)——不需要更多的時間和成本，且對項目質量沒有影響
- 壞的變化(Bad Change)——好注意但是有影響
- 範圍蔓延——一個變更引起另一個變更，另一個變更又引起新的變更
- 鍍金——多此一舉，畫蛇添足
5. 控制範圍(Control Scope)
|
輸入(Inputs)
|
組織過程資產(Organizational Process Assets)
工作績效數據(Work Performance Data)
需求文檔(Requirements Document)
需求追溯矩陣(Requirements Traceability Matrix)
項目管理計劃(Project Management Plan)
批准的變更請求(Approved Change Requests)
|
|
工具或技術(Tools and Techniques)
|
差異分析(Variance Analysis) |
|
輸出(Outputs)
|
工作績效信息(Work Performance Information)
變更請求(Change Requests)
組織過程資產更新(Updates to Organizational Process Assets)
項目管理計劃更新(Updates to Project Management Plan)
項目文檔更新(Project Document Updates )
|
- 控制範圍的目標就是更新範圍、計劃、基線和WBS信息。
- 變更的流程：
- 1) 確實需要一個變更
- 2) 創建一個變更請求
- 3) 讓變更得到批准——整合變更控制
- 4) 完成差異分析
- 5) 重新計劃工作
- 6) 創建一個新的基線
6. 覈實範圍(Validate Scope)
|
輸入(Inputs)
|
可交付成果(Deliverables)
工作績效數據(Work Performance Data)
需求文檔(Requirements Document)
需求追溯矩陣(Requirements Traceability Matrix)
項目管理計劃(Project Management Plan)
|
|
工具或技術(Tools and Techniques)
|
羣體決策技術(Group Decision-Making Techniques)
檢查(Inspection)
|
|
輸出(Outputs)
|
接受的可交付成果(Verified Deliverables)
工作績效信息(Work Performance Information)
變更請求(Change Requests)
項目文檔更新(Project Document Updates )
|
- 正式驗收(Formal Acceptance)意味着你已經得到所有干係人的書面確認(Written Confirmation)，證實你的可交付成功滿足需求和項目管理計劃。
- 覈實範圍和控制範圍的順序不確定，因爲檢查未通過時，要再走控制範圍的流程，發起變更請求。
本章完！
