這些天看到一本書《Agile Project Management with Scrum》，感覺很不錯，于是在網上找了些相關的資料。
SCRUM方法如下：
由Ken Schwaber和 Jeff Sutherland 提出，旨在尋求充分發揮面向對象和構件技術的開發方法，是對迭代式面向對象方法的改進，名稱來自英式橄欖球（在比賽中每個隊員都應時刻保持對場上全局的判斷，然后通過集體行動，奮力實現同一目標──勝利）。SCRUM方法最初實踐于Easel公司(1993年)，現已被數十家公司數百個項目開發中應用，適用于需求難以預測的復雜商務應用產品的開發[11]。SCRUM提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master、SCRUM Team、Demo等模式已被PLOP作為組織和過程模式（Organizational and Process Pattern）的標準[12]。
SCRUM將工業過程控制中的概念應用到軟件開發中來，認為軟件開發過程更多是經驗性過程(Empirical Process)，而不是確定性過程(Defined Process)。確定性過程是可明確描述的、可預測的過程，因而可重復（Repeatable）執行并能產生預期的結果，并能通過科學理論對其最優化。經驗性過程與之相反，應作為一個黑箱（Black box）來處理，通過對黑箱的輸入輸出不斷進行度量，在此基礎上，結合經驗判斷對黑箱進行調控，使其不越出設定的邊界，從而產生滿意的輸出。SCRUM方法將傳統開發中的分析、設計、實施視為一個黑箱，認為應加強黑箱內部的混沌性，使項目組工作在混沌的邊沿，充分發揮人的創造力。如將經驗性過程按確定性過程來處理（如瀑布模型），必將使過程缺乏適應力。
3.2.1 SCRUM方法的開發過程
包括三個過程：
(1) 計劃和體系結構設計（確定性過程）
將Backlog（急待完成的一系列任務，包括：未細化的產品功能要求、Bugs、缺陷、用戶提出的改進、具競爭力的功能及技術升級等）按優先級排序形成Backlog 列表，根據該表和風險評估制訂產品交付基線。
建立系統體系結構（如為已有系統改進，則只作有限分析、調整），將Backlog項按高內聚低耦合的原則分解為一系列問題包(Packets,每個Packet是一組對象或構件的集合) ，依據同樣原則相應劃分若干個開發小組（SCRUM 小組）,分配各小組合適的Backlog項或問題包。建立開發運行環境。
(2) Sprint（經驗性過程）
該過程由若干個迭代的沖刺(Sprint) 活動組成，直至風險評估認為產品可交付為止。一個Sprint是在限定時間段內（Sprint周期，通常為1~6周，可在前一個Sprint結束時調整）的一系列開發活動（包括分析、設計、編碼、測試等），每個SCRUM小組并行開發且必須步調一致（在一個Sprint結束后，均須完成所分配的Backlog項并有可執行的產出）。
每個Sprint包含以下活動：
l 開發。對分配的Backlog工作進行分析，將所需改動（changes）映射到各packets，打開packets,進行領域分析，然后設計、開發、實施、測試、文檔化這些改動。
l 打包(Wrap)。封裝packets,產生一個滿足Backlog需求的可執行版本。
l 評審（Review）。所有的SCRUM小組一起開會，提交各自的工作并演示(Demo)，然后提出和解決問題(Issue)及難點（problem）,增加新的Backlog項；發布、審查或調整產品的標準規范；進行風險評估并提出合適的對策；確定下一個Sprint的工作內容和結束時間。
l 調整（Adjust）。根據評審會匯集的信息，對受影響的Packets進行適當調整和鞏固。
(3) 交付和鞏固（確定性過程）
一旦根據風險評估結果認為可交付產品時，即進入該階段。該階段的活動包括：組裝，系統測試和回歸測試（Regression），準備培訓材料，完成最終文檔。
SCRUM過程認為一個產品的開發將一直持續下去，除非經風險評估后認為應停止。產品交付后的鞏固活動類似于傳統方法中的維護和改善，目的在于整理Sprint期壓力下忽略的工作，為下一階段的開發做準備，以便輕裝上陣。
3.2.2 SCRUM對過程的管理：
(1) SCRUM的控制手段。
SCRUM提出了八個控制項（Controls）用于開發過程的調控，其中風險控制是首要的手段。
l Backlog。
l 對象/構件。
l Packets。
l 變動（Changes）。實施一個Backlog項時，對相應Packet的改動。
l 難點（Problems）。實施一個變動時所必須解決的技術難點。
l 問題（Issues）。涉及到整個項目或在Backlog項分解到Packet之前須解決的問題。
l 措施（Solutions）。對問題或難點的解決，通常會導致變動。
l 風險（Risks）。影響項目成功的風險，應持續跟蹤評估并相應做出調整。風險評估的結果將影響其他所有控制項。SCRUM定義了六個概念性變量來用于風險評估：用戶需求，時間壓力，競爭，質量，遠見（vision）和可用資源。
在SCRUM的各個階段都使用這些控制項來評估和權衡，管理人員側重于以此管理Backlog，開發組用以處理變動和難點。所有人員一起來管理問題、風險和措施。
根據對控制項特別是風險的不斷度量評估和權衡，一方面，計劃和進度（在每個Sprint結束時）不斷相應調整，保證實現產品的商務目標；另一方面，對開發中的工作任務Backlog動態地進行優先級排序，開發組總是先開發優先級最高的Backlog項，這樣就保證了資源的最合理使用。另外，SCRUM強調度量（采用標準功能點度量方法）的重要性，通過對每個Sprint中生產率等的度量，計劃和進度將越來越趨于準確。
(2) 項目組織。
項目組由全職開發人員及與該交付產品有關的市場人員、銷售人員、用戶等組成。設以下小組：
l 項目管理組。由產品經理領銜，包括總設計師，各SCRUM小組組長，市場、銷售的高級職員及典型用戶等。
l 若干個SCRUM小組。各小組由組長（SCRUM Master）領銜。每個小組都是跨專業的（通常包括開發人員，文檔人員，質量控制人員或用戶代表等），通常為3~7人，以使小組內有充分的交流。小組的劃分最好是功能導向的（按所分配的問題包或Backlog），也可是系統層次導向（按體系結構中的分層）。.
在項目組人數增大時，可在管理組之上再設管理組（SCRUM of SCRUM）,從而使SCRUM方法的應用到大項目中。
(3) Sprint期間的調控。
在Sprint期間，應使各SCRUM小組盡量避免外界的干擾（不可將新的Backlog任務加進來，組內產生的Backlog可放到整個項目的Backlog列表中，也可在本次Sprint中解決），使小組成員專心于目前的工作，使他們工作在混沌的邊沿。
為避免項目組在Sprint期間不陷入混亂，SCRUM采取兩個措施:
l SCRUM會議（SCRUM Meeting）。對小組行為進行監控和刺激。會議在Sprint期間每天在同一地點舉行，由SCRUM Master主持。會議上，SCRUM Master對每個小組成員提三個問題：
1） 昨天的工作進展如何。
2） 有否遇到困難和障礙。
3） 今天的工作打算。
會后SCRUM Master集中精力排除障礙，小組成員則進行當天的開發。
l Sprint評審會議。評審后根據對每人的工作成績，進行相應的激勵。
3.2.3 SCRUM方法的實踐效果和發展方向：
SCRUM在實踐中大大提高了生產率（據軟件生產率組織的Capers Jones稱可提高6倍），在實施中有一個"間斷平衡"（Punctuated equilibrium）現象（類似于自然界中物種的進化，在經過一段相對平衡的各自獨立、并行的發展期后，在交匯處發生變異），即在經過緊張、并行的Sprint開發后，在Sprint評審時，軟件產品產生較劇烈的變化。SCRUM方法的最近動向是設法借鑒XP方法。