了得網計算機/網絡_敏捷軟件開發：Scrum實戰指南（第2版）

產品特色

編輯推薦

《敏捷軟件開發：Scrum實戰指南(第2版)》取自作者在大多數公司導入和實施敏捷Scrum過程的實際經歷，通過“故事、模型與成功要領”三段式框架，借助於詼諧有趣、有畫面感的描述，來幫助讀者觀察、思考和體會主要的挑戰與深層次的問題，進而充分運用Scrum的靈活性來創造更多、更大的價值。
特色主題一覽
• 起勢，組建團隊
• 為團隊和組織定義“完成”
• 為短期成效做好規劃，移除障礙，確保成功
• 實施確保敏捷成功的關鍵性技術實踐
• 在制定版本規劃時合理兼顧可預測性和可適應性
• 確保每日站會富有成效
• 及時回顧和補救
• 準確估算項目成本和衡量未來可交付的價值
• 動態Scrum項目的風險管理
• Backlog的優先級確定和估算
• 解決Scrum團隊的文化衝突
• 分布式團隊與離岸團隊
• 形成持續改進的習慣，提升組織敏捷力
《敏捷軟件開發：Scrum實戰指南(第2版)》實例豐富，所有故事都來自作者的親身經歷，對打算導入敏捷的所有人員和組織具有重要的價值，開發人員、架構師、測試人員、經理以及項目負責人等，都可以從這些故事中得到共鳴和啟發。

內容簡介

Scrum作為敏捷方法，已經得到了廣泛的應用。針對如何用好、用巧這個看似簡單的框架，《敏捷軟件開發：Scrum實戰指南(第2版)》結合故事、模型和成功秘訣三大要素，透徹講解確保Scrum成功實施的所有基本要素。全書5部分共35章。在簡單介紹Scrum知易行難後，分別介紹戰前準備、戰地基礎、戰地急救，討論如何使每日站會富有成效，如何提出Scrum的第四個問題，如何讓人們在結對編程時保持專注，增加團隊新成員時應該怎麼辦，發生文化衝突時應該怎麼辦，應急過程等。隨後鎖定八大主題，重點介紹高級生存和荒野生存。*後在附錄中概述Scrum框架，以幫助讀者快速入門。

《敏捷軟件開發：Scrum實戰指南(第2版)》適合打算實現敏捷轉型並導入Scrum的所有人員閱讀，是架構師、開發與測試人員、項目經理和項目負責人的理想參考書。

作者簡介

著譯者簡介
米奇•萊西（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）著譯者簡介
米奇•萊西（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目錄
第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

前言

前言

歡迎閱讀第2版。
當我提出想要修訂本書第1版時，我妻子懷疑這是不是個理智的決定。畢竟，她提醒我，第1版幾乎把要分享的都寫完了。然而，當我回想起我的次寫作過程時，我覺得我不僅有更多要說的，而且我還想調整我已經發表的一些內容。簡而言之，我想要重構，添加一些新特性，並發布2.0版本。所以就有了第2版。
閱讀本書的方法跟閱讀第1版一樣：挑選能解決你在公司遇到的問題的一章並閱讀它，然後應用我的建議，看看會發生什麼。
敏捷是一個旅程。自2012年第1版出版以來，我學到了很多東西。如果你以前讀過這本書，你會立刻發現我已經在原來的章節中添加了新的想法和概念。很多章節重寫超過80%；其他的則隻有10%。你將看到一個新的部分，第V部分“荒野”，包含了更多的實戰技巧，其靈感來自於我與全球組織合作的手經驗。這些新章節包括管理風險、面試、一次做對的謬論等等。前言

