SCRUM 手法介紹
前言
SCRUM不只是觀念的創新，它還提出有很多的手法(Tools，我實在不願意翻譯成【工具】)，應用在生命週期的各個階段，有些還蠻有趣的，本文試著整理一些供大家品一品。
有關SCRUM觀念的介紹請參考筆者上一篇PO文。
以下即依生命週期先後順序說明各個手法。
圖一、SCRUM 生命週期
用戶故事(User Story)
在產品待交事項(Product Backlog)的文件中，產品負責人(Product Owner)定義產品的功能及特色(Features)，每項功能描述均以用戶故事(User Story)說明。
用戶故事類似UML的Use Case擔任的角色，但它只定義功能，不描述細節，尤其是控制流程(與30年前【結構化分析與設計方法】相同，只談What，不談How?)，撰寫語法如下:
"As a <role>, I want <goal/desire> so that <benefit>/<reason>"例如，我們在會計總帳系統中作如此描述會計人員必須每日將當天傳票過帳，以利會計主管掌握財務即時狀況。或者在網站系統開發時，作如下描述使用者進入客戶服務網頁前，必須先登入，以便將Ticket與客戶連結，確保後續處理，能有效通知客戶。
- 撰寫用戶故事的六大原則 INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)，詳見Mike Cohn, User Stories for Agile Requirements 一書。 注意Negotiable，不假設需求一經確認即凍結，因為SCRUM不認為任何一位專案成員一開始就完全掌握細節，只有後續不斷的討論與改進，需求才能真正被挖掘與實現。
- 每個用戶故事必須包含驗收條件(Acceptance Criteria)或測試條件，這就是TDD/BDD的精神，先撰寫Test Case，再開始寫程式。
- 針對每個用戶故事估算出完成所需的故事點數(Story Points)，一個故事點可以是一個人天(Man Day)或人時(Man Hour)。
- 將所有用戶故事依重要性排列出後續開發的優先順序。
索引卡(Index Card)
產品負責人以用戶故事定義出系統開發範圍及所需工作人日後，專案團隊是否就依產品負責人所規劃的進度開始工作呢？答案是否定的，我們常說專案成敗是專案成員共同的責任，但是如果專案成員只是聽命行事，他們為什麼要承擔這個責任呢？因此，建議作法是將用戶故事製作成一張張的索引卡，上面記載內容如下，然後，將它們全部貼在任務牆(Task Board or Kanban Board )上。
圖二、索引卡，(註一)
圖三、任務牆，來源：http://www.xqa.com.ar/visualmanagement/2009/06/kanban-boards/
產品負責人說明各個用戶故事，然後由專案成員共同決定每個用戶故事的確切工時，並可直接在任務牆上移動索引卡，調整開發的優先順序，產品負責人不得干涉，只能在最後結果出爐後，再修改或拆分系統範圍或優先等級，使SCRUM團隊重新考慮某些用戶故事是否能提早執行。
撲克牌遊戲(Planing Poker)
SCRUM團隊成員如何決定用戶故事的確切工時呢？為避免成員【嚴以律人、寬以待己】，將自己的工作寬估，別人的工作估得很緊，此時可使用撲克牌遊戲，投票決定工時，大家針對每一次用戶故事估計，挑選一張牌，代表故事點數，所有人一起亮牌，若差異過大，須再說明、討論或拆分用戶故事，直到達成共識為止。撲克牌如下，一人一份，其中一張牌是咖啡杯，表示【太累了，喝杯咖啡再討論吧】。
圖四、撲克牌遊戲(Planing Poker)，(註一)
Sprint任務牆
在Sprint規劃會議中，決定當次Sprint要完成的事項，即Sprint Backlog，一樣用索引卡將工作項目貼到任務牆上，只是歸類方式改變了，主要分為【未開始進行(Not checked out)】、【已開始進行(Checked out)】、【已完成(Done)】，一開始工作項目全部在左邊，專案開始進行後就逐步向右移，這樣每天進度就一目了然。
圖五、Sprint任務牆，(註一)
燃盡圖(Burndown Chart)
圖五右上方貼著一張線圖，即燃盡圖，灰線代表預計待處理的工作數(以故事點計)，藍線代表實際執行的狀況，SCRUM提出一個有趣的觀點，報告的重點在於【還有多少工作未完成】而非【已完成了哪些工作】，因此圖六左邊，藍線在灰線上方代表待作事項超過預期，進度落後，反之右邊表進度超前。
圖六、燃盡圖，(註一)
另外，Bug的管理也可以用燃盡圖表示，若待處理的Bug數量愈來愈多，那專案就危險了。
站立會議(Stand-up Meeting)
每日例會(Daily SCRUM Meeting)規定在15分鐘內結束，為確保大家不會歹戲拖棚，規定所有人都必須罰站開會，而且只能報告三件事：
1. 昨天完成的工作
2. 今天打算做甚麼？
3. 要完成目標，是否存在什麼障礙？
這一招難度很高，要是碰到當過憲兵的年輕人或喋喋不休的老頭子(is it me?)，罰站再久，也不管用。
結語
以上這些手法是不是像救國團的團康活動？SCRUM就是要藉由這些手法達到全員參與，這樣談【專案成敗，人人有責】才有意義。SCRUM方法知易行難，要有決心與執行力，才能在不斷的調整後，變成一隊攻無不克的團隊吧。
註一、圖片來源主要是出自 Henrik Kniberg，Scrum And XP From The Trenches 一書
