第 1章 介紹敏捷 1

1.1 敏捷的歷史 3

• 我第一次嘗試了測試驅(qū)動開發(fā)（TDD）,，從此深深著迷,。

1.2 雪鳥會議 10

• 個體和互動高一流程和工具
• 可工作的軟件高于詳盡的文檔
• 客戶合作高于合同談判
• 響應(yīng)變化高于遵循計劃

1.3 敏捷全貌 14

1.3.1 鐵十字 15

• 質(zhì)量、速度,、成本,、完成，你只能任選3個,，沒法4個全要,。

1.3.2 墻上的圖 15

1.3.3 你知道的第 一件事 18

• 交付日期

1.3.4 會議 18

1.3.5 分析階段 19

1.3.6 設(shè)計階段 20

1.3.7 實施階段 21

1.3.8 死亡行軍階段 22

1.3.9 夸張嗎 23

1.3.10 更好的方式 23

1.3.11 迭代0 24

1.3.12 敏捷產(chǎn)出數(shù)據(jù) 25

1.3.13 幻想與管理 27

1.3.14 管理鐵十字 27

• 為延遲的項目增加人手反而會是它更加延遲。
• 快速前進的唯一方法就是做扎實,。
• 寫了二三十年程序之后,，這是你會學到的最重要一課。沒有“快而臟”這樣的事,，逢臟必慢,。

1.3.15 業(yè)務(wù)價值排序 31

1.3.16 全貌至此結(jié)束 31

1.4 生命之環(huán) 31

• 極限編程是敏捷本質(zhì)核心的原型，也是最好的代表,。

• 極限編程的生命之環(huán)（敏捷運動的發(fā)起人之一：肯特 貝克）

  • 

• 業(yè)務(wù)實踐

  • 計劃游戲
  • 小步發(fā)布
  • 驗收測試
  • 完整團隊

• 團隊實踐

  • 可持續(xù)節(jié)奏
  • 代碼集體所有
  • 持續(xù)集成
  • 隱喻

• 技術(shù)實踐

  • 結(jié)對
  • 簡單設(shè)計
  • 重構(gòu)
  • 測試驅(qū)動開發(fā)

1.5 結(jié)論 35

第 2章 敏捷的理由 37

2.1 專業(yè)性 38

• 敏捷吸引我的第一要素是導(dǎo)讀重視紀律而非形式,。
• 要把敏捷做對，你需要結(jié)對編程,、測試先行,、重構(gòu)并致力于簡單設(shè)計。

2.1.1 到處是軟件 39

2.1.2 程序員統(tǒng)治世界 41

2.1.3 災(zāi)難 42

• 在把計算機編程編程真正光榮職業(yè)的道路上,，敏捷軟件開發(fā)將是我們邁出的第一步,。

2.2 合理的期望 43

2.2.1 我們不會交付一堆垃圾！ 43

• 請注意,，敏捷中強調(diào)測試,、重構(gòu)、簡單設(shè)計以及用戶反饋,，就是為了避免交付糟糕的代碼,。

2.2.2 從技術(shù)上隨時做好交付準備 45

2.2.3 穩(wěn)定的生產(chǎn)率 46

• 雜亂代碼越多，阻礙越大,，進度越慢,。團隊進展越慢，項目日程壓力就更大,，這又會帶來更多的混亂,。
• 增加人力反而會拖慢團隊好幾周。
• 大規(guī)模的重新設(shè)計極其昂貴,，而且很少真正部署上線,。
• 開發(fā)人員對自己的要求不應(yīng)該低于此。持續(xù)地將架構(gòu)、設(shè)計以及代碼保持在盡可能干凈的狀態(tài)

2.2.4 劃算的適應(yīng)性 49

• 軟件就是“容易修改的產(chǎn)品”,。
• 客戶,、用戶和管理者都希望軟件系統(tǒng)容易修改、修改的成本不高并且成本與收益相符,。
• 我們將看到測試驅(qū)動開發(fā),、重構(gòu)和簡單設(shè)計等敏捷實踐是如何確保以最小的代價安全地更改軟件系統(tǒng)。