歡迎閱讀第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強的大型公司指導顧問過的團隊的實踐建議與真實數據，這本書會物有所值。
怎樣閱讀這本書
設計這本書是為了方便你在任何時間以任何順序閱讀任何章節。每一章都以一個故事開始，這些故事都是從我工作過的或者是指導過的團隊、公司、項目中提取出來的。可以想像，為了保護那些清白的(或者是犯錯的)人，我改變了他們的名字。在你看過這些似曾相識的故事後，我會介紹一個模型。這些模型是我在實戰中用來幫助解決故事中存在的問題的。一些模型你可能會感到不太舒服，或者是認為對你的公司可能不適用。我強烈要求你反抗你的忽視建議或者是修改模型的直覺，至少努力嘗試三次，然後看看結果如何，你可能會對結果感到驚訝。在每章的後，我總結了成功要領，其中的因素事關實踐成敗。
這本書組織為五部分。
第Ⅰ部分“戰前準備”，對你準備開始使用 Scrum 提供建議，幫助你為成功做好準備。如果你正在考慮 Scrum，或者是剛剛開始使用Scrum，就從這裡開始。
第Ⅱ部分“戰地基礎”，討論的話題可以幫助你克服開始敏捷的旅途之後團隊與組織會遭遇的初步障礙。如果已經開始了 Scrum 的實踐，但是遇到了困難，你可以從這裡開始。
第Ⅲ部分“戰地急救”，著眼於解決公司所面臨的一些更大、更深層次的問題，比如往項目中增加人手或者是解決每日站會的功能失調。這些都是在年實踐中某個時候很可能會遇到的情況。這幾章可以幫助你診斷並處理這些情況，使團隊恢復到健康的狀態。
第Ⅳ部分“高級生存”，討論人們在實踐 Scrum的任何階段都常常掙扎的一些話題。比如，項目成本、合同的制定、敏捷與 Scrum 項目中的文檔等。
第V部分“荒野”，包含了一些章節，這些章節關注的是那些被忽視的，但也同樣代價高昂的問題。這些問題是大多數組織在敏捷采納的過程中所面臨的，比如風險管理，面試，一次做對，等等。
如果你是從零開始，對 Scrum 還一無所知，我在本書的附錄中包括了一個對 Scrum 的簡短介紹，旨在幫助你熟悉這些術語與概念。在開始研究這本書之前，你可能還需要多了解一下 Scrum。
為什麼需要閱讀這本書
不管你在敏捷旅途中身處何地，我們都需要一個友好的提醒，即我們的遭遇是正常的，我們還需要解決這些問題的建議和一些成功要領。這本書把這些東西都組織在一起，方便你根據具體需要選擇閱讀需要的章節或者整個部分或者全書。這是真實生活中的情況，可以與你產生共鳴，它的解決方法可以應用於任何團隊。打開書開始閱讀這些故事，這本書將是你經歷 Scrum 與極限編程之高潮與低谷的忠實伴侶。
本書的補充材料
在你閱讀本書的過程中，你可能會想：“我真希望有個工具或者是可以下載一個模板來幫助我實踐這個概念。”很在多情況下，這是可以的。訪問 http://www.mitchlacey.com/supplements/，你可以看到我在我每天的 Scrum 項目中用到的一繫列文件、圖片、Excel 表格以及工具。盡管其中一些信息是精心準備過的，但大多數東西還很簡陋。為什麼？在我的項目中，我不需要它們很完美，我隻需要它能用。你在我的網站上得到的將是手的、真實的、偏重實戰且有用的東西。

在線試讀

