Scrum - 维基百科，自由的百科全书

Scrum是用於開發、交付和維持錯綜複雜產品(complex products) 的敏捷框架(framework) 。

最初著重於軟體開發，之後已被用應用於其他領域，包括研究、銷售、營銷和其他 ... Scrum 語言 監視 編輯 Scrum是用於開發、交付和維持錯綜複雜產品(complexproducts)的敏捷框架(framework)[1]。

最初著重於軟體開發，之後已被用應用於其他領域，包括研究、銷售、營銷和其他先進技術領域。

一個Scrum團隊建議為十名成員的團隊而設計的，他們以迭代[2](iterative)與增量[3](incremental)式的方式交付工作，每個迭代稱作Sprint。

一個Sprint的時間不超過一個月，通常是兩星期。

Scrum團隊在每個Sprint都專注在唯一一個共同的目標(SprintGoal)，每天的DailyScrum團隊中的開發人員(Developers)都檢視朝向這共同目標的進度，和調適當下的計畫。

在Sprint結束時，團隊會進行Sprint審查(SprintReview)跟利害關係人(Stakeholders)一起檢視當下的結果與調適計畫，這是互相資訊交流的機會。

最後，團隊會進行Sprint回顧(SprintRetrospective)來持續改善。

目次 1歷史 2Scrum的特性 3Scrum中的角色 3.1豬組的成員 3.2雞組的成員 4Scrum會議 5文檔 5.1產品訂單 5.2衝刺訂單 5.3燃盡圖 6自適應的專案管理 7Scrum在其他領域的應用 7.1Scrum用於產品開發 7.2Scrum用作營銷專案管理方法 8參見 9外部連結 10參考文獻 11延伸閱讀 歷史編輯 1986年，竹內弘高(HirotakaTakeuchi)和野中郁次郎(IkujiroNonaka)在其1986年的《哈佛商業評論》文章「TheNewNewProductDevelopmentGame」中，闡述了一種新的整體性的方法，該方法能夠提高商業新產品開發的速度和靈活性：[4]文章中在產品開發的背景下引入了術語scrum，他們將這種新的整體性方法與橄欖球相比較，前者各階段相互重疊，並且由一個跨職能團隊在不同的階段完成整個過程，而團隊「作為一個整體前進，把球傳來傳去」。

他們對來自汽車，照片機器，計算機和印表機等產業的案例進行了研究。

1991年，PeterDeGrace和LeslieHuletStahl在《WickedProblems,RighteousSolutions》[5]一書中將這種方法稱為scrum，引用在竹內弘高和野中郁次郎的文章中提到的scrum術語。

1990年代初， 肯·施瓦伯(KenSchwaber)在其公司AdvancedDevelopmentMethods[6]使用了一種方法，這種方法後來發展為Scrum。

同時，傑夫·薩瑟蘭(JeffSutherland)在Easel公司開發了一種類似的方法，並使用單個詞scrum來代表這方法。

[7] 1995年，在奧斯汀舉辦的OOPSLA'95上，薩瑟蘭和施瓦伯聯合發表了論文首次提出了Scrum概念。

施瓦伯和薩瑟蘭在接下的幾年裡合作，將上述的文章，他們的經驗，以及業界的最佳實踐融合起來，形成我們現在所知的Scrum。

2001年，肯·施瓦伯(KenSchwaber)與麥克·比竇（MikeBeedle）合著了《敏捷軟體開發-使用Scrum過程》[8]一書，介紹了Scrum方法。

2002年,肯·施瓦伯(KenSchwaber)與MikeCohn、EstherDerby共同建立了Scrum聯盟(ScrumAlliance)[9]並建立了CertifiedScrum認證系列。

2009年末，肯·施瓦伯(KenSchwaber)離開了Scrum聯盟(ScrumAlliance),創立了Scrum.org[10],該機構負責監督並行的ProfessionalScrum認證系列。

[11][12][13]自2009年以來，肯·施瓦伯(KenSchwaber)和傑夫·薩瑟蘭(JeffSutherland)已發布並更新了名為《Scrum指南》(ScrumGuide)[14]的公共文件。