2.2.5 持續(xù)改進 50

• 結(jié)對編程,、測試驅(qū)動開發(fā),、重構(gòu)、簡單設(shè)計等敏捷實踐強有力地支持持續(xù)改進的期望,。

2.2.6 無畏之力 50

• 測試驅(qū)動開發(fā)的敏捷實踐為你提供了無所畏懼的能力,。

2.2.7 QA應(yīng)該什么也找不到 52

• 驗收測試、測試驅(qū)動開發(fā)以及持續(xù)集成等敏捷實踐支持這個期望,。

2.2.8 測試自動化 52

• 手工測試應(yīng)該僅限于那些無法自動驗證的事情,，以及需要創(chuàng)新能力的探索性測試上。
• 驗收測試,、測試驅(qū)動開發(fā)以及持續(xù)集成等敏捷實踐支持這個期望,。

2.2.9 我們互相掩護 54

• 結(jié)對編程、完整團隊和代碼集體所有的敏捷實踐支持這些期望,。

2.2.10 誠實的估算 54

• 最誠實的估算就是“我不知道”,。

2.2.11 你需要說“不” 55

• 當答案確實是“不”的時候，我期望你能夠說出“不”,。

2.2.12 持續(xù)主動地學習 55

2.2.13 指導(dǎo) 56

2.3 權(quán)利條款 56

2.3.1 客戶權(quán)利條款 56

2.3.2 開發(fā)人員權(quán)利條款 57

2.3.3 客戶權(quán)利詳討 57

2.3.4 開發(fā)人員權(quán)利詳討 59

2.4 結(jié)論 61

• 敏捷不僅僅是一組規(guī)則,，還是構(gòu)成軟件開發(fā)職業(yè)道德基礎(chǔ)的權(quán)利、期望和紀律的組合體,。

第3章 業(yè)務(wù)實踐 63

3.1 計劃游戲 64

3.1.1 三元分析 65

3.1.2 故事和點數(shù) 66

3.1.3 ATM的故事 67

3.1.4 故事 74

• 故事遵循一簡單的指導(dǎo)原則：（INVEST）
  • I：獨立（Independent）
  • N：可協(xié)商（Negotiable）
  • V：有價值（Valueable）
    • 故事永遠是有業(yè)務(wù)價值的東西,。
  • E：可估算（Estimable）
  • S：小（Small）
  • T：可測試（Testable）

3.1.5 故事估算 76

• 伸指頭

3.1.6 對迭代進行管理 78

• 故事都是由程序員自己選 擇的,。
• 經(jīng)理和主管可能傾向于將故事分配給程序員,。應(yīng)該避免這種情況，而讓程序員自己進行協(xié)商,，這樣做的效果要好得多,。
• 如果沒有在中期節(jié)點之前準備好所有驗收測試,，那么一些開發(fā)人員應(yīng)該停止開發(fā)故事,，并開始編寫驗收測試。

3.1.7 演示 80

3.1.8 速率 81

• 不要給度量對象施加壓力
• 最可能導(dǎo)致速率圖顯示持續(xù)的負斜率的因素是代碼質(zhì)量,。
• 團隊很有可能沒有進行足夠的重構(gòu),，而且可能坐視代碼腐爛。
• 團隊無法充分重構(gòu)的原因之一是由于沒有充分的單元測試，因此他們擔心重構(gòu)會破環(huán)過去可運行的部分,。

3.2 小步發(fā)布 82

3.2.1 源代碼控制簡史 83

3.2.2 磁帶 85

3.2.3 磁盤和源代碼控制系統(tǒng) 85

3.2.4 Subversion 86

3.2.5 Git與測試 87

3.3 驗收測試 88

• 應(yīng)該由業(yè)務(wù)方負責說明需求的規(guī)格,。
• 規(guī)格說明是一種測試。

3.3.1 工具和方法論 89

3.3.2 行為驅(qū)動開發(fā) 90

• 他們的目標是從測試中去掉技術(shù)術(shù)語,，是測試看起來更像業(yè)務(wù)人員會喜歡的樣子,。