第1章 Scrum知易行難
Scrum簡潔優雅，表面上看，是一個容易理解的框架，但同時也是難實施得好的框架。我說“實施得好”是因為Scrum固有的簡單性容易誘導我們，讓人覺得使用Scrum很容易。然而，在現實中可能需要很多年纔能把它做好。Scrum似乎完全對立於我們過去多年來在瀑布式開發中所習得的方式。顯而易見，我們需要一些時間來忘記*慣，及時調整到新的現實中。
在本書的附錄中，我解釋了Scrum的機制。如果你對Scrum以及如何使用它還不熟悉，我建議你從那裡開始。如果了解Scrum的一些背景，你就知道它的機制非常簡單直觀。事實上，正因為它如此簡單直觀，纔導致很多人誤以為自己已經掌握了Scrum，可以立即根據現狀著手修改Scrum。結果呢，他們卻往往發現自己迷失方向或者受了傷而需要幫助，本書就是為此而設計的。下面這個故事闡述了一點：如果不理解或者缺乏這些使Scrum有效的核心敏捷概念中的堅實基礎，應用Scrum很快就會陷入困境。
故事
出場人物：敏捷教練Jeff (傑夫) 項目集經理Suzy(蘇西) ScrumMaster教練Julie(朱莉) 首席測試Mike(邁克) 團隊Wyatt(懷亞特)
Jeff是個敏捷教練，他在一家大型軟件公司內部幫助團隊應用Scrum。有一天，他收到部門項目集經理Suzy的一封電子郵件。
“Jeff，請幫個忙。我們已經做了6個月的Scrum，但代碼質量並沒有像預期的那樣有所提高。我想我們需要你過來和我們討論討論結對編程。下周一就是我們計劃周的開始，你能來一下嗎？”
Jeff坐在椅子上想，討論結對編程相對簡單，他可以帶上朋友Julie，一個優秀的開發人員和經驗豐富的敏捷實踐者，所以不會有什麼問題。但電子郵件中有幾個字一直浮現在他的腦海中，計劃周？Scrum要求Sprint計劃會議的兩個部分都不得超過4個小時。這個團隊居然要做1周？他隱隱覺得，不隻是結對編程，還有其他更多的事情需要他做。下周一會比較有意思。
星期一，Jeff和Julie來到會議室，發現Suzy和她的8人團隊已經在會議室各就各位了。在Suzy介紹完團隊之後，Jeff和Julie簡單談了談各自的經歷，然後開始問Suzy代碼質量問題。
團隊很快七嘴八舌，開始回答。首席測試Mike首先說道：“我們的代碼質量差是因為我們沒有時間做測試。開發人員在4周Sprint的後一天還在忙著寫代碼。本來嘛，‘編碼與測試Sprint’應該既做編碼，又做測試。但我們的測試不是被擠到Sprint末尾，就是溢出被放到‘集成Sprint’。”第1章 Scrum知易行難
Scrum簡潔優雅，表面上看，是一個容易理解的框架，但同時也是難實施得好的框架。我說“實施得好”是因為Scrum固有的簡單性容易誘導我們，讓人覺得使用Scrum很容易。然而，在現實中可能需要很多年纔能把它做好。Scrum似乎完全對立於我們過去多年來在瀑布式開發中所習得的方式。顯而易見，我們需要一些時間來忘記*慣，及時調整到新的現實中。
在本書的附錄中，我解釋了Scrum的機制。如果你對Scrum以及如何使用它還不熟悉，我建議你從那裡開始。如果了解Scrum的一些背景，你就知道它的機制非常簡單直觀。事實上，正因為它如此簡單直觀，纔導致很多人誤以為自己已經掌握了Scrum，可以立即根據現狀著手修改Scrum。結果呢，他們卻往往發現自己迷失方向或者受了傷而需要幫助，本書就是為此而設計的。下面這個故事闡述了一點：如果不理解或者缺乏這些使Scrum有效的核心敏捷概念中的堅實基礎，應用Scrum很快就會陷入困境。
故事
出場人物：敏捷教練Jeff (傑夫) 項目集經理Suzy(蘇西) ScrumMaster教練Julie(朱莉) 首席測試Mike(邁克) 團隊Wyatt(懷亞特)
Jeff是個敏捷教練，他在一家大型軟件公司內部幫助團隊應用Scrum。有一天，他收到部門項目集經理Suzy的一封電子郵件。
“Jeff，請幫個忙。我們已經做了6個月的Scrum，但代碼質量並沒有像預期的那樣有所提高。我想我們需要你過來和我們討論討論結對編程。下周一就是我們計劃周的開始，你能來一下嗎？”
Jeff坐在椅子上想，討論結對編程相對簡單，他可以帶上朋友Julie，一個優秀的開發人員和經驗豐富的敏捷實踐者，所以不會有什麼問題。但電子郵件中有幾個字一直浮現在他的腦海中，計劃周？Scrum要求Sprint計劃會議的兩個部分都不得超過4個小時。這個團隊居然要做1周？他隱隱覺得，不隻是結對編程，還有其他更多的事情需要他做。下周一會比較有意思。
星期一，Jeff和Julie來到會議室，發現Suzy和她的8人團隊已經在會議室各就各位了。在Suzy介紹完團隊之後，Jeff和Julie簡單談了談各自的經歷，然後開始問Suzy代碼質量問題。
團隊很快七嘴八舌，開始回答。首席測試Mike首先說道：“我們的代碼質量差是因為我們沒有時間做測試。開發人員在4周Sprint的後一天還在忙著寫代碼。本來嘛，‘編碼與測試Sprint’應該既做編碼，又做測試。但我們的測試不是被擠到Sprint末尾，就是溢出被放到‘集成Sprint’。”
Julie打斷他：“抱歉，Mike，你剛纔是說‘集成Sprint’？”她看著Suzy，Suzy點點頭。
“哦，我還沒有解釋我們改了Scrum，是吧？”Suzy說，“我們知道Scrum要求每4周有一個發布，但對我們做的這種工作，是完全不可能的。我的意思是，在我們嘗試Scrum之前，我們都在努力按季度發布，那完全是一場災難！所以我們隻能修改Scrum使其更好地貼近我們的流程和現實。”Suzy走到白板前開始在上面寫。
“首先，我們有1周來做Sprint計劃；然後在4周的實際Sprint中，開發人員寫代碼，測試人員寫測試用例；在這之後，我們就做集成，然後部署。當然，我也常常增加1周作為緩衝應急，以防萬一。”Suzy說。
話音剛落，她就已經在白板上寫好了下圖所示的內容。

書摘插畫

商品搜索

商品分类

【醫學】

【各大出版社】