Scrum敏捷軟件開發

[美]Mike Cohn

下單後立即進貨 (約4週~6週)

  • Scrum敏捷軟件開發-preview-1
Scrum敏捷軟件開發-preview-1

相關主題

商品描述

《Scrum敏捷軟件開發》是敏捷聯盟及Scrum聯盟創始人之一、敏捷估算及計劃的鼻祖Mike Cohn三大經典著作中影響最為深厚的扛鼎之作,也是全球敏捷社區中獲得廣泛肯定的企業敏捷轉型權威參考。作者花四年時間,把自己近十五年的敏捷實踐經驗,特別是近四年中針對各種敏捷轉型企業的咨詢和指導工作,並結合旁徵博引的方式,從更高的思想層次對敏捷與Scrum多年來的經驗和教訓進行深入而前面的梳理和總結,最終集大成者便是這本令人醍醐灌頂的佳作。 《Scrum敏捷軟件開發》是軟件企業及其管理團隊成功進行敏捷轉型戰略及實施的必備參考書,適合經理、開發人員、教練、ScrumMaster、產品負責人、分析師、團隊領導或項目領導,是幫助他們成功完成項目,甚至造就敏捷企業的重要參考。

作者簡介

Mike Cohn,Mountain Goat Software創辦人,以幫助客戶公司成長為卓越軟件開發組織為己任,專門提供Scrum與敏捷軟件開發培訓。
Mike Cohn是敏捷運動兩大公認名著(《用戶故事與敏捷方法》和《敏捷估算與規劃》)的作者。
他曾經歷任多個軟件開發公司(從新創公司到《財富》40強)的技術總監,曾服務子BBC(英國國際廣播公司)、Capital One(美國第—投資集團),Electronic Arts(藝電)、Experian(益百利)、Gooqle(谷歌)、Intuit(直覺軟件公司)、Lexis Nexis(律商聯訊)、Lockheed Martin(洛克希德·馬丁)、微軟、諾基亞、飛利浦、Sabre、Salesforce.com、西門子、索尼、時代華納、雅虎等客戶。他參與創力了敏捷聯盟、敏捷項目領導網絡和Scrum聯盟。

目錄大綱

  

目    錄

第I部分  啟    航

 

第1章  為什麽敏捷轉型難(但值得) 3

為什麽轉型困難 5

成功的變革不是完全的自上而下

或者自下而上 5

結束狀態是不可預知的 6

Scrum是無處不在的 8

Scrum是截然不同的 9

變化來得比以往更快 10

最佳實踐是危險的 10

為什麽值得投入 11

更高的生產力及更低的成本 13

員工的參與度和工作滿意度增強 15

更快的產品上市時間 16

更高的質量 17

項目乾系人的滿意度提升 18

現在的做法已經不再有效 19

承前啟後 20

延伸閱讀 20

第2章  ADAPT模型 23

意識 25

意識開發工具 27

渴望 29

渴望提升工具 30

能力 33

能力開發工具 34

推廣 37

Scrum推廣工具 38

傳遞 40

"企業重力"的來源 41

承前啟後 44

延伸閱讀 45

第3章  Scrum實施模式 47

小團隊試點,還是全面轉型 47

選擇小團隊試點的原因 48

選擇全面轉型的原因 49

在全面轉型和小團隊試點之間

選擇 50

公開敏捷,還是悄悄行動 51

選擇公開展示敏捷的原因 52

選擇悄悄行動的原因 53

從公開展示和悄悄行動中做出

選擇 54

Scrum的推廣模式 55

先拆分後播種 55

先成長後拆分 56

內部教練 57

優先選擇先拆分後播種模式的原因 57

選擇先成長後拆分模式的原因 58

選擇內部教練模式的原因 58

選擇你自己的方式 59

引入新的技術實踐 60

馬上開始的原因 61

推遲嘗新的原因 62

最後一點考慮 62

延伸閱讀 64

第4章  漸進敏捷 67

改進Backlog 68

企業轉型社區 70

ETC的 Sprint 72

發起人和產品負責人 73

ETC的職責 74

改進社區 77

改進的催化劑 78

有效性的兩個度量指標 79

改進社區Sprint 80

關註實際相關的目標 82