3.3.3 實踐 90

• 程序員才能知道他們開發(fā)的故事是否完成。

3.4 完整團隊 93

• 用戶和程序員之間的距離越短,，交流就越好,，開發(fā)就越快、越準確,。
• 當整個團隊坐在同一個空間里,，魔術(shù)般的變化就能發(fā)生。
• 當團隊在同一地點時,，業(yè)務(wù)運行會更順暢,。

3.5 結(jié)論 96

• 在2001 年的雪鳥會議上，肯特*貝克說,，我們的目標之一是彌合業(yè)務(wù)與開發(fā)之間的鴻溝,。

第4章 團隊實踐 97

• 實踐包括隱喻、可持續(xù)節(jié)奏,、代碼集體所有和持續(xù)集成,。

4.1 隱喻 98

• 為了有效地進行溝通，團隊需要一個受限制的,、有紀律的詞匯表,，其中包含項目中的術(shù)語及概念。

4.2 可持續(xù)節(jié)奏 100

• 快跑的未必能贏......

4.2.1 加班 102

• 自己最糟糕的技術(shù)錯誤都是在狂熱熬夜時犯下的,。

4.2.2 馬拉松 103

• 我學到了軟件項目是一場馬拉松,，不是沖刺，更不是一系列連續(xù)沖刺,。
• 你有義務(wù)節(jié)約自己的資源以確保堅持到最后,。

4.2.3 奉獻精神 103

• 加班工作并不能向雇主展現(xiàn)你的奉獻精神。
• 這只能表明你的計劃做得糟糕,，你答應(yīng)了不該答應(yīng)的截止日期,，
• 承諾了不該承諾的事情，你只是一個可被操縱的勞工而非專業(yè)人士,。
• 你必須非常清醒地意識到加班的成本可能遠遠超過省下的時間,。

4.2.4 睡眠 104

• 程序員最寶貴的養(yǎng)生之道就是充足的睡眠。

4.3 代碼集體所有 104

• 代碼集體所有并非說你不能有所專長,。

4.4 持續(xù)集成 107

4.4.1 然后有了持續(xù)構(gòu)建 108

4.4.2 持續(xù)構(gòu)建的紀律 109

• 持續(xù)構(gòu)建應(yīng)該用不被破壞,。
• 構(gòu)建永不失敗,。

4.5 站會 110

• 怎么做
  • 上次會議之后我做了什么？
  • 下次會議之前我將做什么,？
  • 什么阻礙了我,？
  • 你想要感謝誰？
• 不要做
  • 不要討論
  • 不要裝腔作勢
  • 不要深入解釋
  • 不要藏著掖著
  • 不要帶有情緒
  • 不要八卦
  • 不要發(fā)牢騷

4.5.1 豬和雞,？ 111

4.5.2 公開表示認可 111

• 你想要感謝誰,？

4.6 結(jié)論 111

第5章 技術(shù)實踐 113

5.1 測試驅(qū)動開發(fā) 114

• 沒有測試驅(qū)動開發(fā)、重構(gòu),、簡單設(shè)計及結(jié)對編程的明姐只是虛有其表,，起不到作用。

5.1.1 復(fù)式記賬 114

• 測試驅(qū)動開發(fā)是程序員的相應(yīng)實踐,。每個必要的行為都輸出兩次：一次作為測試,，另一次作為使測試通過的生產(chǎn)代碼。
• 學習 TDD 的程序員被教會每次只添加一個行為--先寫一個失敗的測試,，然后寫恰好使測試通過的生產(chǎn)代碼,。
• 盡管編程對社會來說已經(jīng)必不可少，但我們還沒有用法律強制實施 TDD,。
• 可是,，既然編寫糟糕的軟件已經(jīng)造成了生命財產(chǎn)損失，立法還會遠嗎,？

5.1.2 TDD三規(guī)則 116

• TDD 可以描述為以下 3 條簡單的規(guī)則：
  • 先編寫一個因為缺乏生產(chǎn)代碼而失敗的測試,，然后才能編寫生產(chǎn)代碼。
  • 只允許編寫一個剛好失敗的測試--編譯失敗也算,。
  • 只允許編寫剛好能使當前失敗測試通過的生產(chǎn)代碼,。

