本書將幫你確定應采用哪些原則來解決你的團隊、公司、項目的具體開發問題。你將發現如何使用那些信息指導方法論和實踐的選擇。
通過本書你將學到：
軟件開發團隊的價值觀；
體現這些價值的方法論；
組成這些方法論的實踐；
幫助你將這些價值觀、方法論和實踐都應用到你的團隊和公司的原則。

本書以敏捷軟件開發為中心，繫統闡述了敏捷原則和實踐的先進理念和重要意義，並分別講解了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．1Scrum 的規則64
4．2第1 幕：Scrum 的適用條件65
4．3Scrum 團隊中每個人都要對項目負責67
4．3．1Scrum 主管指導團隊的決策67
4．3．2產品所有者幫助團隊了解軟件的價值68
4．3．3每個人都對項目負責69
4．3．4Scrum 有一組自己的價值觀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