Scrum

Scrum是疊代式增量軟體開發過程，通常用於敏捷軟體開發。Scrum包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括同項目經理類似的Scrum主管角色負責維護過程和任務，產品負責人代表利益所有者，開發團隊包括了所有開發人員。雖然Scrum是為管理軟體開發項目而開發的，它同樣可以用於運行軟體維護團隊，或者作為計畫管理方法：Scrum of Scrums.

基本介紹

• 外文名：Scrum
• 定義：是一種疊代式增量軟體開發過程
• 套用：敏捷軟體開發
• 包括：實踐和預定義角色的過程骨架

創始人

Jeff Sutherland

Jeff Sutherland的第一份工作居然是美國空軍戰鬥機飛行員，還曾於1967年獲得了“壯志凌雲”稱號，完成過100次飛越北部越南的作戰任務。服役後期，他到史丹福大學拿下統計學碩士學位，並在美國空軍學院教授數學統計學和機率學。11年軍旅生涯結束後，他成為了科羅拉多醫學院的教師並獲得了博士學位。在諾貝爾化學獎得主萊納斯·鮑林的贊助下，他以放射學、生物學及預防醫學助理教授的身份參與了維生素與癌症研究中心的創立，擔任八年國家癌症中心的主要研究員，負責科羅拉多地區所有癌症患者的數據統計和IT方案與研究，整合了國家註冊、臨床試驗、流行病學研究和癌變的超級計算機數學模型。1983年，他進入了一家遍及北美、經營著150家銀行的公司，職務為先進系統副總裁及ATM業務部總經理。此後，Sutherland先後擔任了11家軟體公司的CEO、CTO或者工程副總裁，積累了豐富的軟體開發經驗。

Jeff Sutherland

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”或“每日站立會議”。每日站立會議有一些具體的指導原則：

會議準時開始。對於遲到者團隊常常會制定懲罰措施（例如罰款，做伏地挺身，在脖子上掛橡膠雞玩具）歡迎所有人參加，但只有"豬"可以發言。不論團隊規模大小，會議被限制在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鼓勵每一個團隊成員描述他所遇到的困難，而這個困難可能會對整個團隊的工作造成影響。降低財務風險。 在每一個衝刺周期的開始，企業所有者可以不付出任何代價的改變任何市場行銷的因素：包括增加投資以誇大顧客數量，減少投資直至未知風險被減輕，或用於支持其他活動。使得市場行銷計畫更靈活。採用衝刺的短期市場行銷計畫可以更加有效。如果一種促銷方法在衝刺過程中顯示無效，市場行銷經理有機會將其換成另一種促銷方法。向每一個團隊成員說明每一個小的，但重要的任務的交付時間也變得更容易。使得客戶以不同的方式參與。