5.1.3 調(diào)試 117

• 但是通過實踐 TDD 的 3 條規(guī)則，就可以大大降低 bug 的發(fā)生率和嚴重性,。

5.1.4 文檔 117

• 測試集已經(jīng)以各種方式調(diào)用該函數(shù),，并捕獲其可能引發(fā)的每個異常。

5.1.5 樂趣 118

• 如果你曾事后補寫測試,，你就應(yīng)該知道,，那不好玩。
• 因為你已經(jīng)知道代碼可以工作,，你已經(jīng)手工測試過,。

5.1.6 完備性 119

• 不要因為覆蓋率不足而使構(gòu)建失敗。

5.1.7 設(shè)計 121

• 通過先寫測試,，你將以此前從未想過的方式解耦系統(tǒng),。
• 整個系統(tǒng)將是可測試的，所以整個系統(tǒng)也將被解耦,。

5.1.8 勇氣 121

• TDD的好處
  • 更少的調(diào)試
  • 高質(zhì)量的詳細文檔
  • 有趣,、完備的測試
  • 解耦
  • 勇氣
  • 我們之所以實踐TDD，是因為它給了我們勇氣,，去保持代碼整潔有序,。它給了我們勇氣，讓我們表現(xiàn)得像一個專業(yè)人士,。

5.2 重構(gòu) 123

5.2.1 紅-綠-重構(gòu) 124

• 在 TDD 三規(guī)則的基礎(chǔ)上在結(jié)合重構(gòu)過程,，就是廣為人知的“紅-綠-重構(gòu)”。
  • 1. 創(chuàng)建一個失敗的測試,。
  • 2. 是測試通過,。
  • 3. 清理代碼。
  • 4. 返回步驟 1,。
• 編寫可用的代碼與編寫整潔的代碼是編程的兩個不同的維度,。
• 重構(gòu)是一個持續(xù)的過程
• 重構(gòu)一次永遠不應(yīng)該出現(xiàn)在時間表上。
• 重構(gòu)活動也不應(yīng)該出現(xiàn)在項目的計劃中,。

5.2.2 大型重構(gòu) 125

• 這種修改同樣納入紅-綠-重構(gòu)循環(huán)內(nèi),。

5.3 簡單設(shè)計 125

• 簡單設(shè)計實踐是重構(gòu)的目標之一。
• 簡單設(shè)計的意思是：僅編寫必要的代碼,，使得程序結(jié)構(gòu)保持簡單,、最小和最富表現(xiàn)力。
• 簡單設(shè)計的規(guī)則如下：
  • 所有測試通過,。
  • 揭示意圖,。
  • 消除重復(fù)。
  • 減少元素,。

5.4 結(jié)對編程 127

• 結(jié)對是可選的,。
• 結(jié)對是間歇性的。

5.4.1 什么是結(jié)對 128

5.4.2 為什么結(jié)對 129

• 結(jié)對是團隊成員之間共享知識并方式形成知識孤島的最佳方法,。

5.4.3 結(jié)對當作代碼評審 129

5.4.4 代價幾何 130

• 直接成本可能約為15%

5.4.5 只能兩人嗎 130

5.4.6 管理 130

• 永遠,、永遠不要請求管理者允許你結(jié)對，或測試,，或重構(gòu),，或者......你是專家。你決定,。

5.5 結(jié)論 131

• 敏捷的技術(shù)實踐是任何敏捷工作中最本質(zhì)的組成部分,。
• 任何敏捷實踐導(dǎo)入的嘗試，如果不包含技術(shù)實踐,，就注定會失敗,。

第6章 成就敏捷 133

6.1 敏捷的價值觀 134

• 敏捷的4個價值觀：勇氣、溝通,，反饋和簡單,。

• 6.1.1 勇氣 134

• 維護高質(zhì)量代碼和高質(zhì)量的紀律需要勇氣,。

• 通過犧牲質(zhì)量來遵守時間表就是魯莽。

