iT邦幫忙

DAY 8
3

PMP的敏捷之路系列 第 8

PMP的敏捷之路-範疇管理

九大知識領域之二-範疇管理

[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 (role of user), I want (some feature) so that (some business value),重點在於只描述透過系統想達成的事情及目的為何,至於詳盡的細節,則會「恰好及時」地等到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之中。


上一篇
PMP的敏捷之路-整合管理
下一篇
PMP的敏捷之路-Timebox
系列文
PMP的敏捷之路30

尚未有邦友留言

立即登入留言