創始人
Jeff Sutherland
Jeff Sutherland的第一份工作居然是美國空軍戰鬥機飛行員，還曾于1967年獲得了“壯志淩雲”稱号，完成過100次飛越北部越南的作戰任務。服役後期，他到斯坦福大學拿下統計學碩士學位，并在美國空軍學院教授數學統計學和概率學。11年軍旅生涯結束後，他成為了科羅拉多醫學院的教師并獲得了博士學位。在諾貝爾化學獎得主萊納斯·鮑林的贊助下，他以放射學、生物學及預防醫學助理教授的身份參與了維生素與癌症研究中心的創立，擔任八年國家癌症中心的主要研究員，負責科羅拉多地區所有癌症患者的數據統計和IT方案與研究，整合了國家注冊、臨床試驗、流行病學研究和癌變的超級計算機數學模型。1983年，他進入了一家遍及北美、經營着150家銀行的公司，職務為先進系統副總裁及ATM業務部總經理。此後，Sutherland先後擔任了11家軟件公司的CEO、CTO或者工程副總裁，積累了豐富的軟件開發經驗。
Ken Schwaber
Ken Schwaber最初的職業也很特别——商船經理。在随後40多年開發生涯的前10年中，他曾經編寫過操作系統，搞過嵌入式，為IBM大型機開發系統軟件；先後在芝加哥大學、伊利諾伊理工學院、王安公司實驗室工作，并逐漸展現出在軟件開發方法上的天賦。在CASE工具和結構化方法熱門的時候，他自己創辦了ADM公司，從事軟件開發方法培訓服務。期間，公司開發了軟件方法自動化工具MATE，用來生成各種軟件流程所需的模闆、計劃等，生意很好。
合作經曆
Sutherland和Schwaber相識于1980年代早期。1987年，兩人開始合作。一天，Sutherland問Schwaber：“你們開發MATE工具都用了當前流行的哪一種方法？”“當然什麼都沒用，”Schwaber回答，“要不然公司早就完蛋了。”他們意識到問題的嚴重性，開始與開發者交談，研究新方法。
1993年，Sutherland讀到了兩位日本管理教授竹内弘高和野中郁次郎介紹制造業裡出現的新的産品開發方法Rugby（橄榄球）的文章。這種方法的特點是整個流程都由一個高性能、跨功能的團隊執行到底。他受到啟發，結合自己多年的經驗，與Easel公司的John Scumniotales和Jeff McKenna一起開發了一套方法，取名為Scrum（來源于橄榄球術語，不是縮寫）。
而Schwaber則從杜邦公司一位化工過程控制專家那裡取經，意識到項目分為兩種：确定性項目，一切都已經确定，可以自動化生産流程；實驗性項目，充滿不确定性，哪怕一點微小的變化也會牽一發而動全身，因此隻能用各種儀表不斷監控，随時做出調整——這就是每日站會的由來。
兩人在一個IBM項目合作，并做了更詳盡的研究，Scrum誕生了。1995年OOPSLA大會上他們第一次向世人介紹了Scrum。可當時，兩個人的公司都還在做千年蟲和各種重型開發方法咨詢方面的業務呢。
進入新世紀，互聯網帶來的巨變使敏捷方法受到了更多開發團隊的歡迎，而其中Scrum以其擴展性、門檻低、名字和術語更容易被項目經理接受等因素，逐漸成為最受歡迎的敏捷流派。而推出CSM等系列認證，雖然争議頗大，但客觀上對Scrum擴大影響力起到了重要作用。
當今，Scrum的影響已經遠遠超出軟件開發，成為零售、軍事、風險投資甚至學校裡完成各種任務的創新方法，正在改變着世界。
曆史
1986年，竹内弘高和野中郁次郎闡述了一種新的整體性的方法，該方法能夠提高商業新産品開發的速度和靈活性：他們将這種新的'整體性方法與橄榄球相比較，前者各階段相互重疊，并且由一個跨職能團隊在不同的階段完成整個過程，而後者整個團隊"tries to go to the distance as a unit,passing the ball back and forth"。他們對來自汽車，照片機器，計算機和打印機等産業的案例進行了研究。1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一書中将這種方法稱為Scrum，在竹内弘高和野中郁次郎的文章中提到的橄榄球術語。1990年代初，肯·施瓦伯在其公司使用了一種方法Advanced Development Methods（先進開發方法），這種方法後來發展為Scrum。同時，傑夫·薩瑟蘭在Easel公司開發了一種類似的方法，并首次稱之為Scrum。1995年，在奧斯汀舉辦的OOPSLA'95上，薩瑟蘭和施瓦伯聯合發表了論文首次提出了Scrum概念。施瓦伯和薩瑟蘭在接下的幾年裡合作，将上述的文章，他們的經驗，以及業界的最佳實踐融合起來，形成我們當前所知的Scrum。2001年，施瓦伯與麥克·比窦（Mike Beedle）合著了《敏捷軟件開發-使用Scrum過程》一書，介紹了Scrum方法。
特性
Scrum過程
Scrum是一個包括了一系列的實踐和預定義角色的過程骨架（是一種流程、計劃、模式，用于有效率地開發軟件）。
在每一次沖刺（一個15到30天周期，長度由開發團隊決定），開發團隊創建可用的（可以随時推出）軟件的一個增量。每一個沖刺所要實現的特性來自産品訂單（product backlog，我覺得翻譯成“産品目标”更恰當），産品訂單（産品目标）是指按照優先級排列的需要完成的工作的概要的需求（目标）。哪些訂單項（目标項目）會被加入一次沖刺，由沖刺計劃會議決定。在會議中，産品負責人告訴開發團隊他需要完成産品訂單中的哪些訂單項。開發團隊決定在下一次沖刺中他們能夠承諾完成多少訂單項。在沖刺的過程中，沒有人能夠變更沖刺訂單（sprint backlog），這意味着在一個沖刺中需求是被凍結的。
管理Scrum過程有很多實施方法，從白闆上的即時貼到軟件包。Scrum最大的好處是它非常容易學習，而且應用Scrum不需要太多的投入。
敏捷方法之極限編程（XP）和Scrum區别
區别之一：叠代長度的不同
XP的一個Sprint的叠代長度大緻為1~2周，而Scrum的叠代長度一般為2~4周。
區别之二：在叠代中，是否允許修改需求
XP在一個叠代中，如果一個User Story（用戶素材，也就是一個需求）還沒有實現，則可以考慮用另外的需求将其替換，替換的原則是需求實現的時間量是相等的。而Scrum是不允許這樣做的，一旦叠代開工會完畢，任何需求都不允許添加進來，并有Scrum Master嚴格把關，不允許開發團隊受到幹擾。
區别之三：在叠代中，User Story是否嚴格按照優先級别來實現
XP是務必要遵守優先級别的。但Scrum在這點做得很靈活，可以不按照優先級别來做，Scrum這樣處理的理由是：如果優先問題的解決者，由于其它事情耽擱，不能認領任務，那麼整個進度就耽誤了。另外一個原因是，如果按優先級排序的User Story #6和#10，雖然#6優先級高，但是如果#6的實現要依賴于#10，則不得不優先做#10。
區别之四：軟件的實施過程中，是否采用嚴格的工程方法，保證進度或者質量
Scrum沒有對軟件的整個實施過程開出工程實踐的處方，要求開發者自覺保證。但XP對整個流程方法定義非常嚴格，規定需要采用TDD、自動測試、結對編程、簡單設計、重構等約束團隊的行為。
“豬”角色
豬是全身投入項目和Scrum過程的人；they are the ones with "their bacon on the line."
産品負責人代表了客戶的意願。這保證了Scrum團隊在做從業務角度來說正确的事情。産品負責人編寫用戶故事，排出優先級，并放入産品訂單。Scrum主管（或促進者）促進Scrum過程，他的主要工作是解決那些影響團隊交付沖刺目标的障礙。Scrum主管并非團隊的領導（由于他們是自我組織的），而是負責屏蔽外界對開發團隊的幹擾。Scrum主管确保Scrum過程按照初衷進行。Scrum主管是規則的執行者。開發團隊是負責交付産品的團隊。由5至9名具有跨職能技能的人（設計者，開發者等）組成小團隊來完成實際的開發工作。
“雞”角色
雞角色并不是實際Scrum過程的一部分，但是必須考慮他們。使用戶和利益相關者參與到過程中是敏捷方法的一個重要實踐。“雞”角色參與每一個沖刺的評審和計劃，并提供反饋，對于Scrum過程來說是非常重要的。
用戶軟件是為用戶而創建的！就像“假如森林裡有一棵樹倒下了，但沒有人聽到，那麼它算發出了聲音嗎”，“假如軟件沒有被使用，那麼它算是被開發出來了麼？”利益所有者（客戶，提供商）是影響項目成功與否的人，他們隻直接參與到沖刺評審的過程中。經理是為産品開發團體架起環境的那個人。
會議
在沖刺中，每一天都會舉行項目狀況會議，被稱為“scrum”或“每日站立會議”。每日站立會議有一些具體的指導原則：
會議準時開始。對于遲到者團隊常常會制定懲罰措施（例如罰款，做俯卧撐，在脖子上挂橡膠雞玩具）歡迎所有人參加，但隻有"豬"可以發言。不論團隊規模大小，會議被限制在15分鐘。所有出席者都應站立。（有助于保持會議簡短）會議應在固定地點和每天的同一時間舉行。在會議上，每個團隊成員需要回答三個問題：
你完成了哪些工作？以後你打算做什麼？完成你的目标是否存在什麼障礙？（Scrum主管需要記下這些障礙）
每一個沖刺完成後，都會舉行一次沖刺回顧會議，在會議上所有團隊成員都要反思這個沖刺。舉行沖刺回顧會議是為了進行持續過程改進。會議的時間限制在4小時。
Scrum提倡所有團隊成員坐在一起工作，進行口頭交流，以及強調項目有關的規範（disciplines），這些有助于創造自我組織的團隊。
Scrum的一個關鍵原則是承認客戶可以在項目過程中改變主意，變更他們的需求，而預測式和計劃式的方法并不能輕易地解決這種不可預見的需求變化。同樣，Scrum采用了經驗方法–承認問題無法完全理解或定義，而是關注于如何使得開發團隊快速推出和響應不斷出現的需求的能力最大化。
文檔
産品訂單
産品訂單（product backlog）是整個項目的概要文檔。産品訂單包括所有所需特性的粗略的描述。産品訂單是關于将要創建的什麼産品。産品訂單是開放的，每個人都可以編輯。産品訂單包括粗略的估算，通常以天為單位。估算将幫助産品負責人衡量時間表和優先級（例如，如果"增加拼寫檢查"特性的估計需要花3天或3個月，将影響産品負責人對該特性的渴望）.
沖刺訂單
沖刺訂單（sprint backlog）是大大細化了的文檔，包含團隊如何實現下一個沖刺的需求的信息。任務被分解為以小時為單位，沒有任務可以超過16個小時。如果一個任務超過16個小時，那麼它就應該被進一步分解。沖刺訂單上的任務不會被分派，而是由團隊成員簽名認領他們喜愛的任務。
燃盡圖
燃盡圖（burn down chart）是一個公開展示的圖表，顯示當前沖刺中未完成的任務數目，或在沖刺訂單上未完成的訂單項的數目。不要把燃盡圖與掙值圖相混淆。燃盡圖可以使'沖刺（sprint）'平穩的覆蓋大部分的叠代周期，且使項目仍然在計劃周期内。
項目管理
以下是一些Scrum的通用實踐：
客戶成為開發團隊中的一部分。（例如客戶肯定對開發的結果真正感興趣。）和所有其他形式的敏捷軟件過程一樣，Scrum有頻繁的包含可以工作的功能的中間可交付成果。這使得客戶可以更早的得到可以工作的軟件，同時使得項目可以變更項目需求以适應不斷變化的需求。頻繁的風險和緩解計劃是由開發團隊自己制定。–在每一個階段根據承諾進行風險緩解，監測和管理（風險分析）。計劃和模塊開發的透明–讓每一個人知道誰負責什麼，以及什麼時候完成。頻繁的進行所有相關人員會議，以跟蹤項目進展–平衡的（發布，客戶，員工，過程）儀表闆更新–所有相關人員的變更–你必須擁有預警機制，例如提前了解可能的延遲或偏差。沒有問題會被藏在地毯下。認識到或說出任何沒有預見到的問題并不會受到懲罰。在工作場所和工作時間内必須全身心投入。–完成更多的工作并不意味着需要工作更長時間。
術語
下面是Scrum用到的術語：
角色
産品負責人Product Owner：負責維護産品訂單的人，代表利益相關者的利益。
Scrum主管Scrum Master：為Scrum過程負責的人，确保scrum的正确使用并使得Scrum的收益最大化。一般不翻譯。
開發團隊Team：由負責自我管理開發産品的人組成的跨職能團隊。
工件
産品列表Product Backlog：根據用戶價值進行優先級排序的高層需求。
沖刺訂單Sprint Backlog：要在沖刺中完成的任務的清單。
産品增量Increment：最終交付給客戶的内容
活動
計劃會Sprint Planning Meeting：在每個沖刺之初，由産品負責人講解需求，并由開發團隊進行估算的計劃會議。
每日立會Daily Standup Meeting：團隊每天進行溝通的内部短會，因一般隻有15分鐘且站立進行而得名。
評審會Review Meeting：在沖刺結束前給産品負責人演示并接受評價的會議。
反思會/回顧會Retrospective Meeting：在沖刺結束後召開的關于自我持續改進的會議。
其他
沖刺Sprint：一個時間周期（通常在2周到1個月之間），開發團隊會在此期間内完成所承諾的一組訂單項的開發。
其他領域
雖然Scrum最初隻應用于軟件開發，它也可以被成功地應用于其他産業。當前Scrum通常被認為是一種用于開發任何産品或管理人和工作的叠代式的，增量的過程。
用于産品開發
将Scrum應用于産品開發是在《"T新新産品開發遊戲"》（哈佛商業評論86116:137-146，1986年）第一次提出，之後野中郁次郎和竹内弘高合著的《"創造知識的企業"》（牛津大學出版社，1995年）進行了詳細的闡述。當前Scrum被用于開發金融産品，互聯網産品，以及醫藥産品。
項目管理方法
由于市場營銷通常以項目的方式運作，許多一般項目管理的原則應用在市場營銷上。市場營銷也可以像項目管理技術那樣進行優化。以Scrum方法進行市場營銷被認為有助于克服市場營銷經理們所遇到的問題。短時和固定的會議對于小的市場營銷團隊來說很重要，這是因為團隊的每一個成員都可以了解其他人在做些什麼，以及整個團隊在朝着什麼方向前進。Scrum在市場營銷中應用可以：
在早期發現可能的問題，可以更快地，最小損失地應對問題。根據Scrum的主要原則“沒有問題被掃入地毯下”，Scrum鼓勵每一個團隊成員描述他所遇到的困難，而這個困難可能會對整個團隊的工作造成影響。降低财務風險。在每一個沖刺周期的開始，企業所有者可以不付出任何代價的改變任何市場營銷的因素：包括增加投資以誇大顧客數量，減少投資直至未知風險被減輕，或用于支持其他活動。使得市場營銷計劃更靈活。采用沖刺的短期市場營銷計劃可以更加有效。如果一種促銷方法在沖刺過程中顯示無效，市場營銷經理有機會将其換成另一種促銷方法。向每一個團隊成員說明每一個小的，但重要的任務的交付時間也變得更容易。使得客戶以不同的方式參與。
