微信開發(fā)者工具下載官網(wǎng)下載seo軟文代寫
? ? ? ? 項目范圍管理包括確保項目“做”且“只做”所需的全部工作（即不能少做，也不能多做，如果多做，就要消耗團隊額外的時間和資源，并且無法被認可），以成功完成項目。項目范圍管理主要在于定義和控制哪些工作應(yīng)該包括在項目內(nèi)，哪些不應(yīng)該包括在項目內(nèi)。
? ? ? ? 范圍管理過程確保了項目團隊和項目相關(guān)方就項目的可交付成果以及形成這些可交付成果所進行的工作達成共識。
????????范圍包括產(chǎn)品范圍和項目范圍
- 產(chǎn)品范圍：某項產(chǎn)品、服務(wù) 或 成果所具有的特性和功能。
- 項目范圍：為交付具有規(guī)定特性與功能的產(chǎn)品、服務(wù) 或 成果而必須完成的工作。
????????在交付產(chǎn)品的項目中，項目范圍包括產(chǎn)品范圍。
目錄???????
一、項目范圍管理輸入、輸出、技術(shù)和工具
1.1 規(guī)劃范圍管理
1.2 收集需求
1.3 定義范圍
1.4 創(chuàng)建WBS
1.5 確認范圍
1.6 控制范圍
1.7 管理新實戰(zhàn)
1.8 裁剪考慮因素
1.9 敏捷與適應(yīng)方法
二、規(guī)劃范圍管理
2.1 作用
2.2 范圍管理計劃
2.3 需求管理計劃
2.4 需求管理計劃和范圍管理計劃
2.5?驗收文件
三、收集需求
3.1 作用
3.2 需求、可交付成果與項目目標的映射關(guān)系
3.3? 工具與技術(shù)
3.4 需求管理過程
3.4.1 親和圖
3.4.2 思維導圖
3.5 需求決策
3.6?需求文件
?3.7?需求跟蹤矩陣
3.8?敏捷場景下的需求管理
3.8.1 產(chǎn)品屬性
3.8.2 精益畫布
3.8.3 最小可發(fā)布版本
3.8.4 產(chǎn)品待辦事項列表
3.8.5 分解和細化產(chǎn)品待辦事項列表中的條目
3.8.6 用戶故事
四、定義范圍
4.1 作用
4.2 項目范圍說明書
五、創(chuàng)建WBS
5.1 作用
5.2 分解的基本概念
5.3 分解步驟
5.4 WBS元素
5.5 WBS字典
5.6 控制賬戶
5.7 規(guī)劃包
5.8 工作包的分解原則
5.9 范圍基準
5.10 WBS的價值
六、確認范圍
6.1 作用
6.2 確認范圍的步驟
6.3 需要檢查的問題
6.4 干系人關(guān)注點的不同
6.5 可交付成果的演變
6.6 質(zhì)量控制和范圍確認
6.7 其它知識點
七、控制范圍
7.1 作用
7.2 范圍蔓延
一、項目范圍管理輸入、輸出、技術(shù)和工具
| 概念 | 核心思想 | |
| 規(guī)劃范圍管理 | 指南和方向 | 為了記錄如何定義、確認和控制項目范圍及產(chǎn)品范圍，創(chuàng)建范圍管理計劃。 |
| 收集需求 | （甲方）你要啥？ | 易混淆。 收集需求：為了實現(xiàn)項目目標，確定、記錄并管理干系人的需要和需要。 定義范圍：制定項目和產(chǎn)品詳細描述。 |
| 定義范圍 | （乙方）我干啥？ | |
| 創(chuàng)建WBS | 細一點 | 將項目可交付成果和項目工作分解為較小的、更易于管理的組件。 |
| 確認范圍 | （甲方）你簽字 | 易混淆。 確認范圍：正式驗收已完成的項目可交付成果。 控制范圍：監(jiān)督項目和產(chǎn)品的范圍狀態(tài)，管理范圍基準的變更。 |
| 控制范圍 | 做且只做 |
1.1 規(guī)劃范圍管理
? ? ? ? 在整個項目期間對如何管理范圍提供指南和方向。本過程僅開展一次或公在項目的預(yù)定義點開展。
1.2 收集需求
? ? ? ? 為定義產(chǎn)品范圍和項目范圍奠定基礎(chǔ)。本過程僅開展一次或僅在項目的預(yù)定義點開展。
1.3 定義范圍
? ? ? ? 描述產(chǎn)品、服務(wù) 或 成果的邊界和驗收標準。本過程需要在整個項目期間多次反復開展。
1.4 創(chuàng)建WBS
? ? ? ? 為所要交付的內(nèi)容提供架構(gòu)。本過程僅開展一次或僅在項目預(yù)定義點開展。
1.5 確認范圍
? ? ? ? 使驗收過程具有客觀性；通過確認每個可交付成果來提高最終產(chǎn)品、服務(wù) 或 成果獲得驗收的可能性。
1.6 控制范圍
? ? ? ? 在整個項目期間保持對范圍基準的維護。
????????高清鏈接：項目范圍管理輸入、輸出、技術(shù)和工具 密碼:X0V8
1.7 管理新實戰(zhàn)
????????需求一直是項目管理的關(guān)注重點。項目范圍管理的新趨勢和新興實戰(zhàn)更加注重與商業(yè)分析師一起合作，以便：
- 確定問題并識別商業(yè)需要；
- 識別并推薦能夠滿足需要的可行解決方案；
- 收集、記錄并管理干系人需求滿足商業(yè)和項目目標；
- 推薦項目集或項目產(chǎn)品、服務(wù)或最終成果功能應(yīng)用。
????????商業(yè)分析師的職責還應(yīng)包括需求管理相關(guān)的活動，項目經(jīng)理則負責確保這些活動列入項目管理計劃，并且在預(yù)算內(nèi)按時完成，同時能夠創(chuàng)造價值。
? ? ? ? 項目經(jīng)理與商業(yè)分析師之間應(yīng)該是伙伴合作關(guān)系。
1.8 裁剪考慮因素
對項目范圍管理過程裁剪時應(yīng)該考慮的因素：
- 知識和需求管理：項目經(jīng)理應(yīng)該建立哪些指南？為了未來項目中重復使用需求，組織是否擁有正式或非正式的知識和需求管理體系？
- 確認和控制：組織是否采用敏捷方法管理項目？開發(fā)方法屬于迭代型還是增量型？是否采用預(yù)測型方法？混合型方法是否有效？
- 需求的穩(wěn)定性：項目中是否存在需求不穩(wěn)定的領(lǐng)域？是否有必要采用精益、敏捷或其他適應(yīng)弄技術(shù)來處理不穩(wěn)定的需求，直到需求穩(wěn)定且定義明確？
- 治理：組織是否擁有正式或非正式的審計和治理政策、程序和指南？
1.9 敏捷與適應(yīng)方法
? ? ? ? 對于需求不斷變化、風險在或不確定性高的項目，在項目開始時通常無法明確項目的范圍，而需要在項目期間逐漸明確。敏捷或適應(yīng)型方法特意在項目早期縮短定義和協(xié)商范圍的時間，為后續(xù)細化范圍、明確范圍爭取更多的時間。
? ? ? ? 采用敏捷或適用型生命周期，旨在應(yīng)對大量變更，需要干系人持續(xù)參與項目。
- 采用多次迭代，重復開展三個過程：收集需求、定義范圍 和 創(chuàng)建WBS。
- 發(fā)起人和客戶代表應(yīng)該持續(xù)參與項目，重復開展兩個過程：確認范圍 和 控制范圍。
二、規(guī)劃范圍管理
? ? ? ? 項目范圍管理包括確保項目做且只做所需的全部工作，以成功完成項目。項目范圍管理主要在于定義和控制哪些工作應(yīng)該包括在項目內(nèi)，哪些不應(yīng)該包括在項目內(nèi)。
2.1 作用
本過程的主要作用是：在整個項目期間對如何管理范圍提供指南和方向。
本過程僅開展一次或僅在項目的預(yù)定義點開展。
2.2 范圍管理計劃
? ? ? ? 范圍管理計劃是項目管理計劃的組成部分，描述將如何定義、制定、監(jiān)督、控制和確認項目范圍?？梢允钦交蚍钦降?#xff0c;非常詳細或高度概括的。
????????主要內(nèi)容包括：
1. 如何制定項目范圍說明書；
2. 如何根據(jù)詳細項目范圍說明書創(chuàng)建WBS；
3. 確定如何審批和維護范圍基準；
4. 如何正式驗收已完成的項目可交付成果。?
? ? ? ? 主要解決以下問題：
1. 范圍說明書的定義，以及WBS和WBS詞典的格式、流程。
2. 范圍基準的生成和審批程序。
3. 范圍變更管理的規(guī)則和程序。
4. 可交付成果的驗收標準和流程。
2.3 需求管理計劃
? ? ? ? 需求管理計劃是項目管理計劃的組成部分，描述如何分析、記錄和管理需求。主要內(nèi)容包括：
1. 如何規(guī)劃、跟蹤和報告各種需求活動；
2. 配置管理活動；
3. 需求優(yōu)先級排序過程；
4. 測量指標及使用這些指標的理由；
5. 反映哪些需求屬性將被列入跟蹤矩陣。?
2.4 需求管理計劃和范圍管理計劃
| Requirements | Scopes |
| 需求管理計劃 | 范圍管理計劃 |
|
|
? ? ? ? 項目范圍來源于需求，但是需求管理計劃的目地是記錄、跟蹤和管理需求，所有需求只要被提出，就應(yīng)該被有效管理，無論這個需求是否被滿足。需求管理計劃要定義需求識別、記錄、跟蹤、報告、變更、排優(yōu)先級等計劃的規(guī)則和方法。
? ? ? ? 范圍管理計劃就是我們應(yīng)該如何管理好我們必須做的工作。例如，如何清晰的表述工作范圍，如何明確分工，如何管理變更，如何驗收確認。
2.5?驗收文件
? ? ? ? 由客戶提供，經(jīng)過客戶確認簽字的正式文件，用于對項目可交付成果的驗收。
三、收集需求
? ? ? ? 需求具有多樣性、復雜性、隱蔽性、差異性、變化性 和 矛盾性的特性。
3.1 作用
本過程的主要應(yīng)用是：為定義產(chǎn)品范圍和項目范圍奠定基礎(chǔ)。
本過程公開展一次或僅在項目的預(yù)定義點開展。
3.2 需求、可交付成果與項目目標的映射關(guān)系
1. 并不是所有需求都需要項目組去滿足。
2. 需求是否被批準最終由發(fā)起人決定。
3. 被批準的需求需要同可交付成果及項目目標之間建立邏輯聯(lián)系。?
3.3? 工具與技術(shù)
頭腦風暴 Brainstorming：一種用來生產(chǎn)和收集項目需求和產(chǎn)品需求的多種創(chuàng)意的技術(shù)，通過團隊成員集思廣益、暢所欲言、互相啟發(fā)來實現(xiàn)。但是頭腦風暴會受與會人員的知識經(jīng)驗所限。
訪談 Interview：訪談有經(jīng)驗的項目參與者、發(fā)起人、其他高管以及主題專家，有助于識別和定義可交付的產(chǎn)品特征和功能。
焦點小組?Focus Group：是召集預(yù)定的干系人和主題專家，了解他們對所討論的產(chǎn)品、服務(wù)或成果的期望和態(tài)度。由一位受過訓練的主持人引導大家進行互動式討論。焦點小組往往比“一對一”的訪談更熱烈。
問卷調(diào)查 Questionnaire：適用于以下幾種情況：受眾多樣化，需要快速完成調(diào)查，受訪者地理位置分散，適合開展統(tǒng)計分析。問卷設(shè)計應(yīng)緊密圍繞調(diào)查目的，而向調(diào)查對象，堅持人性化，并優(yōu)先選經(jīng)廣泛認可的標準量表。
標桿對照 Benchmarking： 將實際或計劃的產(chǎn)品、過程和實踐，與其他可比組織的實戰(zhàn)進行比較，以便識別最佳實踐，形成改進意見，并為績效考核提供依據(jù)。標桿對照所采用的可比組織可是內(nèi)部的，也可以是外部的。
原型法 Prototyping： 指在實際制造預(yù)期產(chǎn)品之前，選造出該產(chǎn)品的模型，并據(jù)此征求對需求的早期反饋。原型包括微縮產(chǎn)品、計算機生成的二維和三維模型、實體模型或模擬。因為原型是有形的被我，它使得干系人呆以體驗最終產(chǎn)品的模型，而不是僅限于討論抽象的需求描述。原型法支持漸進明細的理念，需要經(jīng)歷從模型創(chuàng)建、用戶體驗、反饋收集到原型修改的反復循環(huán)過程。在經(jīng)過足夠的反饋之后，就可以通過原型獲得足夠的需求信息，從而進入設(shè)計或制造階段。
? ? ? ? 故事板是一種原型技術(shù)，通過一系列的圖像或圖示來展示順序或?qū)Ш铰窂?。故事板用于各種行業(yè)的各種項目中，如電影、廣告、教學設(shè)計以及敏捷和其他軟件開發(fā)項目。在軟件開發(fā)中，故事板使用實體模型來展示網(wǎng)頁、屏幕或其他用戶界面的導航路徑。
名義小組技術(shù)?Nominal group technique： 用于促進頭腦風暴的一種技術(shù)，通過投票排列最有用的創(chuàng)意，以便進一步開展頭腦風暴或優(yōu)先排序。名義小組是一種結(jié)構(gòu)化的頭腦風暴形式。其步驟包括以下四步：
- 向集體提出一個問題或難題，每個人在沉思后寫出自己的想法；
- 主持人在活動掛圖上記錄所有人的想法；
- 集體討論各個想法，直到全體成員達成一個明確的共識；
- 個人私下投票決出各種想法的優(yōu)先排序，通常采用5分制，1分最低，5分最高。
為了減少想法數(shù)量、集中關(guān)注想法，可進行數(shù)輪投票。每輪投票后，都將清點選票，得分最高者被選出。
聯(lián)合應(yīng)用程序開發(fā)或設(shè)計 JAD：適用于軟件開發(fā)行業(yè)。客戶被邀請和開發(fā)團隊一起，通過二系列的研討會收集需求和改進軟件開發(fā)的過程?？蛻舫掷m(xù)參與，有利于客戶充分了解項目并及時給出反饋，也有利于團隊更深入理解客戶的真實需求。
質(zhì)量功能展開 QFD：這個工具在新產(chǎn)品研發(fā)項目中很常用，可以把用戶需求轉(zhuǎn)化成產(chǎn)品功能，以便開發(fā)出最符合用戶需求的產(chǎn)品功能。質(zhì)量功能展開通常分為以下四個步驟：
- 第一步：產(chǎn)品規(guī)劃矩陣，把用戶需求轉(zhuǎn)化為設(shè)計要求。
- 第二步：零件規(guī)劃矩陣，把設(shè)計要求轉(zhuǎn)化為零件特性。
- 第三步：工藝規(guī)劃矩陣，把零件特性轉(zhuǎn)化為工藝要求。
- 第四步：工藝/質(zhì)量規(guī)劃矩陣，把工藝要求轉(zhuǎn)化為生產(chǎn)要求。
3.4 需求管理過程
? ? ? ? 需求管理中數(shù)據(jù)表現(xiàn)的工具有：親和圖、思維導圖。
3.4.1 親和圖
? ? ? ? 親和圖法被稱為KJ法。通過頭腦風暴法把收到的事實、意見和設(shè)想等語言文字資料，根據(jù)資料間的親和性將其歸類，以便從復雜現(xiàn)象中找出規(guī)律、抓住本質(zhì)、理出思路的一種方法。
? ? ? ? 再經(jīng)過分享、討論、投票待方式，根據(jù)需求間的親和性將其照著，形成若干組需求。
3.4.2 思維導圖
? ? ? ? 表達發(fā)散性思維的有效圖形思維工具，即運用圖文并重的技巧，把各級主題的關(guān)系用相互隸屬與相互關(guān)聯(lián)的層級圖表現(xiàn)出來，并把主題關(guān)鍵詞與圖像、顏色等建立記憶連接。
3.5 需求決策
? ? ? ? 當需求眾多，需要做出取舍，或者需要結(jié)合多人的意見做出決策時，通常采用以下決策技術(shù)：
投票：在進行投票之前，要先確定投票的原則。
- 一致同意原則：只有所有人同意，方案才能通過。該方案也叫“一票否決制”。
- 大多數(shù)同意原則：只要獲取通過半數(shù)或超過2/3 的得票，方案即可通過。
- 相對多數(shù)同意原則：多個方案中得票最多的勝出，不管得票是否超過半數(shù)。
獨裁：這種決策技術(shù)是由一個人做出最終決定，必要時可起到高效決策的作用。
多標準決策分析：在相互沖突的多方案中進行選擇，就是根據(jù)準則層的各項準則分別給方案層的各個方案打分，然后匯總分數(shù)，總分最高的方案勝出，成為目標方案。
3.6?需求文件
| 類別 | 定義 |
| 1 業(yè)務(wù)需求 | 整個組織的高層級需要。例如，解決業(yè)務(wù)問題或抓住業(yè)務(wù)機會，以及實施項目的原因。 |
| 2 干系人需求 | 干系人的需要。 |
| 3 解決方案需求 | 為滿足業(yè)務(wù)需求和干系人需求，產(chǎn)品、服務(wù)或成果必須具備的特性、功能和特征。 解決方案需求又進一步分為功能需求和非功能需求：
|
| 4 過渡和就緒需求 | 描述了從“當前狀態(tài)”過渡到“將來狀態(tài)”所需的臨時能力。如數(shù)據(jù)轉(zhuǎn)換和培訓需求。 |
| 5 項目需求 | 項目需要滿足的行動、過程和其他條件。例如里程碑日歷、合同責任、抽紙因素等。 |
| 6 質(zhì)量需求 | 用于確認項目可交付成果的成功完成或其他項目需求的實現(xiàn)的任何條件或標準。 |
?3.7?需求跟蹤矩陣
????????需求跟蹤矩陣是把產(chǎn)品需求從來源連接到能滿足需求的可交付成果的一種表格。使用需求跟蹤矩陣，把每個需求與業(yè)務(wù)目標或項目聯(lián)系起來，有助于確保每個需求都具有商業(yè)價值。需求跟蹤矩陣提供了整個項目生命周期中跟蹤需求的一種方法，有助于確保需求文件中被批準的每項需求在項目結(jié)束的時候都能交付。
????????需求跟蹤的內(nèi)容包括：（但不限于）
- 業(yè)務(wù)需要、機會、目的和目標；
- 項目目標；
- 項目范圍和WBS可交付成果；
- 產(chǎn)品設(shè)計；
- 產(chǎn)品開發(fā)；
- 測試策略和測試場景；
- 高層級需求到詳細需求。
? ? ? ? 需求跟蹤矩陣中記錄了需求的相關(guān)屬性，這些屬性有助于明確每個需求的關(guān)鍵信息。需求跟蹤矩陣中記錄的典型屬性包括唯一標識、需求的文字描述、收錄該需求的理由、所有者、來源、優(yōu)先級、版本、當前狀態(tài)（如進行中、已取消、已推遲、新增加、已批準、被分配和已完成）和狀態(tài)日期。為確保相關(guān)方滿意，可能需要增加一些補充屬性，如穩(wěn)定性、復雜性 和 驗收標準。需求跟蹤矩陣示例如下：（列有相關(guān)需求屬性）
| 需求跟蹤矩陣 | ||||||||
| 項目名稱： | ||||||||
| 成本中心： | ||||||||
| 項目描述： | ||||||||
| 標識 | 關(guān)聯(lián)標識 | 需求描述 | 業(yè)務(wù)需要、機會、目的和目標 | 項目目標 | WBS可交付成果 | 產(chǎn)品設(shè)計 | 產(chǎn)品開發(fā) | 測試案例 |
| 001 | 1.0 | |||||||
| 2.0 | ||||||||
3.8?敏捷場景下的需求管理
3.8.1 產(chǎn)品屬性
? ? ? ? 卡諾屬性也叫“狩野模型”，將產(chǎn)品屬性分為五類，如下圖所求：
- ?魅力屬性 Attractive：讓用戶喜出望外的屬性。即使產(chǎn)品不具備該屬性，用戶的滿意度也不會降低；而如果產(chǎn)品具備該屬性，用戶的滿意度會大幅提升。例如，對大都數(shù)用戶而言，手機的無線充電功能，屏幕可折疊待功能并不是非有不可，不過，假如手機有這些炫酷的功能，用戶還是很開心的。
- 期望屬性 One-Dimensional：也叫線性屬性，客戶滿意度與產(chǎn)品的屬性呈線性關(guān)系。例如，手機待機時間越長、手機的屏占比越大，用戶越滿意。
- 無差異屬性 Indifference：讓用戶不敏感的屬性。無論產(chǎn)品具備還是不具備，用戶的滿意度都不會改變。例如，手機的線路板是幾層的，絕大都數(shù)據(jù)用戶并不關(guān)心。
- 必備屬性 Must-Be：用戶對產(chǎn)品的基本需求。如果產(chǎn)品不具備，用戶滿意度就會大幅度降低，甚至無法接受。
- 反向?qū)傩?Reverse：用戶根本沒有此類需求。產(chǎn)品所具備的該類屬性越多，用戶就越不滿意。例如，手機里預(yù)裝的軟件越多，就越讓用戶討厭。
3.8.2 精益畫布
? ? ? ? 當企業(yè)有了一個很美妙的想法時，很多企業(yè)會按照流程要求編制內(nèi)容翔實的商業(yè)計劃書、可行性研究報告。長達幾十頁甚至上百頁的報告往往要花幾周甚至幾個月的時間。而在精益創(chuàng)業(yè)模式中，使用一張精益畫布就可以解決這個問題。
? ? ? ? 精益畫布是從商業(yè)模式畫布中發(fā)展而來的（如上圖），包含9個部分，如下圖所示：（老人打車精益畫布）
| 2 用戶痛點
| 3 解決方案
| 4 價值主張
| 9 競爭壁壘
| 1 用戶細分
|
| 8 關(guān)鍵指標
| 5 市場渠道
| |||
| 7 成本結(jié)構(gòu)
| 6 收入來源
| |||
3.8.3 最小可發(fā)布版本
? ? ? ? 產(chǎn)品開發(fā)經(jīng)歷漫長的過程。對于創(chuàng)新產(chǎn)品來說，如果企業(yè)沒有發(fā)布過一個版本，就沒法驗證這款產(chǎn)品到底有沒有真正的客戶。
? ? ? ? 雖然在商業(yè)論證階段，產(chǎn)品創(chuàng)意已經(jīng)通過最小可行性產(chǎn)品（Minimum Viable Product, MVP）被驗證過了，但MVP和真正的產(chǎn)品不同，MVP是驗證假設(shè)的試驗品，而MMR是真正的可以被客戶購買的產(chǎn)品。企業(yè)沒生產(chǎn)出真正的產(chǎn)品，只是用MVP驗證出客戶的“購買意愿”，并不代表客戶見了產(chǎn)品后會真的購買。
? ? ? ? 團隊需要從產(chǎn)品待辦事項列表中精挑細選出最有價值的特性，并做出一個成本最小的產(chǎn)品迅速投放到市場上。
? ? ? ? MMR原則如下：
- 最簡特性清單：依據(jù)精益畫布，放棄不屬于核心價值主張的特性； 依據(jù)卡諾模型，舍棄產(chǎn)品非必需的特性。團隊針對每個特性都要問自己：沒有它會怎么樣？如果沒有它并不影響用戶使用，那么它就不應(yīng)該出現(xiàn)。
- 最小特性顆粒：盡力把產(chǎn)品特性拆分出子特性，一直拆分到不能拆分為止（如果繼續(xù)拆分，就無法為用戶提供獨立的價值）。
- 最少特性組合：根據(jù)莫斯科法則（MoSCoW），把梳理出來的特性清單進一步排優(yōu)先級，只開發(fā)最基本的特性，也就是產(chǎn)品必須有的特性。
????????莫斯科法則（MoSCoW）如下：
- 必須有的特性：如果沒有，產(chǎn)品不可行。
- 應(yīng)該有的特性：非常重要但不是必需的特性，可以想其他方法替代或暫時不提供。
- 可以有的特性：有了更好，沒有也行。只有在時間允許，資源充裕的情況下，企業(yè)才會考慮。
- 不該有的特性：不關(guān)鍵、不必要，且不該在這個版本里考慮的特性。
3.8.4 產(chǎn)品待辦事項列表
????????產(chǎn)品待辦事項列表的特征如下。
- 詳圖適當：優(yōu)先級越高的待辦事項，其描述越詳細； 反之，描述越簡略。
- 經(jīng)過估算：產(chǎn)中待辦事項列表中的條目是經(jīng)過估算的，這些估算是粗顆粒度的，通常以故事點或者理想人天的形式表達。
- 涌現(xiàn)的：產(chǎn)中待辦事項列表中的條目是動態(tài)的，不斷演化的。根據(jù)客戶和用戶的反饋，隨時增減和調(diào)整待辦事項列表優(yōu)先級，并且，現(xiàn)有的條目可以不斷被修訂、細化，甚至移除。
- 按優(yōu)先級排序：最重要的事項優(yōu)先級最高，排在產(chǎn)品待辦事項列表的最項層，最先被實施。
3.8.5 分解和細化產(chǎn)品待辦事項列表中的條目
????????如下圖所示，在下一次迭代開始之前，雖然產(chǎn)品負責人應(yīng)當準備好足夠多的細顆粒條目，但不必把所有條目都分解細化，這樣做的目的是把花費在描述產(chǎn)品上的時間和資源降到最低。因為條目是動態(tài)的，變化的，所以分解和細化條目的工作也是周期性的。?
? ? ? ?如果產(chǎn)品待辦事項列表中有同樣重要的活動，那么團隊應(yīng)該先做哪個呢？
? ? ? ? 我們可以采取WSJF原則，即“最短作業(yè)優(yōu)先”原則。公式“WSJF = 延期滿足的代價 / 這項活動的歷時估算” 計算每項活動WSJF 的分數(shù)，分數(shù)最高的活動就是我們應(yīng)該優(yōu)先做的。
3.8.6 用戶故事
? ? ? ? 用戶故事是一個表述用戶需求的固定語法：作為一個<角色>，我想要<活動>，以便于<商業(yè)價值>。
? ? ? ? 通常團隊在識別用戶需求時，會用便利貼按照上述語法把用戶的需求表達出來，用于看板或產(chǎn)品待辦事項列表分析。
四、定義范圍
? ? ? ? 定義范圍是制定項目和產(chǎn)品詳細描述的過程。這個過程主要作用是明確所收集的需求哪些將包含在項目范圍內(nèi)，哪些將排隊在項目范圍外，從而明確項目、服務(wù)或成果的邊界。
? ? ? ? 完整、準確地定義aifl通常是項目成功的前提。范圍說明書是定義范圍過程的最重要的成果。
4.1 作用
本過程的主要作用是：描述產(chǎn)品、服務(wù)或成果的邊界和驗收標準。
本過程需要的整個項目期間多次反復開展。
4.2 項目范圍說明書
? ? ? ? 項目范圍說明是對項目范圍、主要可交付成果、假設(shè)條件和制約因素的描述。項目范圍說明書詳細描述了項目的可交付成果，以及團隊為創(chuàng)建這些可交付成果而必須開展的的工作，也代表了項目相關(guān)方之間就項目范圍所達成的共識。
? ? ? ? 項目范圍說明書是對項目范圍、主要可交付成果、假設(shè)條件和抽紙因素的描述：
1. 產(chǎn)品范圍描述：逐步細化在項目章程和需求文件中所述的產(chǎn)品、服務(wù)或成果特征。
????????
2. 可交付成果：為完成某一過程、階段或項目而必須產(chǎn)出的任何獨特并可核實的產(chǎn)品、服務(wù)能力或成果，可交付成果也包括輔助成果，如項目管理報告和文件。對可交付成果的描述可略可詳。
????????
3. 驗收標準：可交付成果通過驗收前必須滿足的一系列條件。
????????
4. 項目除外責任：識別排除在項目之外的內(nèi)容。明確說明哪些內(nèi)容不屬于項目范圍，有助于管理干系人的期望及減少范圍蔓延。
????????
5. 制約因素：對項目或過程的執(zhí)行有影響的限制性因素。列舉并描述與項目范圍有關(guān)且會影響項目執(zhí)行的各種內(nèi)外部制約或限制條件，如客戶或執(zhí)行組織事先確定的預(yù)算、強制性日期或進度里程碑。如果項目是根據(jù)協(xié)議實施的，那么合同條款通常也是制約因素。關(guān)于制約因素的信息可以列入項目范圍說明書，也可以獨立成冊。?
????????
6. 假設(shè)條件：在制訂計劃時，不需要驗證假設(shè)條件即可將其視為正確、真實或確定的因素。同時還應(yīng)描述如果這些因素不成立，可能造成的潛在影響。在項目規(guī)劃過程中，項目團隊應(yīng)該經(jīng)常識別、記錄并確認假設(shè)條件。假設(shè)條件的信息可以被列入項目范圍說明書，也可以獨立成冊。
? ? ? ? 雖然項目章程和項目范圍說明書的內(nèi)容存在一定程度的重疊，但它們的詳細程度完全不同。項目章程包括高層級的信息，對項目范圍的初步表述，除方向的重大變更外，一般項目章程一經(jīng)制定，就不能頻繁地理性項目范圍的表述，而項目范圍說明書則是對范圍組成部分的詳細描述，這些組成部分需要在項目過程中漸進明細；項目章程是項目范圍說明書制定的重要依據(jù)，而項目范圍說明書需要隨項目的發(fā)展動態(tài)更新維護，漸進明細。就項目范圍而言，項目范圍說明書是對項目章程的細化和具體化。
五、創(chuàng)建WBS
? ? ? ? 創(chuàng)建工作分解結(jié)構(gòu)（WBS）是把項目可交付成果和項目工作分解成較小的、更易于管理的組件的過程。
5.1 作用
本過程的主要作用是：為所要交付的內(nèi)容提供架構(gòu)。
本過程僅開展一次或僅在項目的預(yù)定義點開展。
5.2 分解的基本概念
????????簡單來說，分解就是把一個項目，按一定的原則分解，項目分解成任務(wù)，任務(wù)再分解成一項項工作，再把一項項工作分配到每個人的日常活動中，直到分解不下去為止。
? ? ? ? 分解是一種把范圍和項目可交付成果逐步劃分為更小、更便于管理的組成部分的技術(shù)。
? ? ? ? 工作包是WBS最低層的工作，可對其成本和持續(xù)時間進行估算和管理。分解的程度取決于所需的控制程序，以實現(xiàn)對項目的高效管理。
? ? ? ? 工作包的詳細程度因項目規(guī)模與復雜度而異。
5.3 分解步驟
- 識別和分析可交付成果及相關(guān)工作；
- 確定WBS的結(jié)構(gòu)與編排方法；
- 自上而下逐層細化分解；
- 為WBS組成部分制定和分配標識編碼；
- 核實可交付成果分解的程度是否失當；
5.4 WBS元素
? ? ? ? WBS包含如下幾種元素。
1. 可交付成果
? ? ? ? 可交付成果是團隊為完成某一過程、階段或項目而必須產(chǎn)出的任何獨特并可核實的產(chǎn)品、成果或服務(wù)能力，其包括各種輔助成果，如項目管理報告和文件?？山桓冻晒拿枋隹陕钥稍?。
????????
2. 子項目
? ? ? ? 子項目是整個項目的一部分。一個子項目是能夠被相對獨立地作為“項目”來管理的，可由一個專業(yè)團隊或一個分包組織負責。
????????
3. 控制賬戶
? ? ? ? 控制賬戶是一個管理控制點。在該控制點上，把范圍、預(yù)算、實際成本和進度加以整合，并與掙值相比較，以測量績效。
????????
4. 工作包
? ? ? ? 工作包是WBS中最低層次的組件，通常表達為可交付成果。工作包可以對相關(guān)活動進行歸類，以便對工作進度進行估算，開展監(jiān)督與控制。
????????
5. 規(guī)劃包
? ? ? ? 規(guī)劃包也是WBS的最低層次的組件，位于控制賬戶之下。它的工作范圍是已知的，但所包含的活動或?qū)?yīng)的工期和預(yù)算是當前未知的，需要隨項目的深入進一步確定。
????????
6. 活動
? ? ? ? 活動是工作包的組成部分，不屬于WBS組件。活動描述中包含一個表示其動作的動詞，如“開發(fā)微信支付接口”。一個活動通常有期望持續(xù)時間、期望成本、期望資源需求。活動經(jīng)常被細分為任務(wù)。????????
7. 任務(wù)
? ? ? ? 任務(wù)通常是活動進一步分解的組成部分，不屬于WBS組件，由某個團隊成員負責。
? ? ? ? WBS分解的100%原則：一個WBS元素的下一層分解（子層）必須百分之百地表示上一層（父層）元素的工作，不能有重復，更不能有遺漏。
5.4 WBS結(jié)構(gòu)
- 將項目生命周期的各階段作為分解的第二層，把產(chǎn)品和項目可交付成果放第三層。
- 主要可交付成果作為分解的第二層
- 分解的兩種表現(xiàn)形式
分組的樹形結(jié)構(gòu)（小型項目），特點：WBS層次清晰，非常直觀，結(jié)構(gòu)性很強。
5.5 WBS字典
| WBS編碼 | 縮寫 | 描述 | 標準 | 歷時 | 費用 | 負責人 | 依賴 |
| 1.1.1.0 | EA | 這個元素包含可交付成果的培訓服務(wù)、手冊，復檢，培訓幫助和培訓設(shè)備，用來指導客戶最大效率地學習怎樣操作和維護系統(tǒng)。 | CS13 | 3M? | ～50K | 李四 | 系統(tǒng)部署完成 |
? ? ? ? WBS字典是針對WBS中每個組件，詳細描述可交付成果、活動和進度信息的文件。
? ? ? ? WBS字典對WBS組成部分（包括工作包和控制賬戶）進行更詳細的描述。
? ? ? ? WBS字典中的內(nèi)容可能包括（但不限于）：
- 賬戶編碼標識
- 工作描述
- 假設(shè)條件和制約因素
- 負責的組織
- 進度里程碑
- 相關(guān)的進度活動
- 所需資源
- 成本估算
- 質(zhì)量要求
- 驗收標準
- 技術(shù)參考文獻
- 協(xié)議信息
5.6 控制賬戶
- 控制賬戶是一個管理控制點。
- 在該控制點上，把范圍、預(yù)算和進度加上整合，并與掙值相比較來測量績效。
- 控制賬戶包含兩個或更多工作包，每個工作包只與一個控制賬戶關(guān)聯(lián)。
- 項目管理實踐中，通?？刂瀑~戶和專業(yè)相對應(yīng)。
5.7 規(guī)劃包
- 規(guī)劃包是一種低于控制賬戶而高于工作包的工作分解結(jié)構(gòu)組件，工作內(nèi)容已知，但詳細的進度活動未知。
- 一個控制賬戶可以包含一個或多個規(guī)劃包。
- 由于當前無法分解到編制項目管理計劃所需要的詳細程度，規(guī)劃包是暫時用來做計劃的。
- 隨著情況的逐漸清晰，規(guī)劃包最終被分解成工作包以及相應(yīng)的具體活動。
5.8 工作包的分解原則
- WBS必須是面向可交付成果的。
- WBS必須符合項目的范圍。（100%原則）
- WBS的底層應(yīng)該支持計劃和控制。
- WBS中的元素必須有人負責，而且只有一個人負責。
- WBS控制在4～6層：如果項目規(guī)模比較大，以至于WBS要超過6層，此時，可以使用項目分解結(jié)構(gòu)將大項目分解成子項目，然后針對子項目來做WBS。
- WBS應(yīng)包括項目管理工作，也要包括分包出去的工作。
- WBS的編制需要所有（主要）項目干系人的參與。
- WBS并非是一成不變的。
5.9 范圍基準
5.10 WBS的價值
? ? ? ? WBS的價值體現(xiàn)在以下五個方面。
1. 基準的來源
? ? ? ? 范圍基準是三大基準之首。有了范圍，我們才能確定進度基準和成本基準。
????????
2. 計劃的基礎(chǔ)
? ? ? ? 項目進度、成本、質(zhì)量、風險等所有計劃都要依據(jù)基準來編制。
????????
3. 工作的展現(xiàn)
? ? ? ? WBS把項目所涵蓋的工作分層次、結(jié)構(gòu)化地展現(xiàn)出來。
????????
4. 控制的依據(jù)
? ? ? ? 該項工作是否應(yīng)該做，要對照范圍基準，如果范圍基準里沒有，就不應(yīng)該做。
????????
5. 團隊的指南
? ? ? ? 團隊根據(jù)WBS來確定工作的目標和分工。
六、確認范圍
? ? ? ? 確認范圍是獲得項目發(fā)起人或客戶對項目可交付成果正式驗收的過程。通過項目過程中發(fā)起人或客戶持續(xù)性地驗收每個可交付成果，可以保障最終產(chǎn)品、服務(wù)或成果獲得驗收。
6.1 作用
- 使驗收過程是有客觀性。
- 通過確認每個可交付成果來提高最終產(chǎn)品、服務(wù)或成果獲得驗收的可能性。
確認范圍過程應(yīng)該根據(jù)需要在整個項目期間開展。
? ? ? ? 由主要干系人，尤其是客戶或發(fā)起人審查從控制質(zhì)量過程輸出的核實的可交付成果，確認這些可交付成果已圓滿完成并通過正式驗收。
6.2 確認范圍的步驟
- 確定需要進行范圍確認的時間；
- 識別范圍確認需要哪些投入；
- 確定范圍正式被接受的標準和要素；
- 確定范圍確認會議的組織步驟；
- 組織范圍確認會議。
6.3 需要檢查的問題
? ? ? ? 項目干系人進行范圍確認時，要檢查的內(nèi)容：
- 可交付成果是否確定的、可確認的。
- 每具可交付成果是否有明確的里程碑，里程碑是否有明確的、可辨別的事件，例如，客戶的書面認可等。
- 是否有明確的質(zhì)量標準。
- 審核和承諾是否有清晰的表達。
- 項目范圍是否覆蓋了需要完成的產(chǎn)品或服務(wù)的所有活動，有沒有遺漏或錯誤。
- 項目范圍的風險是否太高，管理層是否能夠降低風險發(fā)生時對項目的影響。
6.4 干系人關(guān)注點的不同
- 管理層主要關(guān)注項目范圍：是指范圍對項目的進度、資金和資源的影響，這些因素是否超過了組織承受范圍，是否在投入產(chǎn)出上具有合理性。
- 客戶主要關(guān)注產(chǎn)品范圍：關(guān)心項目的可交付成果是否足夠完成產(chǎn)品或服務(wù)。
- 項目管理人員主要關(guān)注項目制約的因素：關(guān)心項目可交付成果是否足夠和必須完成，時間、資金和資源是否足夠，主要的潛在風險和預(yù)備解決的方法。
- 項目團隊成員主要關(guān)注項目范圍中自己參與的元素和負責的元素：通過定義范圍中的時間檢查自己的工作時間是否足夠，自己的項目范圍中是否有多項工作，而這些工作是否有沖突的地方。
6.5 可交付成果的演變
- 可交付成果：指導與管理項目工作
- 控制質(zhì)量：核實的可交付成果
- 確認范圍：驗收的可交付成果
- 結(jié)束項目或階段：最終的產(chǎn)品、成果或服務(wù)
6.6 質(zhì)量控制和范圍確認
? ? ? ? 確認范圍，關(guān)注可交付成果的驗收。
? ? ? ? 控制質(zhì)量，關(guān)注可交付成果的正確性及是否滿足質(zhì)量要求。
? ? ? ? 控制質(zhì)量過程通常先于確認范圍過程，但二者也可同時進行。
6.7 其它知識點
? ? ? ? 核實的可交付成果：指已經(jīng)完成，并被控制質(zhì)量過程檢查為正確的可交付成果。
? ? ? ? 驗收的可交付成果：由客戶或發(fā)起人正式簽字批準。應(yīng)該從客戶或發(fā)起人那里獲得正式文件，證明干系人對項目可交付成果的正式驗收。這些文件將提交給結(jié)束項目或階段過程。
七、控制范圍
? ? ? ? 控制范圍是監(jiān)督項目和產(chǎn)品的范圍狀態(tài)，管理范圍基準變更的過程。
7.1 作用
- 在整個項目期間保持對范圍基準的維護，并確保所有變更請求、糾正措施或預(yù)防措施都通過實施整體變更控制程序進行處理。
本過程需要在整個項目期間開展。
7.2 范圍蔓延
未經(jīng)控制的產(chǎn)品或項目范圍的擴大（未對時間、成本和資源做相應(yīng)調(diào)整）被稱為范圍蔓延。
- 狹義的范圍蔓延：在客戶要求下，未經(jīng)正常的范圍變更控制程序而出現(xiàn)的產(chǎn)品或項目范圍的擴大，也叫“范圍爬行”。
- 鍍金：廣義范圍蔓延的一種，指在定義范圍的工作范圍以外，項目團隊主動增加的額外工作，但沒有經(jīng)過范圍控制程序。
不管鍍金還是范圍爬行，共同點者是沒有經(jīng)過整體變更控制程序而發(fā)生了范圍變化。統(tǒng)稱“范圍蔓延”。