SCRUM 初探

SCRUM 初探

SCRUM實在太夯了,最近報章雜誌報導手機應用開發團隊時,就看到一個小房間內,幾個站著三七步的工程師,旁邊還有一塊貼滿便利貼的白板,如下圖,這情境就是SCRUM的【每日衝刺會議】(Daily Sprint),不僅手機開發、Java專案廣泛使用,微軟也在Team Foundation Server 2010內,將其Agile Template改為SCRUM。它到底有甚麼魔力呢?我們就來看看吧 !

DailyScrum

  • 圖一、SCRUM 的Daily Sprint Meeting

 

SCRUM 宣言

  1. 【強調個人與互動】勝於【流程與工具】
  2. 【可運作的軟體】勝於【完整的文件說明】
  3. 【與客戶合作】勝於【合約協商】
  4. 【對需求改變作出應變】勝於【依計畫行事】
  • 以上是由SCRUM大師共同簽屬的宣言,擺明著是針對CMMI說的,他們強調不要過多的流程規定、文件製作,應該聚焦在軟體開發本身,一開始就與客戶團隊合作,而非到專案末期,才針對合約範圍驗收協商。
  • 我不喜歡原文照翻,如有疑慮,請參考 http://agilemanifesto.org/

 

SCRUM 起源

SCRUM方法論的用語很多是套用英式橄欖球術語,如果對橄欖球規則稍有涉獵,應該就有助於SCRUM的了解;SCRUM是指雙方爭球,如下圖,暗喻團隊合作的精神。

Scrum

  • 圖二、SCRUM(爭球)

 

又例如Sprint是指跑鋒短距離全力衝刺,橄欖球隊採分階段進攻,每次前進個幾十碼,逐步累積短期目標,到最後能順利達陣得分。

SCRUM生命週期

與傳統的軟體發展生命週期不同,SCRUM不強調需求分析要完整清楚,才開始進行開發,只要產品負責人(Product Owner)列出產品的待交事項(Product Backlog),依據重要性及優先順序排列,並說明如何展示及滿意的條件,整個開發團隊就可以開始衝刺(Sprint)了,整體生命週期如下圖

image

圖三、SCRUM 生命週期

本圖來源:http://www.mountaingoatsoftware.com/scrum

每段衝刺(Sprint)約2-4星期,工作包括:

  1. 規劃會議(Planning Meeting):訂定本段衝刺(Sprint)的目標,通常是將產品的待交事項(Product Backlog)作細部討論,選出本次衝刺要完成的待交事項,稱之為Sprint Backlog;一般而言,會考慮人員及其他資源的投入量,來決定可完成的用戶故事(User Story)點數,用戶故事類似UML的Use Case。
  2. 每日例行會議:規劃會議搞定後即可開工,之後由SCRUM Master(類似Team Leader)主持每日例行會議(Daily SCRUM Meeting),review 進度,更重要的是讓成員彼此了解其他成員的工作情形及障礙。
  3. 展示:每段Sprint最後必須以實際系統展示,不論是Prototyping或其他形式,以確認預期目標是否達成,產品負責人會依據當初所訂的滿意條件,進行檢驗,另外再檢視燃盡圖(Burndown Chart),比對實際與預期未完成的用戶故事(User Story)點數,瞭解進度是否落後。
  4. 回顧(Retrospective Meeting):類似PMP的Lessons Learned,檢討本次衝刺是否有改善之處。

以上活動都是所有成員共同參與、一起討論,而非命令式的一言堂,至於如何塑造這樣的氛圍,SCRUM有很多的手法可以運用,礙於篇幅,不在本文贅述,有興趣的讀者可參閱 "Scrum and XP from the trenches" 一書,或等下次談到SCRUM導入時,再一一說明。

SCRUM的特點

從以上介紹,可以了解到SCRUM是以務實的觀點出發,它至少具有以下優點:

  1. 降低專案風險:透過階段式展示,系統逐步明朗化,強調產品負責人或客戶在整個專案過程中高度參與,並能確實掌握進度,不會在驗收時一翻兩瞪眼,發生【這不是我要的】的慘劇。
  2. 產品功能可隨著專案進度不斷微調,確保在有限的時程與資源限制下,能開發出符合預期的產品,而非一份完美的文件。
  3. 因客戶與團隊成員高度參與,所以,專案成敗是所有成員與客戶須共同承擔的責任,形成雙贏及團隊自我管理(Self Organization)的良性循環。
  4. 融合TDD、Refactoring、Pair programming等觀念,使專案進行更順利。

當然,它也有一些令人擔憂的地方:

  1. 需求不清楚,就貿然進行開發,會不會造成客戶最後不認帳,產生驗收範圍不明確的爭議?
  2. 階段展示會不會造成使用者介面的討論過多,忽略流程或其他重要功能的討論?
  3. 沒有完整的文件與管控流程說明,如何通過CMMI或ISO的審查?

這些疑慮並非沒有道理,如何選擇適當的專案類型與應用時機,端看主事者的智慧與決心。