Scrum，XP中的一種軟件開發模式，是迭代式開發的一種具體實施方式。Scrum的詳細定義可去wikipedia查詢，這裏只作一個筆記式要點記錄。
使用Scrum方法開發一個軟件，首先要有一個Backlog，這個Backlog是一個或者多個(User) Story的集合。這些story就是開發過程中我們必須完成的事情，也就是說Backlog定義了我們要實現什麼。Scrum進行迭代式開發，一個完整的Scrum過程分爲一個或者多個Sprint來完成。在所有列出的Story中，首先進行優先級排定，然後選擇一些高優先級的Story，作爲第一個Sprint要達到的目標。在Sprint中，又將這些Story在具體化爲多個更貼近代碼的Task，並將Task劃分給具體的人去實施。完成一個Sprint之後，進行測試和總結，驗收前一階段的成果。然後再從Backlog中挑選未完成的Story作爲第二個Sprint的目標。不斷的重複這個過程直至所有的Story都被實現。Scrum講究靈活快速的開發風格，所以每一個Sprint都不宜太長，一般一個Sprint控制在3－6工作周。
以下爲我的一些認識，以及一些經驗人士的實施體會：
1. 在進行開發之前，首先要做的事情是定義你需要什麼東西。也就是常說的產品定義、功能定義或需求。在軟件工程中，這三者是有區別的，但是在Scrum中Backlog彷彿卻是三者的混合。項目一開始，Backlog中的Story可能只是一些很簡單抽象的客戶需求。經過分析，需要將這些需求式的Story轉換爲產品定義式的Story，最終轉換爲可以作爲Project實施指導的功能式（產品特性）的Story。所以，Story是一個變化的過程，而不是一開始就設定好。
2. Scrum重過程，輕文檔。傾向於在實施過程中不斷修正方案（重構），而不是在開頭做一個足夠良好的設計。
3. Scrum重視Project實施中的細節，要求成員之間每天進行溝通和交流（5分鐘晨會）。
4. Story中應該儘量詳細的描述爲什麼要做這個Story，做什麼，完成之後我們可以得到什麼。如果不知道Story該怎麼寫，說明對Project理解不夠，需要進一步的研究之後才能開始編碼。
5. Story細化爲task時，如果不知道如何劃分或劃分很困難，則應審視設計，或者重新理解產品
6. XPlanner，一個根據Scrum過程編寫的項目工具
7. Scrum是一個項目過程控制方法，而不是一個員工績效考覈系統。由於Scrum過程中強調對具體task的精細劃分，常常會被成員，尤其是不熟悉Scrum的成員誤會，認爲這是一個嚴厲的績效考覈體系。其實，Scrum重項目的完成情況，而不重個人的實際工作量。相反的，Scrum對於個人相當寬鬆，它允許擬定的工作量完不成，允許對原計劃進行修訂。因此，必須通過一定的方法使項目成員明白Scrum的作用。
8. Scrum作爲項目管理的方式，其理想的方式在於每一個Sprint都能得到比上一個Sprint更進一步的產品。這種逐步求精的迭代式開發使得我們在短時間內就能得到一個部分可用的產品，然後逐步完善功能，最終形成產品。這使得及早發現產品的潛在問題和進行重構成爲可能。
9. Scrum適合作爲中小規模軟件產品和小團隊開發。對於大型產品來說，Scrum仍然有其用武之地，因爲這類產品的開發也通常會劃分爲多個不同的小模塊。
10. 開發人員在Scrum中相對平等，對於細化的story、task，Scrum鼓勵開發人員按自己的興趣和能力進行選擇。
11. 每task的工作量控制在2－3天，利於發現問題，控制節奏
12. 劃分task應儘量保持task的獨立性，減少task之間的依賴
13. 一個團隊初次使用scrum時必然會遇到各種各樣的問題，比較典型的問題有對工作量不能準確估計等。一般來說需要3－4個月的實踐，才能完全進入狀態。
14. 一般按6小時/天來估計日工作量，留出必要的開銷
15. 一個Story劃分爲多個task完成，出於各種原因，有可能不能完成。這是需要將原Story根據完成的部分劃分爲兩個Story，一個作爲本Sprint的部分，另一個則留到下一個story。原則上來講，一般不會延長Sprint的時間，一個Sprint中未做完的部分都應該採用這種方式形成新的story留到下個sprint完成。以求保證scrum以良好的節奏前進。
16. 對於story優先級的劃分相當重要，劃分的原則可根據開發需要和客戶需要量方面確定。
17. 鼓勵由成員自己來估計每一個task的工作量，而不是由某個leader來指定。這樣成員的開發積極性可能會更高。當然，這可能需要一段時間才能做到準確估計，也需要高級工程師必要的指導。
18. Scrum是動態的，story，task，工作量都需要根據實際情況變動，而不是固定不變的。隨着項目的進展，以及對項目理解的深入，這些都會變動。
19. 通常也會把做計劃本身當作一個story，放到sprint中完成
以上轉自 ： http://goldencz.spaces.live.com/blog/cns!bdf1adf5c4d1f962!668.entry
一直疏忽了實踐，理論也會忘卻，今天竟然犯了個錯誤，在類庫開發中，讓同事去寫story，概念都有點錯，
所以分清，Backlog，Story，Task；另外應該直接去寫需求，讓他們去發掘需求，進而實現需求。