敏捷軟件開發 : Scrum 實戰指南, 2/e 敏捷软件开发:Scrum实战指南(第2版)

米奇•萊西（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（看板倡導者）親自指導。

第1章Scrum知易行難1 
故事1 
Scrum 6 
什麼是Scrum？7 
實施Scrum 8 
Scrum的基本價值觀8 
Scrum需要轉變思維方式9 
Scrum採用的是最短路徑，而不是預設路徑10 
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