關於 Scrum (About Scrum) 

管理框架 Scrum是⼀個適⽤於增量式產品開發的管理框架，由⼀個或多個平均7⼈ 左右的團隊組成。 它提供了⼀個包含⾓⾊、會議、規則和⼯件的結構。團隊負責在此框架 範圍內建立和調整他們的流程。 Scrum使⽤固定時間長度的迭代，稱為Sprint，通常是2周到30天之間。 Scrum團隊試圖每⼀個迭代都構建初⼀個潛在可交付（充分測試過）的 產品增量。

替代瀑布的⼜⼀選擇 (An Alternative to Waterfall)

Scrum採取增量迭代⽅式，拋棄了“瀑布”開發的傳統階段，以獲得可以 快速地吸納反饋、優先開發⼀部分⾼價值特性的能⼒。

。

能夠發揮Scrum最⼤功⼒的，是牽涉到知識創造和協作的複雜型⼯作， 例如新產品開發。Scrum通常都跟⾯向物件軟體開發關聯在⼀起。它也 被⽤在了半導體、抵押貸款和輪椅等產品的開發中。

真的做Scrum，還是在裝樣⼦？ Doing Scrum, or Pretending to Do Scrum?)

Scrum持續地進⾏實況檢查，從⽽暴露出個體、團隊和組織⽅⾯受到的 不合理約束情況。很多⼈說是在做Scrum，實際上卻對那些需要去破除 組織障礙的地⽅都進⾏了修改，失去了獲得⼤量好處的機會。

Scrum ⾓⾊ (Scrum Roles)

產品負責⼈ (Product Owner)

• 最⼤化研發⼯作投⼊回報（ROI）的單⼀責任⼈

• 負責產品願景 • 持續地按優先順序順序重排產品列表，對長期性的所有預期進⾏調整， ⽐如說釋出計劃

• 需求問題的最終裁決者

• 接受或拒絕單個產品增量

• 決定是否要釋出

• 決定是否要繼續開發

• 照顧⼲系⼈的利益

• 也可能以團隊成員⾝份做出貢獻

• 是⼀個需要起到領導作⽤的⾓⾊

Scrum 開發團隊 (Scrum Development Team)

• 跨職能（例如，包括了具備測試技能的成員，以及業務分析師、領域 專家等⼀些過去通常不被稱作開發⼈員的其他⼈）

• ⾃組織/⾃管理，⽆需團隊之外的專⼈管理

• 跟產品負責⼈協商Sprint的承諾問題，每個Sprint⼀次

• 可以⾃主決定如何兌現承諾

• ⾼度協作

• 都待在⼀間團隊室⾥的效果最好，尤其適⽤於最開始的⼏個Sprint

• 隊員長期、全職參與的⽅式效果最好。Scrum把⼯作帶給靈活且快速 學習的團隊，以避免調動⼈員或是把⼈拆散到團隊。

• 5~9名成員 • 是⼀個需要起到領導作⽤的⾓⾊

ScrumMaster

• 引導Scrum的流程 • 協助移除障礙

• 建立⼀個可促進團隊⾃組織的環境

• 收集經驗資料以調整預期

• 隔離團隊的外部⼲擾和分⼼事，以保持團隊⼼流狀態（也即⼼流區）

• 保障時間盒

• 保持Scrum⼯件始終可見

• 推動改善⼯程實踐

• 沒有任何團隊管理職權（任何具有團隊職權的⼈預設都不是團隊的 ScrumMaster）

• 是⼀個需要起到領導作⽤的⾓⾊

Scrum 會議 (Scrum Meetings)

Sprint 計劃會議 (Sprint Planning Meeting)

每個Sprint剛開始的時候，產品負責⼈跟團隊⼀起召開Sprint計劃會議， 商討在這個Sprint中他們想把哪些產品列表條⽬變成為可⼯作的產品。 產品負責⼈負責講清楚對於業務來說哪些需求是最重要的。團隊則負責 選定在不積累技術債務情況下可完成的⼯作。團隊將⼯作從“產品列表” 拉⼊Sprint列表。

在⾯對具有內在不確定性的複雜型⼯作時，團隊除了參考前述Sprint的 情況，還必須協作以便更直觀地瞭解⼤家承諾⼯作項的能⼒。計算可⽤ ⼩時數、⽐較估算值跟實際值的⽅式，會導致團隊⾃以為很精確，還會 削弱團隊的主⼈翁意識。除⾮⼯作真的可預測，否則他們就該在前⼏個 Sprint就放棄這類實踐甚⾄是徹底不⽤。

