專案管理新思維"Scrum"的運用

前言

傳統專案管理是早期擬定計畫，並依據此計畫執行及持續追蹤紀錄，以達成專案目標。但缺點在於專案從發起之初到專案交付成果出爐，可能會產生成果與預期有落差，但時間與人力已經付出，專案卻需重頭來過。因此敏捷式專案管理( Agile Project Management) 就是在這樣的背景下應運而生。其透過較短的專案周期和漸進式的需求分析、交付成果驗收等方式，逐步完善所有專案計畫與需求來進行專案管理。Agile管理中又以”Scrum”為近期最為火紅的一支管理方法。其最早應用於軟體開發產業上，目前已有開始應用到其他非資訊科技專案的案例。

甚麼是Scrum

Scrum字面上的意思指的就是【美式足球的爭球】，它就像是美式足球希望能夠在每一段時間的衝刺(Sprint)中，透過每一小段的推進而逐漸接近球門，進而達陣得分。它對於專案的意義在於利用現有的需求資訊(即使它是不明確且不完整)，有策略的制定衝刺方向及依重要性進行排序，並透過每次衝刺期達成短期目標。而更重要的是，在每次衝刺期內不任意添加新的想法、不修改當下執行方向、也不加開不必要的會議，直到完成眼前的短期目標再說。如此專案能在較快的時間內產出成品，再逐步修正。

Scrum的參與角色

在Scrum的管理方法中，總共有四種角色：

Stakeholder (使用者)

其負責提供需求，也就是專案中”老闆上司”或”業主客戶”。在Scrum中，又稱需求為故事(Story)。

Product Owner (PO)

整個專案團隊的負責人。定義產品需求，負責產品成敗。Product Owner 顧名思義就是『產品擁有者』，有些專案把 PO 稱之為『Product Manager』。PO要負責與Stakeholder溝通，並將其需求（Story），轉換為需求清單(Product Backlog)、並依據重要性進行排序(Priority)，交給專案成員執行。若當成員對於需求不清楚的時候，要負責回答問題與釐清需求。

Scrum Master

Scrum Master它不是執行者，而是教練和團隊帶領人，其通常需要較深的經驗與技術知識背景。它主要工作是協助團隊依循 Scrum 的精神來進行專案，並協助團隊改善專案執行流程，排除任何阻礙專案進行的事件（例如，不必要的會議與來自老闆突發奇想的干擾）。因此Scrum Master是扮演「牧羊犬」的角色，避免羊群（專案成員）受到「大野狼」（外來因素）的騷擾 。

Scrum Team Member

真正專案執行的人員。Scrum強調團隊成員應該是由「跨職能成員」(cross-functional team)組成。翻成白話文就是說，完成某項功能或是某個專案所需要的人才，全部都拉到同一個團隊裡面。

簡單來說，Product Owner決定做什麼(what)，Team member 決定如何做及可以做多少 (how & how much)，而 Scrum Master 是整個管理流程的主導人，它並不直接執行專案，而是負責讓專案能依循Scrum 的精神來執行專案，更重要的是阻止一切破壞團隊自我管理機制的外來力量，這是一般專案管理沒有的角色。

Scrum的流程

在了解其流程前，有幾個重要名詞需要特別了解：

Product Backlog

指的是使用者的需求清單。通常由Product Owner排定好重要性和預計完成時間。

Sprint Planning Meeting

在執行每次的Sprint之前所召開的會議，用來決定這次的Sprint要完成的工作(Sprint Backlog)

Sprint Backlog

每一個Sprint需要完成的工作清單

Sprint

將整個專案週期切分成許多較小的衝刺期（Sprint），意義就在於衝刺期內就不要再修改或任意繼續添加新需求，以先完成此次衝刺為目標。一個工作週期，通常為期一到四週。

Daily Scrum Meeting

Scrum強調沒事少開會、少開會沒事。因此會議通常是在每天開始工作前會舉行，時間大約為15分鐘左右。大家各自簡短報告就好，而且要站著報告。因為必須是站著，大家才會想儘快結束，又稱站立會議。其主要討論的內容為：

• 昨天完成什麼
• 今天要作什麼
• 遭遇到什麼困難

Sprint review meeting

最主要的用意就是用來與stake-holders交流，並且展示team所要交付的成果，而這個會議通常是由Product owner主導，展示以下內容：

• 展示團隊成員承諾要交付的工作項目
• 展示團隊成員完成了什麼工作（有達到哪些目標，有哪些沒有達到）
• 在Sprint中間有達成什麼重要的決定（不管是技術、需求…等）
• 展示現階段專案交付的標的物到什麼程度，並展示初步成果(Demo)
• 工作項目優先順序檢討（為了下一次的sprint）

Retrospective Meeting

