From:http://blog.csdn.net/testwin/archive/2007/04/02/1549325.aspx
嚴格來說，不能算是真正的scrum實踐，但實踐敏捷的過程本身也是一種“敏捷方法”，所以就算是“敏捷實踐之敏捷開發方法－scrum過程”吧。
一、理論參考：Scrum的實踐（該部分摘自網絡）
1.Scrum團隊（5-7個人的小項目組）?！ ?br>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目標來演示完成的內容。
二、實踐小記：
1．目前的團隊剛好7人，且項目背景提供了可實踐scrum的良好土壤；
2. 小版本迭代：從項目啟動開始，采用最多不超過３周的階段計劃；各個階段根據情況發布系統內部版本；
注意與傳統方法區別，沒有按固定周期月之類定計劃，而是按目前能預見的周期內定計劃。事實也是如此，根據幾個月的實踐經驗，最多只能預測三周。
3. 每次階段計劃的時候：功能要求、Bugs、缺陷、用戶提出的改進、具競爭力的功能及技術升級等，先從各成員處收集匯總成為項目任務，并以半天為單位，預估工作量；集體討論確定優先級，然后排工作量，優先級低的任務被去除；
可惜的是無法做到讓客戶來幫我們定優先級；
不過期間我們通過“現場開發”（與客戶方常駐一起）的方式，盡量讓客戶每天能看到系統，提出修改意見；實踐證明，這種開發效率的確要高很多。
4. 每次階段計劃末：統計上個階段每個人任務完成情況、團隊階段任務完成情況、成員工作自我評估滿意度等，并在一個較大周期（一般是3月5日個小階段）后繪制統計曲線；
注意這個曲線一方面可作為項目績效參考，一方面也能夠清楚反映項目計劃、進度控制中的各種問題；
5. 每周都進行有1－2次進度溝通（每次２０－３０分鐘）：互相了解開發進度、遇到什么問題如何解決，需不需要調整細節計劃、內部調整；其中一次是隨機的，一次是固定的，每周五例會。
注意，在周五例會的時候，除了正常的工作溝通，還會進行心情指數、壓力指數調查，并安排相應的娛樂活動，關注每個成員的情緒狀態和滿意度；
關于心情指數，壓力指數，工作滿意度等也會在一個大周期后繪制統計曲線，作為項目階段總結，以持續改進；
其實每周例會最忌諱的是“公事公辦”，應該盡量隨意點，成為大家坦誠溝通的平臺，談工作，談生活，發牢騷，情緒宣泄越暢快越好；有條件就到室外去開。
后來我們在周例會中還加入了３０分鐘技術交流時間，輪流有人自發就本周工作中的體會或經驗進行簡短技術交流，不用花太多時間準備，但對團隊知識積累非常有益（交流完了，資料要求進入知識庫）
6. 核心任務，或項目中的關鍵路徑，采取更緊湊的日進度溝通：通常是對里程碑任務和新加入成員，采取日進度溝通。形式上不是“站立式會議”，多以該面對面隨意聊天、或即時消息、個人或團隊工作日志進行。
個人更推薦隨意的面對面聊天，更符合我們的習慣，主導該關鍵任務的人，每天 早上來了，跟任務相關的人打打招呼：
“ｈｉ，搞定了沒？”
“這么快啊，你家伙很厲害嘛。。。”
“哦，請假了啊，沒關系的，先讓××幫你看看。。。”
通過這種很隨意的方式，即達到了進度溝通的目的，又讓大家覺得親切如朋友。如果太嚴肅，反而會隱藏很多問題。
7. 持續改進：一般在3－5個階段過后，往往會進入項目下一“新進程”，這個時候把前面所有的進度統計、成員滿意度統計、問題跟蹤統計、技術問題等資料統統收集起來，進行分析總結，并確定下一階段的改進措施和工作目標。
問題和改進措施非常重要。一般的做法是讓每個人都提3-5個認為團隊工作最需要改進的方面；然后集體再去排優先級，討論可行的改進措施，然后制定成問題改進跟蹤表（有個軟件平臺最好），到下個進程再循環；
以我們的實踐經驗，只要前面做好了，這份總結很容易，半天就可以整理好。
總結中一個非常重要的方面，就是對成員的管理。這個大階段內，有人進步非?？?，有人一直承擔核心任務，有人總是趕在進度之前（是不是下次應多分配點任務），有人進度延遲較多，滿意度也不高（是不是個人情緒問題，生活中有什么事情影響了工作？）
針對這些情況，私下里或正式或隨意的面談溝通非常重要。不解決好人員問題，后面就有很多不可控的風險。
8. 人員管理為核心：團隊成員角色識別、個性搭配、技術能力搭配、團隊成員技術發展目標和能力發展目標，及時面談溝通等。
“授之以漁，非授之以魚”：任何能夠讓成員提高的事情，都要絕對遵循這個原則，哪怕相對要花較長時間，但絕對是值得的；任何團隊都會受制于很多現實條件，或許團隊里面有2個豬八戒，或許團隊里面除了一個孫悟空，其他的都還不及沙僧，或是人員變更，這都是不可避免的，所以要提前做好預測，識別團隊角色上的缺陷，盡早進行培養，才不至于落得被動。
關于成員發展問題，以前的太簡單了，好像成員就是發展為項目經理，這就叫職業規劃了，其實完全不對路。團隊里面，當確定目標的時候，一定要從小處入手：如技術方面，某一方面的技術能力獲取突破成為公司專家；某一技術弱項快速提高，達到中等層次；知識面拓寬；
如工作能力方面：語言表達、溝通能力達到團隊最好水平，文檔能力達到團隊最高水平；如角色方面；發展為技術管理角色；發展為集成員和質量保證角色；發展為管理角色等。
這種發展目標實實在在，每個人都能很快看到自己的進步。當然，如果某位成員有成為項目經理的機會，也要鼎力向上級推薦。
9. 關于“結對”編程：在某些關鍵任務的設計、調試階段，采用結對方法；
另外：新成員學習期間，每天有1-2小時的結對時間；項目進行單元測試期間，“變相結對”，首先：交換測試（你實現的我測，我實現的你測），然后共同解決問題。
10. 其他，針對項目經理：
1) 你是否還在當“隊長”，而不是當“教練”？你是否還在“管事”，而不是“管人”？你是否還在懼怕你的成員能力超越了你？如果是，后面都不用看了，無法做到的。
2) 要做到前面所說，前期鋪墊是非常重要的，你的團隊成員都接受了你？你是否已經初步和他們建立了坦誠、同甘共苦的合作關系？
3) 你是否真的花了70％的時間在溝通和協調？
4) 你的團隊角色都選好了嗎？你的工作是否得到了上級支持？
5) 你是否總是主動向客戶和上級匯報工作進展，書面的，面對面的？
6）你是否持續用分解的小目標來鼓勵士氣？
7) 是否經常在小目標達成之后通過各種方式激勵大家（公布問題改進跟綜表讓大家隨時看到團隊的進步？一起活動，上班期間半小時聊天休息，邀上公司領導一起聚餐）
8）除了工作外，你是否了解每個成員的個人生活狀況，并隨時能靈敏感覺到部分成員的消極情緒？你是否盡全力幫他們解決了工作上，甚至生活上的問題？
9) 在去除某個資源障礙時，你是否真正做到了絕對客觀和問心無愧？
比較有意思的是下面這段話：
@肯.索夫特
我在的公司的確不大，而且關鍵是我的上級是一個非常好的領導，我的想法他總能一聽就懂，并給你空間，支持你；
心情指數和壓力指數調查肯定不會是填表，例會的時候大家自己說；
我想真實度是依賴于你前期所作的工作，是否真正讓大家相處得象兄弟姐妹一樣；
而且某些情況下是70或90哪個更準確并不重要，重要的是讓大家有機會表達；
關于上班時聊天，不難操作啊，我想大多都有周例會吧？為什么不能在工作說完之后，讓大家隨意聊聊呢？呵呵，我們有個優勢，就是周五的時候會議室不夠用，所以偶爾情況下，剛好有借口在辦公室外開會，大家心情放松多了。
@samever
大公司流程管的嚴，是難操作些。
“高深”的理論向來都不能“武裝”人，只能嚇跑人，所以我從來沒在我的上級，或是同事之間說過，我們要“Agile”,“scrum”，或“XP”，或“pair”。
我說：“頭兒，我有些內部管理的想法想在我們項目中嘗試下。”
頭兒說：“可以啊，沒問題”。
我說：“上次項目總結大家提的問題不是都說‘計劃趕不上變化’嗎，那我們現在能不能盡量把周期縮短點，能預見多長，就定多長的計劃呢？”
大家點頭：“對，是該試下”。
我說：“××，你看看是不是我們倆在一起研究下這塊的代碼”？
然后結對開始了。
公司外部版本發布，要嚴格走流程，我們就不停采用內部發布，這樣一點一點小版本就出來了。
。。。。。。
其實在之前，我們在項目的管理上也是跟著感覺走的，一筆糊涂賬；
但只有這樣細致、日常積累數據，才能真的“管得清楚”（怎么想起小燕子的“跪得容易”了，；） ）