改進社區的成員 82

解散社區 84

一種尺寸不能適合所有的 85

承前啟後 85

延伸閱讀 85

第5章  試點項目 87

選擇試點項目 87

理想試點項目的四個屬性 88

選擇合適的時機啟動項目 90

瀕臨失敗的項目 91

選擇試點項目團隊 92

試點項目不成功會怎樣 94

設定和管理期望 95

關於進度的期望 95

關於可預測性的期望 97

關於對Scrum態度的期望 98

關於參與程度的期望 98

不過是個試點項目 99

延伸閱讀 100

 

  

第II部分  個    體

 

第6章  剋服抵觸 103

預見抵觸 103

哪些人會抵觸 104

瀑布深信症和敏捷恐懼症 106

關於變革的溝通 107

從領導那裡聽到 107

從同伴那裡聽到 108

個體抵觸的方式和原因 109

懷疑論者 112

破壞者 115

頑固分子 116

追隨者 119

把抵觸視為一個有用的危險信號 121

延伸閱讀 122

第7章  新角色 123

ScrumMaster的角色 123

優秀ScrumMaster的品質 124

技術帶頭人擔任ScrumMaster 127

內部或外部的ScrumMaster 128

輪流擔任ScrumMaster 129

剋服共同的問題 130

產品負責人 132

產品負責人的職責 132

每個團隊只需要一個產品負責人 135

優秀產品負責人的品質 138

ScrumMaster擔任產品負責人 139

剋服普遍問題 140

新角色,老責任 143

延伸閱讀 143

第8章  角色轉換 145

分析員 145

項目經理 148

為什麽頭銜要發生變化 150

架構師 151

不編碼的架構師 152

職能經理 153

職能經理的領導角色 153

人員管理職責 155

程序員 155

數據庫管理員 157

測試員 157

用戶體驗設計師 160

三個常見主題 163

延伸閱讀 163

第9章  技術實踐 165

追求技術進步 165

測試驅動開發 166

重構 169

集體所有權 171

持續集成 172

結對編程 174

設計:有意的而又是涌現式的 176

習慣於不做大型設計 178

引導設計 179

技術實踐的改進並不是可有可無的 182

延伸閱讀 182

 

  

第III部分  團    隊

 

第10章  團隊結構 189

給他們兩個匹薩 189

為什麽兩個匹薩就夠了 191

小團隊的效率 192

支持特性團隊 195

保守地使用組件團隊 197

誰來做這些決定? 201

今天對,明天可能錯 201

自組織不等於隨意組合 202

一人一個項目 205

任務太多的時候,花在單一任務上的

時間會減少 206

何時可以多任務 208

公司的多任務表 209

立刻停止 209

良好的團隊結構指導原則 211

承前啟後 213

延伸閱讀 213

第11章  團隊協作 215

擁抱團隊責任制 215

培養團隊承諾 217

依賴專家但須謹慎 218

所有工作總是逐漸完成 220

不要等到Sprint快結束時才完成

所有任務 221

承諾完成不同粒度的產品Backlog

事項 222

鼓勵團隊學習 223

確保學習環境 223

設計學習型團隊 224

消除知識浪費 228

通過承諾鼓勵合作 230

承前啟後 232

延伸閱讀 233

第12章  領導自組織團隊 235

影響自組織團隊 236

容器、差異與交流 237

選擇外部環境 245

定義績效 245

管理思想 246

引入替換選擇系統 246

給系統註入能量 247

領導力遠不僅限於買匹薩 249

延伸閱讀 249

第13章  產品Backlog 251

從文檔到討論的轉變 252

切勿良莠不分 254

在產品Backlog中使用用戶故事 255

持續地提煉需求 258

涌現的需求 258

產品Backlog冰山 259

為什麽要持續地提煉需求? 261

對用戶故事的持續提煉 262

學會在沒有詳細說明書的情況下開始 266

通過事例說明 267

跨職能的團隊能降低對文檔的

需求 270

創建DEEP的產品Backlog 271

不要忘記討論 271

延伸閱讀 272

第14章  Sprint 273

每個Sprint應遞交可工作的軟件 274

"潛在可交付"的含義 275

識別"潛在可交付"的指導方針 276

