今天花了一天的時間，仔細的了解了一下Scrum方法。 其實很早以前（1-2年前吧），就聽說并接觸過Scrum方法，但是僅僅停留在了``聽說"而已，沒有真正的實踐過。
Scrum是什么呢？ 套用介紹文章中的定義: ``Scrum has a simple implementation that is designed to increase productivity and reduce the time it takes to benefit from a software/product development. Importantly, it embraces adaptive and empirical systems development. "。用中文定義來說，就是: ``Scrum提供了一種經驗方法，它使得團隊成員能夠獨立地，集中地在創造性的環境下工作。它發現了軟件工程的社會意義。這一過程是迅速，有適應性，自組織的，它代表了從順序開發過程以來的重大變化"。
這種定義其實非常的``空洞"，關鍵在于Scrum的實踐:
1. Scrum團隊（5-7個人的小項目組）。 團隊的負責人可能擔負起Scrum Master的角色。
2. Backlog: 急待完成的一系列任務，包括：未細化的產品功能要求、Bugs、缺陷、用戶提出的改進、具競爭力的功能及技術升級等，按優先級定義出來，這些任務可能不是完整的，甚至可能隨時會更改或添加。
3. Sprint(沖刺): 通常為30天的迭代時間，把Backlog中的每一項安排在Sprint中，由團隊估算出所需要的時間（按小時記）。 每一次Sprint之后，一定要有可以交付使用的功能。
4. Scrum會議: 這是與傳統方式最大的區別，每天15-20分鐘的Scrum會議，通常在每天的同一時間和同一個房間內舉行(通常在午飯后舉行)。 Scrum團隊所有人都參加，也可以有旁聽者（但不允許旁聽者指手劃腳）。 在這個15分鐘的會議上，Scrum Master會詢問每個成員三個問題:
a) 自上次Scrum會議后的1天里你做了什么？
b) 從現在到下次Scrum會議的1天時間里你準備做什么？
c) 你在工作中遇到了哪些困難？
每個成員在Backlog條目上所花費的時間會被記錄到Spring backlog中。 Scrum Master在會上對存在的問題提出即時的解決方案或指導，使團隊不斷向著目標前進。Scrum會議不同于項目會議，對團隊來說，它起到了快速簡報的作用。
5. 通過Sprint Backlog的分析，可以了解Backlog的進度，盡早的了解所發生的問題
6. 管理者不在是項目或者團隊的``老板", 而是幫助團隊解決問題的``協調者"或是``助手"。
7. 每一次Sprint之后要review，團隊按照既定的Sprint Backlog目標來演示完成的內容。
今天讀了這些介紹Scrum方法的文章以后，才發現，其實在過去一段時間的產品開發和項目管理中，或多或少的在方式方法上，受到了Scrum的影響，但大部分是定性的在使用，比如: 每個月底會review這個月的工作，然后安排下一個月的工作(有點類似于制定一個Sprint Backlog)。 每周會詳細的了解開發進度，解決問題(太過粗礦的Scrum Meeting)。 但是，我們并沒有定量的使用這種靈巧的開發方式，比如: 沒有為每項需求或者功能仔細的預估時間，對進度的了解過于粗粒度了而造成有時無法盡早了解發生的問題，沒有一個直觀的數據分析來協助團隊了解總體的進展。
我想，我們會逐漸的在開發和實施的項目中開始使用Scrum這種敏捷的方式，也許先從個別的小團隊開始嘗試實施。
【參考鏈接】
http://www.controlchaos.com/about/
http://www.methodsandtools.com/archive/archive.php?id=18
http://wiki.scrums.org/index.cgi?HomePage
http://www2.cnblogs.com/jackyrong/archive/2006/07/09/446282.html
http://epjnpe.cnblogs.com/archive/2006/06/30/440034.html