SCRUM 初探
SCRUM實在太夯了，最近報章雜誌報導手機應用開發團隊時，就看到一個小房間內，幾個站著三七步的工程師，旁邊還有一塊貼滿便利貼的白板，如下圖，這情境就是SCRUM的【每日衝刺會議】(Daily Sprint)，不僅手機開發、Java專案廣泛使用，微軟也在Team Foundation Server 2010內，將其Agile Template改為SCRUM。它到底有甚麼魔力呢？我們就來看看吧 !
- 圖一、SCRUM 的Daily Sprint Meeting
SCRUM 宣言
- 【強調個人與互動】勝於【流程與工具】
- 【可運作的軟體】勝於【完整的文件說明】
- 【與客戶合作】勝於【合約協商】
- 【對需求改變作出應變】勝於【依計畫行事】
- 以上是由SCRUM大師共同簽屬的宣言，擺明著是針對CMMI說的，他們強調不要過多的流程規定、文件製作，應該聚焦在軟體開發本身，一開始就與客戶團隊合作，而非到專案末期，才針對合約範圍驗收協商。
- 我不喜歡原文照翻，如有疑慮，請參考 http://agilemanifesto.org/
SCRUM 起源
SCRUM方法論的用語很多是套用英式橄欖球術語，如果對橄欖球規則稍有涉獵，應該就有助於SCRUM的了解；SCRUM是指雙方爭球，如下圖，暗喻團隊合作的精神。
- 圖二、SCRUM(爭球)
又例如Sprint是指跑鋒短距離全力衝刺，橄欖球隊採分階段進攻，每次前進個幾十碼，逐步累積短期目標，到最後能順利達陣得分。
SCRUM生命週期
與傳統的軟體發展生命週期不同，SCRUM不強調需求分析要完整清楚，才開始進行開發，只要產品負責人(Product Owner)列出產品的待交事項(Product Backlog)，依據重要性及優先順序排列，並說明如何展示及滿意的條件，整個開發團隊就可以開始衝刺(Sprint)了，整體生命週期如下圖。
圖三、SCRUM 生命週期
每段衝刺(Sprint)約2-4星期，工作包括：
- 規劃會議(Planning Meeting)：訂定本段衝刺(Sprint)的目標，通常是將產品的待交事項(Product Backlog)作細部討論，選出本次衝刺要完成的待交事項，稱之為Sprint Backlog；一般而言，會考慮人員及其他資源的投入量，來決定可完成的用戶故事(User Story)點數，用戶故事類似UML的Use Case。
- 每日例行會議：規劃會議搞定後即可開工，之後由SCRUM Master(類似Team Leader)主持每日例行會議(Daily SCRUM Meeting)，review 進度，更重要的是讓成員彼此了解其他成員的工作情形及障礙。
- 展示：每段Sprint最後必須以實際系統展示，不論是Prototyping或其他形式，以確認預期目標是否達成，產品負責人會依據當初所訂的滿意條件，進行檢驗，另外再檢視燃盡圖(Burndown Chart)，比對實際與預期未完成的用戶故事(User Story)點數，瞭解進度是否落後。
- 回顧(Retrospective Meeting)：類似PMP的Lessons Learned，檢討本次衝刺是否有改善之處。
以上活動都是所有成員共同參與、一起討論，而非命令式的一言堂，至於如何塑造這樣的氛圍，SCRUM有很多的手法可以運用，礙於篇幅，不在本文贅述，有興趣的讀者可參閱 "Scrum and XP from the trenches" 一書，或等下次談到SCRUM導入時，再一一說明。
SCRUM的特點
從以上介紹，可以了解到SCRUM是以務實的觀點出發，它至少具有以下優點：
- 降低專案風險：透過階段式展示，系統逐步明朗化，強調產品負責人或客戶在整個專案過程中高度參與，並能確實掌握進度，不會在驗收時一翻兩瞪眼，發生【這不是我要的】的慘劇。
- 產品功能可隨著專案進度不斷微調，確保在有限的時程與資源限制下，能開發出符合預期的產品，而非一份完美的文件。
- 因客戶與團隊成員高度參與，所以，專案成敗是所有成員與客戶須共同承擔的責任，形成雙贏及團隊自我管理(Self Organization)的良性循環。
- 融合TDD、Refactoring、Pair programming等觀念，使專案進行更順利。
當然，它也有一些令人擔憂的地方:
- 需求不清楚，就貿然進行開發，會不會造成客戶最後不認帳，產生驗收範圍不明確的爭議?
- 階段展示會不會造成使用者介面的討論過多，忽略流程或其他重要功能的討論?
- 沒有完整的文件與管控流程說明，如何通過CMMI或ISO的審查?
這些疑慮並非沒有道理，如何選擇適當的專案類型與應用時機，端看主事者的智慧與決心。