在團隊學會如何每個Sprint都能完成⼀個潛在可交付的產品增量之前， 團隊應該削減他們所承諾完成功能的數量。若⽆法改變積習，將會產⽣ 技術債務甚⾄是設計壞死（如圖15所⽰）。

如果產品列表頂部的內容尚未確定，那就需要佔⽤計劃會議⼤部分時間 都⽤來做這件事，就如列表修整會議章節所述。

Sprint計劃會議快結束的時候，團隊把所選擇的條⽬拆分成Sprint任務， 得到⼀份初始清單，並對⼯作做出最終承諾。 30天的Sprint，分配給計劃會議的最⼤時長（也即時間盒）是8個⼩時， 對於較短的Sprint，也要相應地縮減會議時間。

Scrum⽇會和Sprint執⾏ (Daily Scrum and Sprint Execution)

每天在相同時間相同地點，Scrum開發隊員們花費總計15分鐘相互報告 情況。每名隊員都要總結他昨天做了什麼、今天將要做什麼，以及是否 遇到了障礙。

站著開Scrum⽇會，有助於保持會議簡短。如果有需要額外關注的話題 可以等所有⼈都報告完之後感興趣的⼈再繼續討論。

團隊或許會發現，維護使⽤⼀份當前Sprint任務列表、⼀張Sprint燃盡圖 以及⼀個障礙列表是很有⽤的。在Sprint執⾏過程中，發現要達成Sprint ⽬標必需新增任務，是很常見的情況。那些由團隊控制範圍之外的問題 所造成的障礙，應視作組織級障礙。

產品負責⼈如果能參加Scrum⽇會，通常都會有所收穫。但如果有任何 參會者同時也是團隊主管，隱形槍效應就會阻礙⾃組織和演進式領導⼒ 的形成。缺乏團隊⾃組織的實際經驗的⼈往往看不到這個問題的存在， 就跟魚⼉看不見⽔⼀樣。反過來說，產品負責⼈提⾼參與度能幫到那些 缺乏產品需求相關經驗的團隊，包括參加Scrum⽇會在內。

Scrum⽇會旨在破除獨⾃⼯作的積習。隊員們要警惕那些舊習慣復甦的 蛛絲馬跡。例如，只⾯對著ScrumMaster講話，就是其中的⼀種症狀， 表明團隊還沒有學會如何像⾃組織實體那樣運轉。

Sprint 評審會議 (Scrum Review Meeting)

Sprint執⾏之後，團隊召開Sprint評審會議，向產品負責⼈和其他有興趣 瞭解的⼈演⽰可⼯作的產品增量。 這個會議應該是現場演⽰，⽽不是作報告。 演⽰完之後，產品負責⼈逐個檢查在Sprint計劃會議上所做出的承諾， 並申明他認為哪些條⽬是完成的。例如，只有“編碼完成”的軟體條⽬是 被算作沒有完成的，因為沒有測過的軟體是⽆法交付的。未完成的條⽬ 會被打回產品列表，然後再根據產品負責⼈的最新優先順序順序判斷是否 放⼊後續Sprint。

ScrumMaster協助產品負責⼈和⼲系⼈將他們的意見轉化為新增的產品 列表條⽬，以便產品負責⼈進⾏優先順序排序。新發現的需求範圍往往都 會超出團隊開發的速率。如果產品負責⼈覺得新範圍⽐最初的預期更加 重要，新範圍就會取代舊範圍在產品列表中的位置。

Sprint評審會議是適合於外部⼲系⼈（甚⾄是最終⽤戶）參加的會議。 它是在產品演進過程中進⾏檢驗及適應，和⼈們不斷改進對需求理解的 機會。對於新產品，尤其是軟體產品來說，憑空想象是很難想出來的。 ⼤多數客戶都需要把軟體運⾏起來、⽤⼀⽤，才能發現他們⾃⼰真正想 要些什麼。迭代開發是⼀種價值驅動的⽅式，可⽤於建立那些⽆法按照 計劃驅動⽅式要求在前期就能講清楚的產品。

Sprint 回顧會議 (scrum Respective Meeting)