該版本已被修訂6次，當前版本為2020年11月。

2020年5月，傑夫·薩瑟蘭(JeffSutherland)在2006年創立的ScrumInc公司，開始教授'ScrumInc認證系列『[15]Scrum的特性編輯  Scrum過程 Scrum是一個包括了一系列實踐和預定義角色的過程骨架。

Scrum中的主要角色包括： ScrumMaster是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，並幫助團隊掃除實施中的障礙； 產品負責人，確定產品的方向和願景，定義產品發布的內容、優先級及交付時間，為產品投資報酬率負責； 開發團隊，一個跨職能的小團隊，人數5-9人，團隊擁有交付可用軟體需要的各種技能。

在每一次衝刺或迭代（一個15到30天的周期，其長度由開發團隊決定）當中，開發團隊創建可用的（可以隨時推出）軟體的一個增量。

每一個迭代所要實現的功能來自產品訂單。

產品訂單按照優先級排列工作需求。

在迭代計劃會議中，產品負責人告訴開發團隊需要完成產品訂單中的哪些訂單項。

開發團隊決定在下一次迭代中他們能夠承諾完成多少訂單項。

在迭代的過程中，沒有人能夠變更迭代訂單，這意味著在一個迭代中需求是被凍結的。

管理Scrum過程有很多實施方法，如即時貼、白板、甚至軟體包。

Scrum最大的好處之一是它非常容易學習，而且啟動Scrum應用並不需要太多的投入。

Scrum中的角色編輯 Scrum當中定義了許多角色。

按照對開發過程的參與情況，這些角色被分為兩組，即豬組和雞組。

這個分組方法的由來是一個關於豬和雞合夥開餐館的笑話[16]： 一天，一頭豬和一隻雞在路上散步。

雞對豬說：「嗨，我們合夥開一家餐館怎麼樣？」 豬回頭看了一下雞說：「好主意，那你準備給餐館起什麼名字呢？」 雞想了想說：「叫『火腿和雞蛋』怎麼樣？」 「那可不行」，豬說：「我把自己全搭進去了，而你只是參與而已。

」 豬組的成員編輯 豬是在Scrum過程中全身投入專案的各種人物，他們在專案中承擔實際工作。

他們有些像上邊那個笑話裡的豬，要把自己身上的肉貢獻出來。

產品負責人（productowner） 產品負責人代表了客戶的意願。

這保證了Scrum團隊在做從業務角度來說正確的事情。

產品負責人編寫用戶故事，排出優先級，並放入產品訂單。

Scrum主管（或促進者）（scrummaster） Scrum主管促進Scrum過程，他的主要工作是去除那些影響團隊交付沖刺目標的障礙。

Scrum主管並非團隊的領導（因為團隊是自我組織的），而是一個負責屏蔽外界對開發團隊的干擾的角色。

Scrum主管確保Scrum過程被按照初衷使用。

Scrum主管是規則的執行者。

開發團隊（devteam） 負責交付產品的團隊。

一個團隊通常由5至9名具有跨職能技能的人（設計者，開發者等）組成，承擔實際的開發工作。

雞組的成員編輯 雞並不是實際Scrum過程的一部分，但是必須考慮他們。

敏捷方法的一個重要方面是使得用戶和利益相關者參與到過程中的實踐。

參與每一個衝刺的評審和計劃，並提供反饋對於這些人來說是非常重要的。

用戶 軟體是為了人而開發的。

有人說，「假如森林裡有一棵樹倒下了，但沒有被人聽到，那麼它算是發出了聲音嗎？」同樣地，人們可以說，「假如軟體沒有被使用，那麼它算是被開發出來了麼？」 利益相關者（客戶，提供商） 影響項目成功的人，但只直接參與衝刺評審過程。

經理 為產品開發團體搭建環境的人。

Scrum會議編輯 參見：站會  在辦公室中間進行的「每日站立會議」，會議的位置有助於會議準時開始 在衝刺中，每一天都會舉行項目狀況會議，被稱為「scrum」或「每日站立會議」。

每日站立會議有一些具體的指導原則： 會議準時開始。