每個Sprint提交一些有價值的東西 279

在當前Sprint為下個Sprint做準備 282

臺球短跑 283

只在一個Sprint中塞入能完成的

東西 283

每個Sprint始終保持協作 285

避免特定活動的Sprint 286

用完成-完成的關系取代完成-開始的

關系 288

用戶體驗設計的交迭 289

全盤思考,增量工作 290

系統架構和數據庫設計 292

保持時間箱定期性和嚴格性 294

絕不要延長Sprint 295

不要改變目標 297

放棄改變團隊目標的習慣 299

獲得反饋,學習和適應 301

延伸閱讀 301

第15章  做計劃 303

逐步完善計劃 304

不要用加班來趕計劃 306

歷經挫折後才會明白 307

達到目標 308

如果不加班,怎麽辦 310

如果可能,支持改變範圍 311

考慮其他選擇 312

項目環境是關鍵 315

區別對待估算和承諾 316

用正確的數據來做 317

從估算到承諾 320

歷史估算是承諾的基礎 321

小結 325

延伸閱讀 326

第16章  質量 327

把測試集成到流程中 327

為什麽最後才測試沒有效果 328

什麽是構建質量 330

不同層次的自動化 331

保留用戶界面測試的角色 334

手工測試角色 334

在Sprint內做自動化 335

關於收益的例子 337

驗收性測試驅動開發(ATTD) 338

恰到好處的細節 339

償還技術債務 341

通過三個步驟3降低測試債務 342

質量需要團隊的共同努力 344

延伸閱讀 344

 

  

 

第IV部分  組    織

 

第17章  擴展Scrum 349

擴展產品負責人 350

共享責任,分割職能 351

完成大型產品Backlog的工作 352

一個產品,一個產品Backlog 352

保持產品Backlog大小合理 354

主動管理依賴 356

進行滾動的前瞻性計劃會議 357

舉行發布啟動會議 359

共享團隊成員 360

使用集成團隊 361

在團隊間協調工作 363

Scrum of Scrums會議 364

同步Sprint 367

擴展Sprint計劃會議 368

錯開一天 369

大房間 370

培養實踐社區 371

正式的或非正式的 373

創造有利於社區形成和繁榮的

環境 374

參與 375

Scrum確實能擴展 376

延伸閱讀 377

第18章  分佈式團隊 379

決定如何分佈多個團隊 380

形成凝聚力 383

承認顯著的文化差異 383

承認微小的文化差異 385

加強職能和團隊的亞文化 386

通過強調早期進展來建立信任 389

現場見面會 392

播種訪問 392

聯絡訪問 394

旅行大使 395

改變溝通方式 397

添加一些文檔 397

給產品Backlog添加細節 398

鼓勵橫向溝通 399

會議 400

一般性建議 401

Sprint計劃會議 403

每日站會 406

Scrum of Scrums 410

Sprint評審和回顧 411

謹慎行事 412

延伸閱讀 413

第19章  與其他方法論共存 415

混合Scrum和順序式開發 415

三種交互場景 416

沖突的3個領域 417

Scrum和順序式能永遠共存嗎? 419

監管 420

用非敏捷的監管來運行Scrum

項目 421

兼容 422

ISO 9001 423

能力成熟度模型集成(CMMI) 425

實現兼容 427

下一步 428

延伸閱讀 429

第20章  人力資源、後勤和PMO 431

人力資源 432

管理層次結構 433

定期的績效評估 434

開除團隊成員 436

職業發展 437

只要有人參與,就總是存在與人

相關的問題 438

後勤 439

空間 439

將作戰指揮室變到整個空間 440

傢具 442

在工作空間里應該可見的東西 444

項目管理辦公室 446

人員 447

項目 448

過程 449

重新命名PMO 450

底線 451

延伸閱讀 451

 

  

第V部分  下  一  站

 

第21章  看看進展如何 455

測量的目的 455

一般性的敏捷評估 456

撒丹遵守度調查 457

Agile: EF 459

比較式敏捷評估 460

創建你自己的評估 464

Scrum團隊平衡計分卡 465

構建平衡記分卡 466

推崇簡單度量 468

我們真的在意這些嗎 470

延伸閱讀 471

第22章  沒有終點 473