⼀個Sprint在回顧會議之後即告結束。團隊將在會上反思⾃⼰的流程。 他們檢驗⾃⼰的⾏為、採取措施以適應後續的Sprint。

全職的ScrumMaster會想⽅設法以避免使⽤了⽆新意、讓⼈畏懼的會議 形式。深度回顧需要在⼈們覺得⼼理安全的環境中才會出現，在⼤多數 組織中都缺乏這樣的環境。安全感的缺失會導致回顧討論變味，要麼是 ⼀團和⽓、避⽽不談敏感話題，要麼就變成了批⽃會，⼈們互相指責、 發洩敵意。

績效評估執⾏者的出現是影響團隊能否敞開⼼扉的⼀個常見阻礙。

⼈們急於得出結論、提出⾏動建議的偏好，是有效回顧的另⼀個障礙。 《敏捷回顧》1 是相關書籍中最為流⾏的⼀本，它通過⼀系列步驟來放慢 進⾏此過程：預設會議基調、收集資料、激發靈感、決定做什麼、總結 收尾。還推薦⼀本書給ScrumMaster們，《學問》將此過程拆解成⼏個 不同層次的相似步驟：客觀性層次、反映性層次、詮釋性層次、決定性 層次（ORID)。

地理位置分佈是做到⼼理安全的第三個障礙。散佈各地的團隊在協作上 通常都不如共處⼀室的團隊做得好。

回顧通常都會暴露出組織級障礙。在團隊解決了⾃⾝影響⼒範圍之內的 問題後，ScrumMaster應該接著擴⼤影響，⼊⼿解決組織級的問題。

ScrumMaster應該綜合運⽤包括默寫、時間線以及滿意度直⽅圖在內的 多種技術來引導回顧會議。任何情況下⽬標都⼀樣，要匯聚多種觀點以 形成共識，並尋求能夠帶領團隊更上⼀層樓的⾏動⽅案。

產品列表修整會議 (Backlog Refinement Meeting)

⼤多數產品列表條⽬（PBI）在初期都需要修整，因為它們個頭太⼤⽽且 很難理解。團隊們發現，可以在每個Sprint的執⾏過程中都拿出點時間 ⽤於為下⼀個Sprint計劃會議作準備，這種做法很有效。

在產品列表修整會議上，圍繞著產品列表上的條⽬，團隊針對他們完成 這些條⽬所需要的投⼊，並提供相關技術資訊以輔助產品負責⼈對它們 進⾏優先順序排序3。⼤且模糊的條⽬將被拆分並澄清，此過程中需要綜合 考慮業務和技術兩個⽅⾯進⾏處理。有時候也會在⼤家集體估算之前， 叫上團隊的少部分⼈，再加上產品負責⼈和其他⼲系⼈，把產品列表給 先理⼀理、拆⼀拆。

技藝嫻熟的ScrumMaster可以幫助團隊學會，如何在嚴守包含適量測試 和重構的“完成”定義的同時，去發現具有業務價值的⼯作豎切⽚。

編寫產品列表條⽬時普遍使⽤⽤戶故事的形式 。此⽅式中，過⼤的PBI 4 被稱作史詩級故事。傳統開發⽅式將特性拆解為橫向任務（按瀑布階段 進⾏組裝），它們既⽆法被獨⽴地進⾏優先順序排序，也缺乏從客戶⾓度 可見的業務價值。這種習慣很難打破。

敏捷⼒要求我們學會把⼤型的史詩故事拆分為可代表⼩個頭產品特性的 ⽤戶故事。例如，某醫療記錄應⽤的⼀個史詩故事“向醫⽣顯⽰患者過敏 記錄的全部內容”，從中可以提煉出“不管有沒有過敏記錄都進⾏顯⽰”。 此時，⼯程師預見的是解析過敏記錄內容所存在的技術⼤難題，然⽽， 到底有還是沒有過任何的過敏記錄，這才是醫⽣最想知道的重要資訊。 拆分史詩故事時，通過業務⼈員和技術⼈員的通⼒協作，找出了只需要 原始史詩故事20%的投⼊就能得到80%商業價值的故事。

⼤多數產品的⼤多數特性⼤多數客戶都不會⽤到，因⽽，明智的做法是 拆分史詩故事以便能先交付最有價值的那些故事。即便後續交付低價值 特性時可能要返⼯，那返⼯總⽐沒⼯好。