歡迎所有人參加，但只有「豬」可以發言。

不論團隊規模大小，會議被限制在15分鐘。

所有出席者都應站立。

（有助於保持會議簡短） 會議應在固定地點和每天的同一時間舉行。

在會議上，每個團隊成員需要回答三個問題： 昨天你完成了那些工作？ 今天你打算做什麼？ 完成你的目標是否存在什麼障礙？（Scrum主管需要記下這些障礙）每一個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上所有團隊成員都要反思這個衝刺。

舉行衝刺回顧會議是為了進行持續過程改進。

會議的時間限制在4小時。

Scrum提倡所有團隊成員坐在一起工作，進行口頭交流，以及強調項目有關的規範（disciplines），這些有助於創造自我組織的團隊。

Scrum的一個關鍵原則是承認客戶可以在項目過程中改變主意，變更他們的需求，而預測式和計劃式的方法並不能輕易地解決這種不可預見的需求變化。

同樣，Scrum採用了經驗方法–承認問題無法完全理解或定義，而是關注於如何使得開發團隊快速推出和響應不斷出現的需求的能力最大化。

Scrum會議一共包含以下四種： 衝刺計劃會議 每日站立會議 評審會議 回顧會議。

文檔編輯 產品訂單編輯 產品訂單（productbacklog）是整個專案的概要文檔。

產品訂單包括所有所需特性的粗略的描述。

產品訂單是關於將要生產什麼樣的產品。

產品訂單是開放的，每個人都可以編輯。

產品訂單包括粗略的估算，通常以天為單位。

估算將幫助產品負責人衡量時程表和優先順序（例如，如果"增加拼寫檢查"特性的估計需要花3天或3個月，將影響產品負責人對該特性的渴望）。

衝刺訂單編輯 衝刺訂單（sprintbacklog）是大大細化了的文檔，包含團隊如何實現下一個衝刺的需求的信息。

任務被分解為以小時為單位，沒有任務可以超過16個小時。

如果一個任務超過16個小時，那麼它就應該被進一步分解。

衝刺訂單上的任務不會被分派，而是由團隊成員簽名認領他們喜愛的任務。

燃盡圖編輯 燃盡圖（burndownchart）是一個公開展示的圖表，顯示當前衝刺中未完成的任務數目，或在衝刺訂單上未完成的訂單項的數目。

不要把燃盡圖與掙值圖相混淆。

燃盡圖可能在一次衝刺的大部分時間內都維持平坦，但計畫仍然可以按照既定時間進行。

自適應的專案管理編輯 以下是一些Scrum的通用實踐： 客戶成為開發團隊中的一部分。

（例如客戶肯定對開發的結果真正感興趣。

） 和所有其他形式的敏捷軟體過程一樣，Scrum有頻繁的包含可以工作的功能的中間可交付成果。

這使得客戶可以更早的得到可以工作的軟體，同時使得項目可以變更項目需求以適應不斷變化的需求。

開發團隊經常評估風險並制定緩解計劃。

在每一個階段根據承諾進行風險緩解，監測和管理（風險分析）。

計劃和模塊開發要保持透明，讓每一個人知道誰負責什麼，以及什麼時候完成。

參與者要經常開會以跟蹤項目進展–平衡的（發布，客戶，員工，過程）儀錶板更新–利益所有者更新。

你必須擁有預警機制，例如在可能延期交付時提出警告。

不要隱藏問題。

認識到或說出任何沒有預見到的問題並不會受到懲罰。

在工作場所和工作時間內必須全身心投入。

–完成更多的工作並不意味著需要工作更長時間。

Scrum在其他領域的應用編輯 雖然Scrum最初只應用於軟體開發，它也可以被成功地應用於其他產業。

現在Scrum通常被認為是一種用於開發任何產品或管理人和工作的迭代式的，增量的過程。

Scrum用於產品開發編輯 將Scrum應用於產品開發是在《新新產品開發遊戲》[4]第一次提出，之後野中郁次郎和竹內弘高合著的《創造知識的企業》（牛津大學出版社，1995年）進行了詳細的闡述。

今天Scrum被用於開發金融產品，網際網路產品，以及醫藥產品。

