本書以敏捷軟體開發為中心，系統闡述了敏捷原則和實踐的先進理念和重要意義，並分別講解了Scrum、極限編程、精益和看板四套敏捷實踐的套用。作者從開發團隊的日常困境入手，用講故事的形式展開問題，由表及里，層層講解，並在每一章最後附上參考書，便於讀者進一步查找學習。本書內容生動，語言通俗易懂，集趣味性和實用性於一體，是學習敏捷開發、提升團隊效率的極佳參考書。
內容簡介,作者簡介,目錄,
內容簡介
本書以敏捷軟體開發為中心，系統闡述了敏捷原則和實踐的先進理念和重要意義，並分別講解了Scrum、極限編程、精益和看板四套敏捷實踐的套用。作者從開發團隊的日常困境入手，用講故事的形式展開問題，由表及里，層層講解，並在每一章最後附上參考書，便於讀者進一步查找學習。本書內容生動，語言通俗易懂，集趣味性和實用性於一體，是學習敏捷開發、提升團隊效率的極佳參考書。
作者簡介
Andrew Stellman
是O'Reilly暢銷書作者、敏捷教練、項目領導人、軟體工程項目經理、開發人員和系統架構師。具有20多年的軟體開發項目管理經驗，是公認的軟體開發專家。
Jennifer Greene
是一位優秀的軟體測試人員，曾與不同的軟體開發團隊共事，並且構建了很多相當酷的工程。她還是一位暢銷書作者，曾撰寫過Head First PMP、Head First C#。其中Head First C#為她與Andrew Stellman合著。
目錄
序 xv
前言 xvii
第1章 學習敏捷 1
1.1 什麼是敏捷 2
1.2 本書的讀者對象 5
1.3 本書的目標 6
1.4 努力建立敏捷思維 6
1.5 本書結構 9
第2章 理解敏捷價值觀 11
2.1 團隊主管、架構師和項目經理走進了一間酒吧…… 12
2.2 沒有銀彈 14
2.3 敏捷可以拯救亂局嗎 16
2.3.1 引入敏捷，帶來變化 17
2.3.2 “聊勝於無”的結果 18
2.4 視角割裂 19
2.4.1 視角割裂帶來的問題 21
2.4.2 為什麼視角割裂只能做到“聊勝於無” 22
2.5 敏捷宣言幫助團隊認識實踐的目的 24
2.5.1 個體和互動高於流程和工具 25
2.5.2 可工作的軟體高於詳盡的文檔 25
2.5.3 客戶協作高於契約談判 26
2.5.4 回響變化高於遵循計畫 26
2.5.5 原則高於實踐 27
2.6 理解敏捷的“大象” 28
2.7 著手採用一套新方法 32
第3章 敏捷原則 37
3.1 敏捷軟體開發的12 條原則 38
3.2 客戶總是對的嗎 38
3.3 交付項目 40
3.3.1 原則1：最優先要做的是儘早、持續地交付有價值的軟體，讓客戶滿意 40
3.3.2 原則2：欣然面對需求變化，即使是在開發後期。敏捷過程利用變化為
客戶維持競爭優勢 41
3.3.3 原則3：頻繁交付可工作的軟體，從數周到數月，交付周期越短越好 42
3.3.4 改進電子書閱讀器團隊的項目交付計畫 44
3.4 溝通和合作 46
3.4.1 原則4：在團隊內外，面對面交談是最有效、也是最高效的溝通方式 48
3.4.2 原則5：在整個項目過程中，業務人員和開發人員必須每天都在一起工作 49
3.4.3 原則6：以受激勵的個體為核心構建項目，為他們提供環境和支持，
相信他們可以把工作做好 51
3.4.4 在電子書閱讀器項目中採用更好的溝通方式 52
3.5 項目實施——推進項目 53
3.5.1 原則7：可工作的軟體是衡量進度的首要標準 53
3.5.2 原則8：敏捷過程倡導可持續開發。贊助商、開發人員和用戶要能夠
共同、長期維持其步調，穩定向前 54
3.5.3 原則9：堅持不懈地追求技術卓越和設計優越，以此增強敏捷的能力 55
3.5.4 改善電子書閱讀器團隊的工作環境 55
3.6 項目和團隊的持續改進 56
3.6.1 原則10：簡單是盡最大可能減少不必要工作的藝術，是敏捷的根本 56
3.6.2 原則11：最好的架構、需求和設計來自自組織的團隊 57
3.6.3 原則12：團隊定期反思如何提升效率，並依此調整 57
3.7 敏捷項目：整合所有原則 58
第4章 Scrum和自組織團隊 62
4.1 Scrum的規則 64
4.2 第1幕：Scrum的適用條件 65
4.3 Scrum團隊中每個人都要對項目負責 67
4.3.1 Scrum主管指導團隊的決策 67
4.3.2 產品所有者幫助團隊了解軟體的價值 68
4.3.3 每個人都對項目負責 69
4.3.4 Scrum有一組自己的價值觀 75
4.4 第2幕：狀態更新只是社交網路的玩法 78
4.5 整個團隊參與每日Scrum例會 80
4.5.1 反饋和“可見− 檢查− 調整”周期 80
4.5.2 最後責任時刻 81
4.5.3 召開有效的每日Scrum例會 83
4.6 第3幕：將衝刺計畫寫到牆上 86
4.7 衝刺、計畫和回顧會議 87
4.7.1 疊代式與增量式 87
4.7.2 衝刺成也在於產品所有者，敗也在於產品所有者 89
4.7.3 可見性和價值觀 89
4.7.4 計畫並執行有效的Scrum衝刺 93
4.8 第4幕：盡力之後 94
第5章 Scrum計畫和集體承諾 99
5.1 第5幕：出乎意料 100
5.2 用戶故事、速度和普遍接受的Scrum實踐 102
5.2.1 提升軟體價值 102
5.2.2 以用戶故事構建用戶真正會用到的功能 103
5.2.3 滿意條件 105
5.2.4 故事點和速度 106
5.2.5 燃盡圖 108
5.2.6 通過用戶故事、故事點、任務和任務板來計畫並實施衝刺 111
5.2.7 廣受認可的Scrum實踐 115
5.3 第6幕：第一次勝利 116
5.4 回顧Scrum價值觀 116
5.4.1 具體實踐沒有價值觀也有效果（只是別管它叫Scrum） 117
5.4.2 你的公司文化與Scrum的價值觀兼容嗎 119
第6章 極限編程與擁抱變化 128
6.1 第1幕：開始加班 129
6.2 極限編程的主要實踐 130
6.2.1 編程實踐 130
6.2.2 集成實踐 131
6.2.3 計畫實踐 132
6.2.4 團隊實踐 133
6.2.5 為什麼開發團隊抵制變化，上述實踐如何提供幫助 134
6.3 第2幕：計畫有變，但我們還是看不到希望 137
6.4 極限編程的價值觀幫助團隊改變心態 139
6.4.1 極限編程幫助開發人員學會與用戶協作 141
6.4.2 開發團隊的懷疑會破壞實踐的效用 142
6.5 正確的思維從極限編程的價值觀開始 144
6.5.1 極限編程的價值觀 144
6.5.2 以善意鋪就 144
6.6 第3幕：勢頭的變換 147
6.7 理解極限編程價值觀，擁抱變化 148
6.7.1 極限編程的指導原則 149
6.7.2 極限編程指導原則可以加深對計畫的理解 151
6.7.3 極限編程指導原則與實踐相互促進 152
6.7.4 反饋循環 154
第7章 極限編程、簡化和增量式設計 163
7.1 第4幕：再次加班 164
7.2 代碼和設計 165
7.2.1 代碼異味和反模式（如何判斷你是不是聰明過頭了） 166
7.2.2 極限編程團隊主動尋找和修復代碼異味 168
7.2.3 鉤子、邊界情況以及功能過多的代碼 170
7.2.4 代碼異味會增加複雜性 175
7.3 把編碼和設計決定留到最後責任時刻 175
7.3.1 決然重構，償還技術債務 177
7.3.2 持續集成，排查設計問題 179
7.3.3 避免一體式設計 180
7.4 增量式設計與極限編程的整體實踐 182
7.4.1 有時間進行思考，團隊才能做好工作 184
7.4.2 團隊成員彼此信任並共同作出決定 186
7.4.3 極限編程的設計、計畫、團隊和整體實踐形成了一個帶動創新的系統 186
7.4.4 增量式設計與為了復用而設計 188
7.4.5 簡化單元互動，系統實現增量式成長 190
7.4.6 優秀的設計源自簡單的互動 190
7.5 第5幕：最終得分 192
第8章 精益、消除浪費和著眼全局 200
8.1 精益思維 201
8.1.1 你已經理解了很多精益價值觀 201
8.1.2 承諾、選擇意識和集合式開發 203
8.2 第1幕：還有一件事…… 207
8.3 創造英雄與神奇思維 209
8.4 消除浪費 210
8.5 加深對產品的理解 214
8.5.1 著眼全局 216
8.5.2 找到問題的根本原因 218
8.6 儘快交付 219
8.6.1 使用面積圖可視化工作進度 221
8.6.2 限制進行中的工作，控制瓶頸 225
8.6.3 拉動式系統幫助團隊消除約束 226
第9章 看板方法、流程和持續改進 233
9.1 第2幕：緊趕慢趕的遊戲 234
9.2 看板方法的原則 236
9.2.1 找到一個出發點並由此進行實驗性的演進 236
9.2.2 用戶故事進去，代碼出來 238
9.3 用看板方法改進流程 240
9.3.1 將工作流程可視化 241
9.3.2 限制進行中的工作 246
9.4 測量並管理流量 251
9.4.1 用CFD 和進行中工作面積圖測量並管理流量 252
9.4.2 用利特爾法則控制系統的流量 259
9.4.3 用進行中工作上限管理流量，自然地創造緩衝 263
9.4.4 讓過程策略明確統一 265
9.5 看板方法下自然發生的行為 266
第10章 敏捷教練 275
10.1 第3幕：還有一件事（又來了？！）…… 276
10.2 教練要理解人們為什麼不想改變 277
10.3 教練要理解人們如何學習 280
10.4 教練清楚如何讓一套方法起作用 284
10.5 進行敏捷指導時的原則 285
關於作者 288
關於封面 288
前言 xvii
第1章 學習敏捷 1
1.1 什麼是敏捷 2
1.2 本書的讀者對象 5
1.3 本書的目標 6
1.4 努力建立敏捷思維 6
1.5 本書結構 9
第2章 理解敏捷價值觀 11
2.1 團隊主管、架構師和項目經理走進了一間酒吧…… 12
2.2 沒有銀彈 14
2.3 敏捷可以拯救亂局嗎 16
2.3.1 引入敏捷，帶來變化 17
2.3.2 “聊勝於無”的結果 18
2.4 視角割裂 19
2.4.1 視角割裂帶來的問題 21
2.4.2 為什麼視角割裂只能做到“聊勝於無” 22
2.5 敏捷宣言幫助團隊認識實踐的目的 24
2.5.1 個體和互動高於流程和工具 25
2.5.2 可工作的軟體高於詳盡的文檔 25
2.5.3 客戶協作高於契約談判 26
2.5.4 回響變化高於遵循計畫 26
2.5.5 原則高於實踐 27
2.6 理解敏捷的“大象” 28
2.7 著手採用一套新方法 32
第3章 敏捷原則 37
3.1 敏捷軟體開發的12 條原則 38
3.2 客戶總是對的嗎 38
3.3 交付項目 40
3.3.1 原則1：最優先要做的是儘早、持續地交付有價值的軟體，讓客戶滿意 40
3.3.2 原則2：欣然面對需求變化，即使是在開發後期。敏捷過程利用變化為
客戶維持競爭優勢 41
3.3.3 原則3：頻繁交付可工作的軟體，從數周到數月，交付周期越短越好 42
3.3.4 改進電子書閱讀器團隊的項目交付計畫 44
3.4 溝通和合作 46
3.4.1 原則4：在團隊內外，面對面交談是最有效、也是最高效的溝通方式 48
3.4.2 原則5：在整個項目過程中，業務人員和開發人員必須每天都在一起工作 49
3.4.3 原則6：以受激勵的個體為核心構建項目，為他們提供環境和支持，
相信他們可以把工作做好 51
3.4.4 在電子書閱讀器項目中採用更好的溝通方式 52
3.5 項目實施——推進項目 53
3.5.1 原則7：可工作的軟體是衡量進度的首要標準 53
3.5.2 原則8：敏捷過程倡導可持續開發。贊助商、開發人員和用戶要能夠
共同、長期維持其步調，穩定向前 54
3.5.3 原則9：堅持不懈地追求技術卓越和設計優越，以此增強敏捷的能力 55
3.5.4 改善電子書閱讀器團隊的工作環境 55
3.6 項目和團隊的持續改進 56
3.6.1 原則10：簡單是盡最大可能減少不必要工作的藝術，是敏捷的根本 56
3.6.2 原則11：最好的架構、需求和設計來自自組織的團隊 57
3.6.3 原則12：團隊定期反思如何提升效率，並依此調整 57
3.7 敏捷項目：整合所有原則 58
第4章 Scrum和自組織團隊 62
4.1 Scrum的規則 64
4.2 第1幕：Scrum的適用條件 65
4.3 Scrum團隊中每個人都要對項目負責 67
4.3.1 Scrum主管指導團隊的決策 67
4.3.2 產品所有者幫助團隊了解軟體的價值 68
4.3.3 每個人都對項目負責 69
4.3.4 Scrum有一組自己的價值觀 75
4.4 第2幕：狀態更新只是社交網路的玩法 78
4.5 整個團隊參與每日Scrum例會 80
4.5.1 反饋和“可見− 檢查− 調整”周期 80
4.5.2 最後責任時刻 81
4.5.3 召開有效的每日Scrum例會 83
4.6 第3幕：將衝刺計畫寫到牆上 86
4.7 衝刺、計畫和回顧會議 87
4.7.1 疊代式與增量式 87
4.7.2 衝刺成也在於產品所有者，敗也在於產品所有者 89
4.7.3 可見性和價值觀 89
4.7.4 計畫並執行有效的Scrum衝刺 93
4.8 第4幕：盡力之後 94
第5章 Scrum計畫和集體承諾 99
5.1 第5幕：出乎意料 100
5.2 用戶故事、速度和普遍接受的Scrum實踐 102
5.2.1 提升軟體價值 102
5.2.2 以用戶故事構建用戶真正會用到的功能 103
5.2.3 滿意條件 105
5.2.4 故事點和速度 106
5.2.5 燃盡圖 108
5.2.6 通過用戶故事、故事點、任務和任務板來計畫並實施衝刺 111
5.2.7 廣受認可的Scrum實踐 115
5.3 第6幕：第一次勝利 116
5.4 回顧Scrum價值觀 116
5.4.1 具體實踐沒有價值觀也有效果（只是別管它叫Scrum） 117
5.4.2 你的公司文化與Scrum的價值觀兼容嗎 119
第6章 極限編程與擁抱變化 128
6.1 第1幕：開始加班 129
6.2 極限編程的主要實踐 130
6.2.1 編程實踐 130
6.2.2 集成實踐 131
6.2.3 計畫實踐 132
6.2.4 團隊實踐 133
6.2.5 為什麼開發團隊抵制變化，上述實踐如何提供幫助 134
6.3 第2幕：計畫有變，但我們還是看不到希望 137
6.4 極限編程的價值觀幫助團隊改變心態 139
6.4.1 極限編程幫助開發人員學會與用戶協作 141
6.4.2 開發團隊的懷疑會破壞實踐的效用 142
6.5 正確的思維從極限編程的價值觀開始 144
6.5.1 極限編程的價值觀 144
6.5.2 以善意鋪就 144
6.6 第3幕：勢頭的變換 147
6.7 理解極限編程價值觀，擁抱變化 148
6.7.1 極限編程的指導原則 149
6.7.2 極限編程指導原則可以加深對計畫的理解 151
6.7.3 極限編程指導原則與實踐相互促進 152
6.7.4 反饋循環 154
第7章 極限編程、簡化和增量式設計 163
7.1 第4幕：再次加班 164
7.2 代碼和設計 165
7.2.1 代碼異味和反模式（如何判斷你是不是聰明過頭了） 166
7.2.2 極限編程團隊主動尋找和修復代碼異味 168
7.2.3 鉤子、邊界情況以及功能過多的代碼 170
7.2.4 代碼異味會增加複雜性 175
7.3 把編碼和設計決定留到最後責任時刻 175
7.3.1 決然重構，償還技術債務 177
7.3.2 持續集成，排查設計問題 179
7.3.3 避免一體式設計 180
7.4 增量式設計與極限編程的整體實踐 182
7.4.1 有時間進行思考，團隊才能做好工作 184
7.4.2 團隊成員彼此信任並共同作出決定 186
7.4.3 極限編程的設計、計畫、團隊和整體實踐形成了一個帶動創新的系統 186
7.4.4 增量式設計與為了復用而設計 188
7.4.5 簡化單元互動，系統實現增量式成長 190
7.4.6 優秀的設計源自簡單的互動 190
7.5 第5幕：最終得分 192
第8章 精益、消除浪費和著眼全局 200
8.1 精益思維 201
8.1.1 你已經理解了很多精益價值觀 201
8.1.2 承諾、選擇意識和集合式開發 203
8.2 第1幕：還有一件事…… 207
8.3 創造英雄與神奇思維 209
8.4 消除浪費 210
8.5 加深對產品的理解 214
8.5.1 著眼全局 216
8.5.2 找到問題的根本原因 218
8.6 儘快交付 219
8.6.1 使用面積圖可視化工作進度 221
8.6.2 限制進行中的工作，控制瓶頸 225
8.6.3 拉動式系統幫助團隊消除約束 226
第9章 看板方法、流程和持續改進 233
9.1 第2幕：緊趕慢趕的遊戲 234
9.2 看板方法的原則 236
9.2.1 找到一個出發點並由此進行實驗性的演進 236
9.2.2 用戶故事進去，代碼出來 238
9.3 用看板方法改進流程 240
9.3.1 將工作流程可視化 241
9.3.2 限制進行中的工作 246
9.4 測量並管理流量 251
9.4.1 用CFD 和進行中工作面積圖測量並管理流量 252
9.4.2 用利特爾法則控制系統的流量 259
9.4.3 用進行中工作上限管理流量，自然地創造緩衝 263
9.4.4 讓過程策略明確統一 265
9.5 看板方法下自然發生的行為 266
第10章 敏捷教練 275
10.1 第3幕：還有一件事（又來了？！）…… 276
10.2 教練要理解人們為什麼不想改變 277
10.3 教練要理解人們如何學習 280
10.4 教練清楚如何讓一套方法起作用 284
10.5 進行敏捷指導時的原則 285
關於作者 288
關於封面 288