產品列表修整會議沒有官⽅名稱，通常被叫做“列表修整”、“列表維護”或 是“故事時間”。

 

Scrum ⼯件 (Scrum Artifacts)

• 所期望功能的排⾏榜 • 所有⼲系⼈可見

• 任何⼲系⼈（包括團隊）均可新增條⽬

• 產品負責⼈持續調整優先順序

• 頂部條⽬的粒度⽐底部條⽬更細

• 通過產品列表修整會議進⾏維護

產品列表條（PBI） (Product Backlog Item)

• 主要澄清⼀個以客戶為中⼼的特性是什麼，⽽⾮如何做

• 通常都寫成⽤戶故事的格式

• 制定產品級公⽤完成定義以防⽌技術債務發⽣

• 可以制定條⽬專⽤的接收標準

• ⼯作規模由團隊估算，理想狀況是使⽤相對單位值（例如，故事點）

• ⼯作規模應該在2~3個⼈⼯作2~3天左右，⾼級團隊會更⼩些

 Sprint 列表 (Sprint Backlog)

• 由Sprint計劃會議上團隊和產品負責⼈協商承諾的PBI所組成

• 在Sprint執⾏期間，所承諾範圍是固定不變的

• 初始任務是團隊在Sprint計劃會議上識別確定的

• 在Sprint執⾏期間，團隊將發現兌現既定範圍承諾還需要的附加任務

• 團隊可見

• 可供Scrum⽇會時參考使⽤

增量 (Increment)

• 在短跑期間完成的產品能力

• 在每次衝刺結束時帶到可用的可釋放狀態

• 與產品所有者希望的一樣頻繁釋出

• 在每次衝刺評審會議期間進行檢查

 Sprint 任務 (Sprint Tasks)

• 澄清達成PBI⽬標的⼿段

• 完⼯需要花費⼀天或更少的時間

• 每天都要重估剩餘⼯作量，通常以⼩時計數

• 在Sprint執⾏期間，每⼀個⼈可以主動認領⼀個任務

• 由整個團隊擁有；需要協作

Sprint 燃盡圖 (Sprint Burdown Chart)

• 顯⽰Sprint期間團隊總的任務剩餘時間

• 每天都重新估算，因⽽可能⾛⾼也可能⾛低

• 旨在引導團隊⾃組織

• 按⼈分條⽬或增加趨勢線等表⾯功夫會削弱⿎勵協作的效果

• 在Scrum發展早期很被看好，但由於在實踐中常被誤⽤為⼀份管理層 報告⽽備受爭議。如果它成為了團隊⾃組織的阻礙，ScrumMaster就 應該停⽌使⽤這個圖表。 

 產品/釋出燃盡圖 (Product / Release Burndown Chart)

• 跟蹤記錄剩餘的產品列表⼯作規模跟隨Sprint的變化

• Y軸可能會使⽤相對單位值，例如故事點

• 展現了過往的趨勢變化以便調整預測
 

擴張 (Scaling Scrum)

壞訊息：這事⼉有難度。

Scrum將不同職能⼈員聚集於同⼀個團隊（待在同⼀個團隊房間⾥更為 理想），從⽽最⼤化溝通頻寬、可見度和信任，以發現不確定的需求及 技術上的風險。

在需求不確定性和技術風險很⾼的情況下，增派⼈⼿⽆濟於事，只會讓 事情變得更糟。根據專業進⾏分組同樣會讓事情變得更糟。按架構模組 分組（也即，模組團隊），最後也只能讓事情變得更糟。

好訊息：特性團隊或許有幫助。

解決此問題最有效辦法是建立完全跨職能“特性團隊”，他們有能⼒操作 所有架構層從⽽交付以客戶為中⼼的特性。在⼤型系統中這意味著得要 學習新技能。

當團隊專注於學習⽽不是短期的些微效率時，就能建立學習型組織。

更多壞訊息：還是有難度。

⼤型組織獲得敏捷⼒的挑戰尤其⼤。它們多數都陷在了裝樣⼦做Scrum 的泥潭⾥6。在⼤型組織⾥，ScrumMaster們應該定期聚會，通過視覺化 組織級障礙清單推動轉型，閱讀《精益和敏捷開發⼤型應⽤指南7》這樣 的書。

相關實踐 (Related Practices)

精益 (Learn)