Scrum用作營銷專案管理方法編輯 由於市場行銷通常以專案的方式運作，許多一般專案管理的原則應用在市場行銷上。

市場行銷也可以像專案管理技術那樣進行優化。

以Scrum方法進行市場行銷被認為有助於克服市場行銷經理們所遇到的問題。

短時和固定的會議對於小的市場行銷團隊來說很重要，這是因為團隊的每一個成員都可以了解其他人在做些什麼，以及整個團隊在朝著什麼方向前進。

Scrum在市場行銷中應用可以： 在早期發現可能的問題，可以更快地，最小損失地應對問題。

根據Scrum的主要原則「沒有問題被掃入地毯下」，Scrum鼓勵每一個團隊成員描述他所遇到的困難，而這個困難可能會對整個團隊的工作造成影響。

降低財務風險。

在每一個衝刺周期的開始，企業所有者可以不付出任何代價的改變任何市場行銷的因素：包括增加投資以擴大顧客數量，減少投資直至未知風險被減輕，或用於支持其他活動。

使得市場行銷計劃更靈活。

採用衝刺的短期市場行銷計劃可以更加有效。

如果一種促銷方法在衝刺過程中顯示無效，市場行銷經理有機會將其換成另一種促銷方法。

向每一個團隊成員說明每一個小的，但重要的任務的交付時間也變得更容易。

使得客戶以不同的方式參與。