• 質(zhì)量和紀律會提高速度,，這是一種信念,。

• 強勢但優(yōu)質(zhì)的人們在面對時間壓力時會不斷挑戰(zhàn)這種信念，因此堅持正確的信念需要勇氣,。

6.1.2 溝通 134

• 重視面對面,、非正式的人際對話。
• 坐在一起并經(jīng)常交流的團隊可以創(chuàng)造奇跡,。

6.1.3 反饋 135

• 敏捷團隊因反饋而健壯,。
• 計劃游戲、重構(gòu),、測試驅(qū)動開發(fā),、持續(xù)集成、小步發(fā)布,、代碼集體所有,、完整團隊等實踐最大化反饋的頻率和數(shù)量。

6.1.4 簡單 135

• 軟件中的每個問題都可以通過添加間接層來解決,。
• 保持代碼簡單,。保持段對更簡單。

6.2 怪物博物館 136

• 導(dǎo)入完整的生命之環(huán),，特別要包含技術(shù)實踐,。
• 大多數(shù)的團隊只導(dǎo)入了外圈的業(yè)務(wù)環(huán)，然后發(fā)現(xiàn)自己掉進了陷阱,，馬丁*福勒稱之為“疲軟的Scrum”,。
• 生產(chǎn)力大量流失的原因在于代碼本身的腐壞和惡化。

6.3 轉(zhuǎn)型 137

• 敏捷開發(fā)的價值觀包括勇于冒險,、快速反饋,、熱情、人與人之間跨越障礙和指揮結(jié)構(gòu)的頻密溝通,。

6.3.1 ?；ㄕ?138

6.3.2 幼獅 138

6.3.3 哭泣 139

6.3.4 寓意 139

6.3.5 假裝 139

6.3.6 在更小的組織中成功 140

• 保持著直截了當、敢于冒險的精神,。

6.3.7 個人成功和遷移 141

6.3.8 創(chuàng)建敏捷組織 141

6.4 教練輔導(dǎo) 142

• 目標是灌輸明杰價值觀及傳授明杰紀律,。
• 這個角色應(yīng)該盡快從團隊內(nèi)部選拔出來。
• 隊員會在無意中停止了結(jié)對,、停止了重構(gòu),，或者忽略了持續(xù)構(gòu)建中的那些失敗。教練的工作就是看到這些現(xiàn)象,，并向全團隊指出來,。
• 教練是團隊的良知,，總是提醒團隊對自己的承諾和一致同意必須秉持的價值觀。
• 教練的角色完全是內(nèi)部的,。

6.5 認證 143

• 培訓不應(yīng)該集中在某個特定的角色上,，而是應(yīng)該針對團隊中的每個人。
• 敏捷團隊的每個成員都需要了解敏捷的價值觀和技術(shù),。

6.6 大型組織中的敏捷 144

• 團隊中包含 4～12 名軟件開發(fā)人員。
• 敏捷是為中小型團隊服務(wù)的,，就這樣,。對于中小型團隊，敏捷很有效,。
• 敏捷從來不是為大型團隊設(shè)計的,。
• 我們不知道如何有效地組織一個相對較小的程序員團隊來提高效率。敏捷解決的正是這個問題,。
• 根本沒有所謂的大規(guī)模敏捷,。

6.7 敏捷工具 148

6.7.1 軟件工具 148

• 軟件開發(fā)人員必須掌握一些核心工具：
  • 至少一門編程語言，通常會是多門,；
  • 一個集成開發(fā)環(huán)境（IDE）或者程序員使用的編輯器（vim,、Tmacs 等）；
  • 各種數(shù)據(jù)格式（JSON,、XML,、YAML等）和標記語言（包括 HTML）；
  • 基于命令行和腳本與操作系統(tǒng)進行交互,；
  • 源代碼倉庫工具（Git,。除此之外還有其他的選項嗎？）,；
  • 持續(xù)集成/持續(xù)構(gòu)建工具（Jenkins,、TeamCity、GoCD等）,；
  • 部署/服務(wù)器管理工具（Docker,、Kubernetes、Ansible,、Chef,、Puppet等）；
  • 溝通工具--電子郵件,、Slack,、英語（！）,；
  • 測試工具（單元測試框架,、Cucumber,、Selenium等）；