Scrum是在軟體開發領域的敏捷運動期間出現的⼀個通⽤管理框架，它 部分地受到了精益⽣產⽅式的影響，⽐如說豐⽥⽣產⽅式8。

極限程式設計 (XP) (Extreme Programming)

ScrumMaster負責提升完成定義的嚴格程度，但Scrum卻並未規定具體 使⽤什麼⼯程實踐。名副其實⽅可謂之完成。⾃動化迴歸測試能夠防⽌ 那些吸⾎型故事逃出它們的巢⽳。設計、架構和基建必須要與時俱進， 在持續地重新考慮和修整的過程中演進，⽽不是在剛開始我們⼀⽆所知 的時候就試圖“最終敲定”。

ScrumMaster可以⿎勵團隊去學習極限程式設計（XP）相關⼯程實踐：持續 整合（持續的⾃動化測試）、測試驅動開發（TDD）、堅持⽆情重構、 結對程式設計、頻繁提交，等等。據稱運⽤這些實踐可以預防技術債務。

團隊⾃組織 (Team Self-Organization)

全⼼投⼊的團隊表現遠勝被操縱的團隊

在Sprint執⾏過程中，團隊成員們對共同⽬標有著內在的興趣，並學著 互相管理去達成⽬標。願為同儕擔責的⼈類天性與⼯作者多年來的習慣 相互⽭盾。接受⼀個團隊靠⾃⾝驅動，⽽不是被外部獎懲所操縱，這跟 經理⼈們多年來的習慣也是衝突的10。ScrumMaster所具備的觀察能⼒ 和說服能⼒可以克服前期的不舒適感，提⾼成功概率。

挑戰與機遇

⾃組織團隊徹底超越了規模更⼤的以傳統⽅式管理的團隊。在滿⾜⼀定 條件的情況下，家庭規模的群體⾃然⽽然地就會變得⾃組織：

• 成員們以清晰的短期⽬標為⼰任

• 成員們能夠衡量群體的進展如何

• 成員們可以觀察得到彼此的貢獻

• 成員們可以放⼼地給出坦率反饋

⼼理學家Bruce Tuckman將群體發展分為了“組建期、激盪期、規範期、 執⾏期”四個階段11。達到⾃組織的最佳狀態需要時間。團隊在最初⼏個 迭代時的表現可能會不如按傳統⽅式管理的⼯作組12。

多樣化團隊應對複雜型⼯作的表現⽐單⼀化團隊更好。他們經歷的衝突 也更多13。對於全⼼投⼊的團隊來說，出現意見分歧很正常也很健康；團 隊的表現就取決於他們是否能妥善處理這些衝突。

壞蘋果理論認為，⼀名消極成員（“拖團隊後腿、散播負⾯情緒或是違反 重要的⼈際交往規範14”）可以不成⽐例地拖累整個群體的表現。這種⼈ 並不多見，但如果團隊未能及時清除他們，就會放任他們擴⼤其影響。 在挑選新成員時給予團隊更⼤影響⼒能夠部分地緩解此問題。 有些⼈在⽼板與⼯⼈情況下⽆法施展拳腳（因為挑戰不⾜或被微管理的 原因），將在Scrum團隊中煥發光彩。 ⾃組織受很多條件的制約，包括地理位置分佈、⽼板與⼯⼈動態關係、 兼職團隊成員以及與Sprint⽬標⽆關的各種⼲擾。讓全職ScrumMaster 去努⼒減輕這類障礙所造成的影響，對於⼤多數團隊來說都很有好處15。

何時適⽤Scrum？(When is Scrum Appropriate?)

Scrum特別適合那種⽤預定義流程⽆法管理的⼯作，需求不確定、技術 實現風險也⽆法預測。在決定採納Scrum還是PMBOK®指南所描述那種 計劃驅動型⽅法的時候，務必要考慮：基本原理是否已經被充分理解、 ⼯作本⾝是否依賴於知識創造與協作。例如，Scrum就不是為可重複型 產品和服務⽽設計的。

同樣要考慮是否有⾜夠的決⼼去培養⼀⽀⾃組織的團隊。

作者簡介 (About the Authors)

Michael James很多年前就已經開始程式設計。他曾經 跟Ken Schwaber⼀起⼯作，併成為了⼀名Scrum 培訓師。他輔導技術⼈員、管理⼈員和⾼管們對 業務進⾏優化以交付價值。