SCRUM的方法並沒有特定的工程實踐慣例，但是定義了幾個角色例如“團隊、Scrum Master， Product Owner”以及角色相應的職責。並且在團隊這個角色上注入了“團隊自我管理”的使命。團隊成員會主動朝著產品研發的進展方向規劃自己的迭代計劃、日計劃，並主動完成其工作。產品圍繞著叫做Backlog的列表展開，這個列表最開始作為一個容器容納所有待完成和已完成的工作項，而每個工作項都可以繼續拆分和重新排列優先順序，當團隊開始了SCRUM的開發時， 團隊將從中選擇重要且能夠完成的Backlog，在2到4周完成這些Backlog的釋出，而產品就是通過每每迭代，這裡叫做SPRINT，來增量構建這些Backlog而組成的。

SCRUM同其他例如XP、Crystal方法一樣均屬於敏捷Agile 方法範疇，我們回憶一下敏捷宣言，宣言中強調了在專案實施過程中，左邊專案要素優於右邊優先被考慮。

個人與互動         重於              開發過程和工具

可用的軟體         重於              複雜的文件

尋求客戶的合作  重於              對合同的談判

對變化的相應             重於              遵循固定的計劃

•  擁抱變化（Embrace the change）

無論是多麼明智，多麼正確的決定，也有可能在日後發生改變。因此，團隊要能夠充分理解我們的STAKEHOLDER和客戶代表為什麼經常提出新的需求和設計要求，一句話，就是心中有數“唯一不變的是變化”。團隊更要信任STAKEHOLDER做出的每次決定和需求的調整都是將產品開發推向更正確的發展方向，新變化將進一步降低風險，實現團隊最大化利益，理解這是適應市場變化的必然行為。

而在接受變化的同時，我們應該積極的向STAKEHOLDER和客戶代表反映實現活動中暴露出來的可能的設計缺陷和錯誤。在實際工作中，團隊成員應該用優先順序制度來劃分事情和目標先後順序，在迭代週期內對於還沒有最終決定的設計方案可以予以後來實現、測試，不用急於投入資源展開全面的開發、測試活動。這樣一來，開發測試團隊也會人員也將更加適應，真正擁抱變化。

• 客戶的參與（With customer representative on site）

首先誰是Customer，Customer Representative呢？STAKEHOLDER，或者我們可以理解為我們的客戶（Customer），產品的最終使用者（Enduser）， 內部使用者（Insider），商業夥伴（Business Partner）。STAKEHOLDER 作為團隊中最瞭解BUSINESS的人物將幫助開發團隊的快速達到目標和做出適時決策。開發團隊擁有很好的技術但在BUSINESS方面他們需要STAKEHOLDER的幫助。而通常在敏捷的開發專案中，團隊中的任何一個人若需要幫助時，只要簡單的邀請大家參加一個15分鐘會議，或一封郵件、一個電話便可以解決。

但是，如果STAKEHOLDERS各執一詞怎麼辦呢？為解決這個問題，將Product Owner引入到討論中來， 作為Product Owner他可以作為是STAKEHOLDERS的代表，能夠在分歧中做最後抉擇。因此，通過這樣的客戶代表的參與，團隊更好的瞭解了所做事情的價值和意義，其工作效率也因而得到很大提高。

STAKEHOLDERS能夠幫助團隊中的每一個人更好，更快的完成了工作，他們的直接參與成為了敏捷開發、敏捷測試的重要前提。

•  較少的文件（With less documents）

敏捷開發更重視生產出可用的產品而不是詳細文件。而時常有發覺文件又是無論敏捷還是傳統開發、測試不可或缺的一部分。筆者認為，傳統開發的文件在敏捷開發裡仍有大用，只是原來十來頁的內容精煉到現在的一頁半頁。

敏捷主義者相信文件不是最佳的溝通方式，他們鼓勵通暢的交流和溝通，要求避免和減少陳詞濫調和空頭支票。尤其是複雜的文件說明只是增加了溝通成本，因而敏捷開發、測試的文件不需要長篇累讀，需要的是簡潔，清晰。任何一段清楚的文字，甚至一張圖片，照片，一封記錄著會議記錄的郵件都是我們認可的敏捷文件。因為是無論是通過文字板書的檔案還是其他的溝通方式和載體都是為了幫助團隊進行更高效的交流和溝通。只有團隊保持著溝通上、理解上的一致後才能夠充分發揮出團隊最佳戰鬥力。但凡這是幫助團隊有效溝通的方式，何種開發都不會捨棄的。

• 最大化的生產力(Maximize Productivity）

敏捷開發模式要最大化的提高團隊的工作效率。無論是依靠剪除冗餘的文件工作，還是提供民主的、通暢的溝通平臺都是為了幫助團隊能夠集中有限的精力處理有意義的問題。據調查，通常人會在兩個、多個任務並行的情況下產生出出最高工作效率。而敏捷也恰恰使用了各種方法得到團隊的最大生產力。

敏捷開發的Scrum模式，要求在計劃階段，團隊成員主動定製迭代週期的所有工作任務，因此，本身從團隊開始迭代活動的那時起，已經在在多重工作的壓力下緊張工作了。而在日常的迭代生產活動裡，各個成員需要當眾簡單彙報當天的工作進度和承諾下一個24小時的工作計劃。因此，通過增加敏捷人員的工作的透明度，無形之中，團隊成員的生產力進一步得到提高。

•   自動化冗餘工作(Automate the redundant work）

將團隊成員從冗餘的勞動中解放出來，無論是自動化的測試還是自動化工具的開發只要能夠節約成本都是敏捷開發、敏捷測試的目標。

• 民主的團隊(Democracy in team）

敏捷團隊是一支民主的團隊，團隊關係是平行的，每個團隊成員能夠平等的參與討論，決策。傳統開發的垂直的官僚機構在敏捷開發中已是過時的。

• l 尊重團隊(Respect to team）

敏捷團隊的決定權交有團隊自己，決定是團隊統一制定。無論是產品設計方案還是產品的功能實現都是的最佳結果。團隊脫離了任何一個成員的工作都是不完整的，所以我們應當足夠尊重其他成員的勞動果實和表達對其他成員的充分信任。尊重團隊，尊重團隊中的每一個成員都是敏捷開發的原則之一。