參見編輯 改善法 用戶故事 特性驅動開發（英語：Feature-drivendevelopment） 極限編程(XP)-通常由Scrum驅動 燃盡圖 看板(軟體開發) 精益軟體開發 專案管理 UnifiedProcess（英語：UnifiedProcess） 規範敏捷交付（英語：Disciplinedagiledelivery） 基於大規模的敏捷框架（英語：ScaledAgileFramework）（SAFe） Scrum度量和關鍵績效指標（頁面存檔備份，存於網際網路檔案館） 外部連結編輯 捷伴行Agile（頁面存檔備份，存於網際網路檔案館） Scrum精髓中文網站（頁面存檔備份，存於網際網路檔案館） Scrum中文交流社區（頁面存檔備份，存於網際網路檔案館） Scruminfiveminutes ScrumAlliance Scrum.org（頁面存檔備份，存於網際網路檔案館） ScrumandXPfromtheTrenches Scrumarticlesdirectory AgileAlliance'sScrumlibrary InfoQ.com/Agile（頁面存檔備份，存於網際網路檔案館）-Trackingchangeandinnovationintheenterprisesoftwaredevelopmentcommunity(News,Articles,Books,Video) AgiloforScrum(OpenSourceScrumTool,ScrumSoftware) ScrumandXPfromtheTrenches（頁面存檔備份，存於網際網路檔案館）byHenrikKniberg.A130-pagePDFbookdescribingindetailhowScrumandXPcanbeimplementedfromapracticalperspectiveTheNewNewProductDevelopmentGame（頁面存檔備份，存於網際網路檔案館）byTakeuchiandNonaka.Thepaperthatstarteditall. ScrumDeliversorScrumandtheToyotaWaybyBorisGloger.ThispapermapstheprinciplesofToyotaexplainedbyLiker,withthepracticesofScrum.參考文獻編輯 ^Schwaber,Ken;Sutherland,Jeff.Scrum指南.ScrumGuides.org.ScrumGuides.org.[Feb9,2021].（原始內容存檔於2021-06-02）.  ^NationalAcademyforEducationResearch.Iteration.國家教育研究院.國家教育研究院.[2021-02-09].（原始內容存檔於2021-02-09）.  ^NationalAcademyforEducationalResearch.Incremental.國家教育研究院.國家教育研究院.[Feb9,2021].（原始內容存檔於2021-02-09）.  ^4.04.1TakeuchiandNonaka:TheNewNewProductDevelopmentGame(HarvardBusinessReview,Jan-Feb1986) ^PeterDeGrace,LeslieHuletStahl,Wickedproblems,righteoussolutions,1990,ISBN0-13-590126-X ^AdvancedDevelopmentMethods,IncCompanyProfile.Dun&Bradstreet.  ^JeffSutherland,AGILEDEVELOPMENT:LESSONSLEARNEDFROMTHEFIRSTSCRUM,2004(PDF).[2008-08-16].（原始內容存檔(PDF)於2008-05-17）.  ^AgileSoftwareDevelopmentwithScrum.2002.  ^Maximini,Dominik.TheScrumCulture:IntroducingAgileMethodsinOrganizations.ManagementforProfessionals.Cham:Springer.January8,2015:26(2015)[August25,2016].ISBN 9783319118277.（原始內容存檔於2021-04-14）.KenSchwaberandJeffSutherlandpresentedScrumforthefirsttimeattheOOPSLAconferenceinAustin,Texas,in1995.[...]In2001,thefirstbookaboutScrumwaspublished.[...]Oneyearlater(2002),KenfoundedtheScrumAlliance,aimingatprovidingworldwideScrumtrainingandcertification. 請檢查|publication-date=中的日期值(幫助) ^Home.Scrum.org.[January6,2020].（原始內容存檔於2021-06-08）（英語）.  ^AletterfromKenSchwaber.2009ControlChaos-MessagefromKen.[Feb16,2021].（原始內容存檔於2006-12-14）.  ^KenSchwaber.KenSchwaber在Blog自述2006年接到的一通電話….KenSchwaber'sBlog.[2021-02-16].（原始內容存檔於2020-08-08）.  ^PaddyCorry.在成立ScrumAlliance七年後的2009年，Schwaber在對幫助傳播Scrum一詞的認證計劃存在分歧之後，陷入了一片陰影….Medium:Serious-Scrum.[2021-02-16].（原始內容存檔於2021-01-26）.  ^Schwaber,Ken;Sutherland,Jeff.Scrum指南.ScrumGuides.org.ScrumGuides.org.[Feb15,2021].（原始內容存檔於2021-06-02）.  ^許慈真／北美智權報　專欄作家.從Scrum一案看美國商標訴訟如何取得暫時禁制令：.北美智權報.[2021-02-16].（原始內容存檔於2020-11-27）.  ^KenSchwaber.AgileProjectManagementwithScrum.MicrosoftPress.2004年1月:7.ISBN 0-7356-1993-X.  (PDF)Rising,L.,Janoff,N.S.(2000).TheScrumSoftwareDevelopmentProcessforSmallTeamsRetrievedMarch15，2007 (PDF)Schwaber,K.AdvancedDevelopmentMethods.SCRUMDevelopmentProcess（頁面存檔備份，存於網際網路檔案館）RetrievedAugust15，2006 (video)JeffSutherlandinScrumTuning:LessonslearnedfromScrumimplementationatGoogle（頁面存檔備份，存於網際網路檔案館）Retrieved2007-12-15 (video)KenSchwaberinScrumetal.（頁面存檔備份，存於網際網路檔案館）Retrieved2008-01-19 延伸閱讀編輯 Vacaniti,Daniel.TheKanbanGuideforScrumTeams(PDF).scrum.org.February2018[2018-03-12].（原始內容(PDF)存檔於2021-11-19）.  Sutherland,Jeff;Schwaber,Ken.ScrumGuides.ScrumGuides.org.2013[2017-07-26].（原始內容存檔於2017-07-25）.  Verheyen,Gunther(2013).Scrum-APocketGuide(ASmartTravelCompanion)ISBN 978-9087537203. Münch,Jürgen;Armbrust,Ove;Soto,Martín;Kowalczyk,Martin.SoftwareProcessDefinitionandManagement.2012.ISBN 978-3-642-24291-5.  Deemer,Pete;Benefield,Gabrielle;Larman,Craig;Vodde,Bas.TheScrumPrimer.2009[2009-06-01].（原始內容存檔於2011-06-27）.  Janoff,N.S.;Rising,L.TheScrumSoftwareDevelopmentProcessforSmallTeams(PDF).2000[2015-02-26].（原始內容存檔(PDF)於2015-11-06）.  取自「https://zh.wikipedia.org/w/index.php?title=Scrum&oldid=72277811」