歪歪凍的細細私語

[PMBOK Guide 4th,104]

根據PMBOK的定義，範疇管理共有以下5個流程

1. 蒐集需求 (Collect Requirements)
2. 定義範疇 (Define Scope)
3. 建立WBS (Create WBS)
4. 驗證範疇 (Verify Scope)
5. 控制範疇 (Control Scope)

 

蒐集需求及定義範疇

在Scrum專案中，唯一能提出需求的人即是Product Owner(PO)。依專案的特性不同，PO通常是由客戶代表、產品經理或內部某個了解需求的人來擔任。由單一窗口的PO來向各個利害關係人蒐集及統整需求，再由他來負責決定每件事情的優先順序。當然，需求可以在排入Sprint Plan之前不斷的變化及調整，並記錄在Product Backlogs之中。Scrum的Product Backlogs通常是以User story的方式來紀錄功能性及非功能性的每個需求。User Story並非是規格文件，它通常就僅只是一句單純的描述，像是As a [user role], I need [some business value] so I want [some feature]，重點在於只描述透過系統想達成的事情及目的為何，至於詳盡的細節，則會「恰好及時」地等到Sprint Planning Meeting時才透過口頭的溝通來理解。

 

建立WBS

Scrum專案中並不建立WBS，雖然它有看起來長的有幾分相似的Taskborad。Taskborad與WBS的差別在於Taskborad是直接將User Story細分至要完成這個Story所需要進行的工作，這裡的工作是等同於PMBOK中的活動。由於一個Sprint中規劃可完成的User Story數量有限，因此可大幅減少規劃時所需花費的思考心力，所以無需對User Story先做分解的動作便可完成規劃。

 

驗證範疇

經Sprint Planning Meeting過後，從Produect Backlogs移至Sprint Backlogs的User Story通常會再加上該Story完成的定義 (Definition of Done, DoD)或是Review Meeting時該如何Demo的描述。因此範疇驗證的工作將會在Sprint當中由團隊自行對成果的驗證以及Review Meeting時，PO欣賞團隊Demo本次Sprint成果時進行。

 

控制範疇

敏捷專案並不存在「控制」這個字眼，對於需求變更，PO可以隨時添加、移除或異動在Product Backlogs中的User Stroy，並且調整它們的優先順序，好讓重要的Story能排進到下一個Sprint之中。