6.7.2 什么才是有效的工具 149

• 優(yōu)秀的工具可以做到以下幾點：
  • 幫組人們實現(xiàn)目標,；
  • 可以很快到“足夠好”的程度,；
  • 對用戶透明；
  • 允許適配和擴展,；
  • 經(jīng)濟上負擔得起,。

6.7.3 物理的敏捷工具 151

6.7.4 自動化的壓力 152

6.7.5 有錢人用的ALM類工具 153

6.8 教練——另一個視角 155

6.8.1 條條大路通敏捷 155

6.8.2 從過程專家到敏捷專家 156

6.8.3 對敏捷教練的需求 157

• 要想變的敏捷，需要重新審視根生蒂固的觀念,、文化,、過程、思維和工作方式,。
• 讓一個人轉(zhuǎn)變思維,、幫組他看到“這對我有什么好處”。
• 變革能持續(xù)的關(guān)鍵在于：找到人們意識到并愿意投資的問題或者機遇,，然后幫組他們實現(xiàn)目標,。

6.8.4 將教練技術(shù)帶給敏捷教練 158

• 《如何構(gòu)建敏捷項目管理團隊》-麗薩

6.8.5 超越ICP-ACC 158

6.8.6 教練工具 159

6.8.7 只有專業(yè)教練技巧是不夠的 159

• 敏捷教練可以從六大專業(yè)領(lǐng)域中汲取知識：敏捷框架、敏捷轉(zhuǎn)型,、敏捷產(chǎn)品管理,、敏捷技術(shù)實踐、引導(dǎo)技術(shù),、教練技術(shù),。
• 添加新的功能時必須同時添加新的測試

6.8.8 在多團隊環(huán)境中進行敏捷教練的工作 160

6.8.9 大型組織中的敏捷 161

6.8.10 使用敏捷和教練技術(shù) 來變得敏捷 161

6.8.11 敏捷導(dǎo)入的成長 162

6.8.12 細處著手成大事 164

6.8.13 敏捷教練的未來 165

6.9 結(jié)論（鮑勃大叔回來了） 165

第7章 匠藝 167

7.1 敏捷的宿醉 169

7.2 不孚所望 170

7.3 漸行漸遠 172

7.4 軟件匠藝 173

7.5 思想體系與方法論 174

• 沒有實踐的原則只是空殼，而沒有原則的實踐往往是沒有判斷力的死記硬背,。
• 原則指導(dǎo)實踐,，實踐具像化原則，兩者齊頭并進,。

7.6 軟件匠藝包含實踐嗎 175

• 自 2008 年創(chuàng)建以來,，軟件匠藝社區(qū)認為極限編程是當下的最佳敏捷開發(fā)實踐集。

7.7 聚焦于價值而非實踐 176

• 如果人們看不到價值,，就不會改變他們的工作方式,。

7.8 對實踐的討論 177

• 圍繞實踐的討論應(yīng)該是在合適的級別、與合適的人進行,。

7.9 匠藝對個人的影響 178

• 正是通過軟件匠藝社區(qū),，開發(fā)人員學習測試驅(qū)動開發(fā)（TDD）、集成測試,、結(jié)對編程,、簡單設(shè)計、SOLID 原則、整潔代碼和重構(gòu),。

7.10 匠藝對行業(yè)的影響 179

7.11 匠藝對公司的影響 180

7.12 匠藝與敏捷 181

7.13 結(jié)論 182

第8章 結(jié)論 183

• 敏捷的本源從未變過,。它們是羅恩*杰弗里斯的生命之環(huán)中的紀律，它們是肯特-貝克的《解析極限編程-擁抱變化》一書中的價值觀,、原則和紀律,，它們是馬丁-福勒的《重構(gòu)：改善既有代碼的設(shè)計（第 2 版）》一書中的動機、技術(shù)和紀律,。

跋 185

索引 191