Scrum作為敏捷方法，已經得到了廣泛的應用。針對如何用好、用巧這個看似簡單的框架，《敏捷軟件開發：Scrum實戰指南(第2版)》結合故事、模型和成功秘訣三大要素，透徹講解確保Scrum成功實施的所有基本要素。全書5部分共35章。在簡單介紹Scrum知易行難后，分別介紹戰前準備、戰地基礎、戰地急救，討論如何使每日站會富有成效，如何提出Scrum的第四個問題，如何讓人們在結對編程時保持專注，增加團隊新成員時應該怎么辦，發生文化沖突時應該怎么辦，應急過程等。隨后鎖定八大主題，重點介紹高級生存和荒野生存。*后在附錄中概述Scrum框架，以幫助讀者快速入門。
《敏捷軟件開發：Scrum實戰指南(第2版)》適合打算實現敏捷轉型并導入Scrum的所有人員閱讀，是架構師、開發與測試人員、項目經理和項目負責人的理想參考書。
《敏捷軟件開發：Scrum實戰指南(第2版)》取自作者在大多數公司導入和實施敏捷Scrum過程的實際經歷，通過故事、模型與成功要領三段式框架，借助于詼諧有趣、有畫面感的描述，來幫助讀者觀察、思考和體會主要的挑戰與深層次的問題，進而充分運用Scrum的靈活性來創造更多、更大的價值。
特色主題一覽
起勢，組建團隊
為團隊和組織定義完成
為短期成效做好規劃，移除障礙，確保成功
實施確保敏捷成功的關鍵性技術實踐
在制定版本規劃時合理兼顧可預測性和可適應性
確保每日站會富有成效
及時回顧和補救
準確估算項目成本和衡量未來可交付的價值
動態Scrum項目的風險管理
Backlog的優先級確定和估算
解決Scrum團隊的文化沖突
分布式團隊與離岸團隊
形成持續改進的習慣，提升組織敏捷力
《敏捷軟件開發：Scrum實戰指南(第2版)》實例豐富，所有故事都來自作者的親身經歷，對打算導入敏捷的所有人員和組織具有重要的價值，開發人員、架構師、測試人員、經理以及項目負責人等，都可以從這些故事中得到共鳴和啟發。
前言
歡迎閱讀第2版。
當我提出想要修訂本書第1版時，我妻子懷疑這是不是個理智的決定。畢竟，她提醒我，第1版幾乎把要分享的都寫完了。然而，當我回想起我的第一次寫作過程時，我覺得我不僅有更多要說的，而且我還想調整我已經發表的一些內容。簡而言之，我想要重構，添加一些新特性，并發布2.0版本。所以就有了第2版。
閱讀本書的方法跟閱讀第1版一樣：挑選能解決你在公司遇到的問題的一章并閱讀它，然后應用我的建議，看看會發生什么。
敏捷是一個旅程。自2012年第1版出版以來，我學到了很多東西。如果你以前讀過這本書，你會立刻發現我已經在原來的章節中添加了新的想法和概念。很多章節重寫超過80%；其他的則只有10%。你將看到一個新的部分，第V部分荒野必備，包含了更多的實戰技巧，其靈感來自于我與全球組織合作的第一手經驗。這些新章節包括管理風險、面試、一次做對的謬論等等。
本書誕生過程
我女兒 Emma出生時，我感到有些力不從心。相比我們的其他孩子，我們這次在醫生辦公室的時間似乎要更多一些。我一直問我妻子：這正常嗎？一天晚上，我在枕頭邊上發現我妻子那本《新生兒父母手冊》，里面有她寫的一張小紙條：讀讀這本書，你會感到好受一些。
我讀了。由此我知道了我們所經歷的每件事情對于我的孩子都是正常的，即使對我或我以前觀察到的來說不常見。這使我感到更有信心與安全感。這也正好是我開始試驗 Scrum 與敏捷的時間。隨著我開始遇到障礙與面臨不熟悉的情況，我開始認識到，在做 Scrum與XP的第一年(甚至之后)，我真正需要一本指導手冊。
問題在于，不像一本指導手冊，我不可能準確告訴你，在第 1～3月或者 9～12 月，你的團隊應該做什么或者是應該擔心什么。團隊并不像小孩那樣，不會以一個可以預測的速度發展。相反，在他們第一年的實踐中，隨著他們學習團隊合作、采用敏捷工程實踐、與他們的客戶建立信任、和以增量迭代方式工作的過程中，他們常常會摔倒、蹣跚、犯錯誤，前進兩步就倒退一步。
有鑒于此，我更傾向于以這種方式我遇到了一個問題，該怎么辦來組織這本書。我收集了我參與過或者見證過的、在他們第一年敏捷旅途中的那些團隊的故事。隨著我繼續我的敏捷旅途，我注意到各個公司中這些故事、模式通常都很相似。我在一個公司中實現一個想法，稍微調整一下就可以應用在下一個公司中。重復這個過程，我得以收集了這些現實世界的解決方案， 并把它們加入我隨身攜帶的虛擬工具箱。在這本書中，我將與你分享一些最常見的痛苦與解決方法。當你的團隊遇到麻煩或者是受傷的時候，你可以找到最接近你的癥狀的那一章，然后你可以發現，即使不能解決你的問題，至少也有一個辦法可以減輕你的痛苦。
第2版旨在幫助你精心調試你自己的實踐，在一些你不熟悉的領域提供指南以及在前進的道路上更輕松地克服我們都遇到過的困難。
誰應該讀這本書
如果你正在考慮開始 Scrum 或者敏捷的實踐，或者剛剛開始你的旅途，或者已經實踐了一年左右但卻感覺好像迷失了方向，這本書就是為你準備的。我正式的目標群體就是，從那些在6個月以內將開始他們的項目，到那些已經實踐了一年的公司，即有 18 個月的時間窗口。
這本書是為推崇實踐的人準備的。如果你想學習理論或者是高深的討論，可以從很多優秀的 Scrum 和敏捷的書籍中找到一本。另外一方面，如果你想尋求基于我在微軟做過的項目以及我在福布斯 100強的大型公司指導顧問過的團隊的實踐建議與真實數據，這本書會物有所值。
怎樣閱讀這本書
設計這本書是為了方便你在任何時間以任何順序閱讀任何章節。每一章都以一個故事開始， 這些故事都是從我工作過的或者是指導過的團隊、公司、項目中提取出來的�？梢韵胂螅瑸榱吮Ｗo那些清白的(或者是犯錯的)人，我改變了他們的名字。在你看過這些似曾相識的故事后，我會介紹一個模型。這些模型是我在實戰中用來幫助解決故事中存在的問題的。一些模型你可能會感到不太舒服，或者是認為對你的公司可能不適用。我強烈要求你反抗你的忽視建議或者是修改模型的直覺，至少努力嘗試三次，然后看看結果如何，你可能會對結果感到驚訝。在每章的最后，我總結了成功要領，其中的因素事關實踐成敗。
這本書組織為五部分。
第Ⅰ部分戰前準備，對你準備開始使用 Scrum 提供建議，幫助你為成功做好準備。如果你正在考慮 Scrum，或者是剛剛開始使用Scrum，就從這里開始。
第Ⅱ部分戰地基礎，討論的話題可以幫助你克服開始敏捷的旅途之后團隊與組織會遭遇的初步障礙。如果已經開始了 Scrum 的實踐，但是遇到了困難，你可以從這里開始。
第Ⅲ部分戰地急救，著眼于解決公司所面臨的一些更大、更深層次的問題， 比如往項目中增加人手或者是解決每日站會的功能失調。這些都是在第一年實踐中某個時候很可能會遇到的情況。這幾章可以幫助你診斷并處理這些情況，使團隊恢復到健康的狀態。
第Ⅳ部分高級生存，討論人們在實踐 Scrum的任何階段都常常掙扎的一些話題。 比如， 項目成本、 合同的制定、敏捷與 Scrum 項目中的文檔等。
第V部分荒野必備，包含了一些章節，這些章節關注的是那些被忽視的，但也同樣代價高昂的問題。這些問題是大多數組織在敏捷采納的過程中所面臨的，比如風險管理，面試，一次做對，等等。
如果你是從零開始，對 Scrum 還一無所知，我在本書的附錄中包括了一個對 Scrum 的簡短介紹，旨在幫助你熟悉這些術語與概念。在開始研究這本書之前，你可能還需要多了解一下 Scrum。
為什么需要閱讀這本書
不管你在敏捷旅途中身處何地，我們都需要一個友好的提醒，即我們的遭遇是正常的， 我們還需要解決這些問題的建議和一些成功要領。這本書把這些東西都組織在一起，方便你根據具體需要選擇閱讀需要的章節或者整個部分或者全書。這是真實生活中的情況，可以與你產生共鳴，它的解決方法可以應用于任何團隊。打開書開始閱讀這些故事，這本書將是你經歷 Scrum 與極限編程之高潮與低谷的忠實伴侶。
本書的補充材料
在你閱讀本書的過程中，你可能會想：我真希望有個工具或者是可以下載一個模板來幫助我實踐這個概念。很在多情況下，這是可以的。訪問 http://www.mitchlacey.com/supplements/，你可以看到我在我每天的 Scrum 項目中用到的一系列文件、圖片、Excel 表格以及工具。盡管其中一些信息是精心準備過的，但大多數東西還很簡陋。為什么？在我的項目中，我不需要它們很完美，我只需要它能用。你在我的網站上得到的將是第一手的、真實的、偏重實戰且有用的東西。
著譯者簡介
米奇萊西（Mitch Lacey）
Scrum聯盟和敏捷聯盟的委員會成員，敏捷大會兩屆主席，CST（認證Scrum培訓師）、PMI項目管理專家（PMP）和認證敏捷教練（ACP）。華盛頓大學敏捷認證課程講師。
米奇擁有二十年項目管理經驗，幫助過很多組織順利采用敏捷實踐，包括Scrum和XP。他具有豐富有效的實踐經驗，深受許多公司的信賴，比如Adobe Systems，Aera Energy，Rio-Rad，EchoStar，Microsoft，Oracle，Qualcomm，Salem Hospital，SAP，Sony等等。他經常出席全球大會發表主題演講。在微軟工作期間，他運用敏捷相關知識成功發布了Windows Live的核心企業級服務。他在微軟的第一個敏捷團隊由Ward Cunningham（維基之父、極限編程創始人之一）、Jim Newkirk（nUnit創始人）和David Anderson（看板倡導者）親自指導。
王國良（Glen Wang）
敏捷教練，致力于打造卓越個人和組織。經歷過三個行業：通信，電子制造和金融IT。先后擔任過開發人員、經理，精益和敏捷教練。譯著有《特斯拉：電氣時代的開創者》。敏捷之旅講師，認證Scrum Master課程Co-Trainer。個人微信公眾號：真北敏捷。
熊小龍
高級項目經理，10年以上軟件開發及管理經驗，7年敏捷軟件開發管理經驗。現任職于晨星資訊(深圳)有限公司，從事金融產品開發和項目管理工作。 長期奮斗于一線，注重管理實踐與工程實踐的結合，一直在探索跨職能、跨地域、跨時區的Scrum團隊最佳實踐。
葉虎
項目經理，PMP，經歷了公司從瀑布式到敏捷轉型。畢業于暨南大學，從測試到項目管理，專注于卓越產品和團隊。
鄭璐璐
精益和敏捷教練，卓越運營專家。致力于流程改進、質量提升、產品開發以及企業變革等主題，同時也將敏捷應用于個人成長領域并提煉出個人迭代精進模式。現就職于金融服務行業，專注于建造卓越運營體系，系統提升產品及服務質量，打磨以人為本，持續改善，迭代創新和共創共贏的卓越組織。
目錄
第1章 Scrum知易行難 1
故事 1
Scrum 6
什么是Scrum？ 7
實施Scrum 8
Scrum的基本價值觀 8
Scrum 需要轉變思維方式 9
Scrum采用的是最短路徑，而不是預設路徑 10
Scrum發現問題 12
Scrum的最佳搭檔 12
什么時候適合用Scrum？ 13
變化是困難的 15
現狀后期 16
從外部元素和混亂到思想轉變 16
實踐與集成 16
新的現狀 17
成功要領 17
引用 18
第Ⅰ部分 戰前準備
第2章 取得支持與組建團隊 23
故事 23
模型 29
轉變需要時間 30
建立緊迫感 30
成立一個強大的指導聯盟 31
建立愿景/繪制未來的藍圖 31
溝通愿景 31
授權人們為愿景采取行動 32
計劃并創造短期成功 33
進一步改善，鞏固成效，繼續深化改革 33
制度化新的方式方法 33
成功要領 33
引用 34
參考 34
第3章 用團隊顧問來優化團隊表現 35
故事 35
模型 40
建立一個團隊顧問池 40
建立團隊 42
核心團隊 43
團隊顧問 44
團隊大小 44
核心團隊與團隊顧問一起工作 46
團隊顧問與會議 46
成功要領 47
責任 47
試驗 48
小心過度 48
計劃可能的空閑時間 48
團隊顧問不能代替專職團隊 49
引用 49
參考 49
第4章 預估團隊的速率 50
故事 50
模型 55
使用歷史數據的問題 55
為拍腦袋增加一些依據 56
估算Product Backlog 57
分解參考故事 57
點數與小時數的大致關系 58
團隊的生產能力 58
估算團隊的速率 59
增強對這種技術的信心 60
走著瞧(使用靠譜的數據) 60
收集并以圖表形式表示真實的數據 61
計算平均速率，但要對范圍進行交流 61
截斷數據 62
成功要領 64
引用 65
第5章 Scrum的三大角色 66
故事 66
模型 70
選擇角色 71
組合角色 72
如果實在萬不得已，又該何時組合這三大角色 74
成功要領 74
第6章 確定Sprint的長度 76
故事 76
模型 79
項目期限 80
產品負責人與項目干系人 81
Scrum 團隊 82
確定 Sprint 的長度 82
警告 85
問卷之外 85
成功要領 86
長于1個月的Sprint 87
延長Sprint長度 87
引用 87
第7章 如何定義完成 88
故事 88
模型 90
介紹 91
頭腦風暴 91
分類 92
排序與整合 93
生成與發布DoD 95
沒有完成的工作呢？ 95
成功要領 96
引用 96
第8章 全職的ScrumMaster 97
故事 97
模型 100
成功要領 106
消除障礙/解決問題 106
結束爭論/當團隊的保姆 107
報告團隊的行為表現 107
引導并在必要時提供幫助 107
教育組織并驅動組織變革 108
結語 109
引用 109
參考 110
第II部分 戰地基礎
第9章 Scrum中工程實踐的重要性 113
故事 113
實踐 117
重構 119
持續集成以及更頻繁的提交 120
結對編程 121
自動化集成與驗收測試 123
成功要領 124
不是銀彈 125
開始行動 125
獲得團隊的支持 125
DoD 125
把工程實踐加入Product Backlog 126
獲得培訓與指導 126
結語 126
引用 127
參考 127
第10章 團隊核心時間 128
故事 128
模型 131
在一起工作的團隊 131
分布式團隊與兼職的團隊 133
成功要領 134
第11章 發布計劃 136
故事 136
模型 140
項目成本 144
成功要領 146
事先進行溝通和交流，并且要頻繁 147
每個Sprint后都更新發布計劃 147
努力先做優先級最高的條目 147
交付可工作的軟件 148
引用 148
第12章 分解故事與任務 149
故事 149
模型 152
做好準備 152
故事分解 153
任務分解 156
成功要領 159
引用 160
參考 160
第13章 缺陷管理 161
故事 161
模型 163
成功要領 164
附加信息 165
引用 165
參考 166
第14章 可持續工程與Scrum 167
故事 167
模型 170
專用時間模型 170
隨時收集數據 171
專職團隊模型 171
成功要領 173
專職維護團隊成員的輪換 173
用良好的工程實踐來改進遺留代碼 174
結語 174
引用 174
第15章 Sprint評審會 175
故事 175
模型 179
進行會議 180
成功要領 181
花時間準備 181
記錄決策 182
要求認可 182
勇敢 182
參考 183
第16章 Sprint回顧會 184
故事 184
實踐 187
讓回顧會議發揮應有的作用 187
計劃一個有效的回顧會議 188
召開回顧會議 189
成功要領 191
告訴他們為什么要保留回顧會議 192
營造一個良好的環境 192
有需要就開 192
高度重視回顧會議 193
引用 193
第III部分 戰地急救
第17章 富有成效的每日站會 197
故事 197
模型 200
準時開始和結束 201
開會遲到 201
議程、節奏和站位 202
打斷 202
漫談和深入討論 202
暴露隱藏的障礙 204
忽略問題 204
過于模糊 204
結束就意味著開始 204
成功要領 205
保持會議的頻率 205
站著，不要坐 206
像團隊一樣工作 206
耐心 207
第18章 每日站會的第四個問題 208
故事 208
模型 211
成功要領 212
引用 212
第19章 真正參與結對編程 213
故事 213
模型 215
混排結對編程 216
實踐混排結對編程 216
混排結對編程的挑戰 217
微結對 218
成功要領 220
引用 221
第20章 222
新加入團隊成員 222
故事 222
模型 224
練習 226
成功要領 227
承認速率會下降 227
明智地選擇新成員 227
風險 228
引用 228
第21章 處理文化沖突 229
故事 229
模型 234
成功要領 239
掌握自己的命運 239
面對現實 240
堅持到底 241
引用 242
參考 242
第22章 Sprint緊急情況處理流程 243
故事 243
模型 246
消除障礙 246
獲得幫助 247
縮小范圍 247
取消Sprint 248
成功要領 249
引用 249
第IV部分 高級生存
第23章 可持續的步伐 253
故事 253
模型 257
縮短迭代周期 260
監測燃盡圖 260
增加團隊時間 261
成功要領 262
引用 263
第24章 交付可工作的軟件 264
故事 264
模型 268
核心模型 268
用戶數 269
從風險最高的組件開始 270
擴展和驗證 270
成功要領 271
思維的改變 272
返工 272
專注于端對端的場景 273
參考 274
第25章 價值的度量與優化 275
故事 275
模型 278
功能工作 278
額外的工作 278
試驗性工作 279
技術債務 280
其他潛在的類型 280
組織數據 281
使用數據 281
成功要領 283
教育項目干系人 283
和項目干系人一起工作 284
確定模式與趨勢 284
引用 284
參考 284
第26章 項目成本預算 285
故事 285
模型 290
功能規格書 290
用戶模型 291
估算用戶模型 291
確定用戶故事的優先級 292
確定團隊的速率 293
計算成本 293
制定發布計劃 294
成功要領 294
引用 295
第27章 Scrum項目中的文檔 296
故事 296
模型 299
為什么我們要做文檔 300
我們會做什么文檔 300
什么時候以及怎樣做文檔 301
在項目開始的時候做大量文檔 301
在項目最后做大量文檔 302
隨著項目的進展寫文檔 303
敏捷項目的文檔 304
文檔準備不充分就開始項目 305
成功要領 305
引用 306
第28章 外包與離岸開發 307
故事 307
模型 310
考慮實際成本 310
交接成本 310
增加的開銷 311
長期的人員流失 311
文化的挑戰與管理工作 311
開發實踐 312
面對現實 312
預算與成本 313
時間、距離與文化 314
成功要領 314
選擇合適的離岸團隊 314
以痛苦最小的方式分配工作 315
堅守Scrum框架 315
建立團隊文化 316
準備差旅 317
配備一個項目/團隊協調人 318
絕不考慮離岸的情況 318
引用 318
參考 319
第29章 大型產品列表的優先級確定與估算 320
故事 320
模型 323
團隊 324
項目干系人 325
成功要領 328
預先計劃至關重要 328
專注于討論并設定時間限制 328
將未解決的爭議放入停車場 329
帶上額外的卡片/紙張以備現場產生用戶模型 329
引用 330
第30章 擬定合同 331
故事 331
模型 335
傳統的合同與變更要求 335
寫用戶模型 341
估算用戶模型 341
成功要領 343
引用 345
第V部分 荒野必備
第31章 合作推動完成 349
故事 349
模型 353
任務撲克 353
結對編程 354
限制進行中的工作條目 355
兩周迭代 358
用任務板創造可見性 359
成功要領 361
每個聲音都有人聽 361
對工作的共同理解 361
每位團隊成員都對成果投入 362
不要平均任務估算 362
避免粒度更細的任務估算 362
Scrum建立在團隊工作的基礎之上 362
參考 363
第32章 故事點與時間的關系 364
故事 364
模型 367
恐懼因素 368
寬范圍 368
成功要領 371
收集正確的數據 371
用數據來改善 372
故事點的REFLECT原則 373
參考 374
第33章 沉浸式面試與招聘 375
故事 375
模型 378
預測 378
雇傭要有正確原因 378
不良招聘的成本 379
技能，能力，還是兩者兼顧 380
如何招聘 380
候選人篩選 381
準備與計劃 382
候選人打分 383
招聘管理和非技術人員 384
成功要領 384
建立一個可重復的招聘流程 385
專注于能力而不是問題 385
技能容易學，能力不易學 385
找到比你強的人 386
理解成本并加大投資 386
引用 386
參考 387
第34章 激勵與成果掛鉤 388
故事 388
模型 391
設置關注點 391
按客戶滿意度統一目標 391
優先級的排定和調整 392
其他好處 394
成功要領 394
銷售與開發一體化 394
停止犧牲人員和質量：對項目組合進行排序 394
管理層的支持 395
參考 395
第35章 Scrum項目中的風險管理 396
故事 396
模型 397
客戶風險：PO 399
社會化風險：ScrumMaster 399
技術風險：開發(核心)團隊 400
成功要領 400
放手 400
敏捷起來 401
參考 401
附錄 Scrum框架
角色 404
ScrumMaster 404
產品負責人 404
開發團隊 404
工件 405
Sprint Backlog 406
燃盡圖 407
會議 407
計劃會 407
每日Scrum 408
Sprint評審會 409
Sprint回顧會 409
結語 410
新書資訊