參與的主要成員為Team member和Scrum Master，其重點則是讓團隊成員檢視Sprint的實作施行流程，並對其提出流程改善的建議。

圖一即是Scrum的運作流程。透過此圖，我們更可以了解上述參與角色與重要名詞的意義：

• Stakeholder向Product Owner提出自己的需求。
• Product Owner將需求轉換為Product Backlog。
• 透過Sprint Planning Meeting後，將Product Backlog轉換為Sprint Backlog 。
• 在每一次的Sprint中，按照優先順序，進行一次Sprint（衝刺）。
• 每次的衝刺中，都會進行Daily Scrum Meeting，確保進度。
• 完成產出後，透過Sprint review meeting，由Product Owner來驗收成果。
• 整個Scrum流程做完後，進行Retrospective Meeting，檢討整個流程需要改進之處。

而與傳統專案管理相比，Scrum不僅涵蓋預估(story point)、實作(sprint)、監控(daily scrum)和修正(retrospective meeting)，更因執行流程類似湧浪式規畫法(Rolling Wave Planning)：專案執行流程是反覆數次，每次都是根據前一次的結果並結合最新的需求進行，並增量交遞目標物(incremental delivery)以逐步完善。因此適合用於需快速反應需求改變以及時間緊迫的管控模式。

雙重回饋機制

Scrum 的流程中，與傳統專案管理最大的差異之一，就是Scrum擁有雙重回饋機制。

由 圖二可知，每個Sprint是透過Sprint Planning Meeting及Sprint Review Meeting的討論，確認執行方向。其中Sprint planning meeting事實上會分成兩個部分part 1和part 2。

• Part 1的重點是在於這次的Sprint要做甚麼(What to do)。參加成員為Product owner (PO)、Scrum master (SM)和Team member。會議將由PO主導，討論的內容為這個Sprint該從Product backlogs中挑選哪些Story來完成。 並由PO一一的來說明相關細節部分。
• Part 2的的重點在Sprint要如何做(How to do)。參加成員為SM和Team member。討論的內容為這些Story該如何分解為Task，以及Task的實作細節和預估該花費的工時等等。

而在每個Sprint結束之前，則會有所謂的review。同樣的，review亦分為兩個部分：Review meeting和Retrospective Meeting。

• Review Meeting的重點在於讓PO檢視這個Sprint所產出的成果，如果有任何不符合需求或是需求變動，便會被記錄下來，加至Product backlogs當中，好讓後續的Sprint能夠處理解決。
• 而Retrospective Meeting的重點則是讓團隊成員檢視Sprint的實作施行流程，並對其提出流程改善的建議。

由此可知Review Meeting是針對標的物的品質回饋，Retrospective Meeting則是針對流程的品質回饋。因為有雙回饋機制，才能在快速適應變化的情況下確保專案整體的品質。

Scrum的進度管理工具

為了管理方便，在專案過程中，會透過下列工具來幫助了解專案執行進度：

Task Board

用來確認工作完成狀況的表格。實際上許多人會用有顏色的便利貼來區分，不同的顏色代表不同的工作或不同的負責人，跟一般常用的工作待辦事項(To do list)相比，能更清楚知道專案團隊成員的各自工作執行狀況及進度 圖三。

Burn Down Chart

像是進度S曲線(S-curve)，用來監控專案進度的表格，X軸是時間，Y軸是專案總時程或總工作數目。理想中的走勢應該是像綠色線一樣的斜率，但是實際執行時，通常會有出入，可能會像藍色摺線一般，可以用來觀察專案的走勢 圖四。

結論

近年來，相關的Agile專案管理大行其道，連美國國際專案管理師協會(PMI)日前也開始增加敏捷式專案管理認證PMI-ACP (Agile Certified Practitioner)。其中Scrum相較其他專案管理模式，其著重於成員高度參與，強調的是自我管理(Self-organizing Team)及跨領域團隊(Cross-functional Team)。在對於重複性高、專業性強的專案，能透過其管理流程，有效率的組成能協同作業、有共同價值的團隊，進而較能快速產出標的物。

若將其模式套用於新廠興建的流程中，Facility Department、IE、AMHS、Warehouse等單位等同Stakeholder，其提出使用需求；而PO這個角色則是新工處的Planner或PM，負責與上述使用者溝通，整理需求及決定可以做的範圍(what)；而各系統負責人及廠商則是Team Member，則在有限資源下，決定執行方案，也就是決定如何做(how)及做多少(How much)。若能再加上Scrum Master這角色，來推動專案管理流程的導入，如同專案教練，讓快速成軍的專案成員容易進入流程，縮短學習時間又可累計管理知識。或許在末來專案執行上可參考其模式，使專案更為確實掌握進度及執行更為順利。