敏捷整潔之道-回歸本源

• 第 1章 介紹敏捷 1
  • 1.1 敏捷的歷史 3
  • 1.2 雪鳥會議 10
  • 1.3 敏捷全貌 14
    • 1.3.1 鐵十字 15
    • 1.3.2 墻上的圖 15
    • 1.3.3 你知道的第 一件事 18
    • 1.3.4 會議 18
    • 1.3.5 分析階段 19
    • 1.3.6 設計階段 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 敏捷產出資料 25
    • 1.3.13 幻想與管理 27
    • 1.3.14 管理鐵十字 27
    • 1.3.15 業務價值排序 31
    • 1.3.16 全貌至此結束 31
  • 1.4 生命之環 31
  • 1.5 結論 35
• 第 2章 敏捷的理由 37
  • 2.1 專業性 38
    • 2.1.1 到處是軟體 39
    • 2.1.2 程式員統治世界 41
    • 2.1.3 災難 42
    • 2.2 合理的期望 43
    • 2.2.1 我們不會交付一堆垃圾！ 43
    • 2.2.2 從技術上隨時做好交付準備 45
    • 2.2.3 穩定的生產率 46
    • 2.2.5 持續改進 50
    • 2.2.6 無畏之力 50
    • 2.2.7 QA應該什么也找不到 52
    • 2.2.8 測驗自動化 52
    • 2.2.10 誠實的估算 54
    • 2.2.11 你需要說“不” 55
    • 2.2.12 持續主動地學習 55
    • 2.2.13 指導 56
  • 2.3 權利條款 56
    • 2.3.1 客戶權利條款 56
    • 2.3.2 開發人員權利條款 57
    • 2.3.3 客戶權利詳討 57
    • 2.3.4 開發人員權利詳討 59
  • 2.4 結論 61
• 第3章 業務實踐 63
  • 3.1 計劃游戲 64
    • 3.1.1 三元分析 65
    • 3.1.2 故事和點數 66
    • 3.1.3 ATM的故事 67
    • 3.1.4 故事 74
    • 3.1.5 故事估算 76
    • 3.1.6 對迭代進行管理 78
    • 3.1.7 演示 80
    • 3.1.8 速率 81
  • 3.2 小步發布 82
    • 3.2.1 源代碼控制簡史 83
    • 3.2.2 磁帶 85
    • 3.2.3 磁盤和源代碼控制系統 85
    • 3.2.4 Subversion 86
    • 3.2.5 Git與測驗 87
    • 3.3 驗收測驗 88
    • 3.3.1 工具和方法論 89
    • 3.3.2 行為驅動開發 90
    • 3.3.3 實踐 90
  • 3.4 完整團隊 93
  • 3.5 結論 96
• 第4章 團隊實踐 97
  • 4.1 隱喻 98
  • 4.2 可持續節奏 100
    • 4.2.1 加班 102
    • 4.2.2 馬拉松 103
    • 4.2.3 奉獻精神 103
    • 4.2.4 睡眠 104
  • 4.3 代碼集體所有 104
  • 4.4 持續集成 107
    • 4.4.1 然后有了持續構建 108
    • 4.4.2 持續構建的紀律 109
  • 4.5 站會 110
    • 4.5.1 豬和雞？ 111
    • 4.5.2 公開表示認可 111
  • 4.6 結論 111
• 第5章 技術實踐 113
  • 5.1 測驗驅動開發 114
    • 5.1.1 復式記賬 114
    • 5.1.2 TDD三規則 116
    • 5.1.3 除錯 117
    • 5.1.4 檔案 117
    • 5.1.5 樂趣 118
    • 5.1.6 完備性 119
    • 5.1.7 設計 121
    • 5.1.8 勇氣 121
  • 5.2 重構 123
    • 5.2.1 紅-綠-重構 124
    • 5.2.2 大型重構 125
  • 5.3 簡單設計 125
  • 5.4 結對編程 127
    • 5.4.1 什么是結對 128
    • 5.4.2 為什么結對 129
    • 5.4.3 結對當作代碼評審 129
    • 5.4.4 代價幾何 130
    • 5.4.5 只能兩人嗎 130
    • 5.4.6 管理 130
  • 5.5 結論 131
• 第6章 成就敏捷 133
  • 6.1 敏捷的價值觀 134
    • 6.1.1 勇氣 134
    • 6.1.2 溝通 134
    • 6.1.3 反饋 135
    • 6.1.4 簡單 135
  • 6.2 怪物博物館 136
  • 6.3 轉型 137
    • 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 創建敏捷組織 141
  • 6.4 教練輔導 142
  • 6.5 認證 143
  • 6.6 大型組織中的敏捷 144
  • 6.7 敏捷工具 148
    • 6.7.1 軟體工具 148
    • 6.7.2 什么才是有效的工具 149
    • 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
    • 6.8.4 將教練技術帶給敏捷教練 158
    • 6.8.5 超越ICP-ACC 158
    • 6.8.6 教練工具 159
    • 6.8.7 只有專業教練技巧是不夠的 159
    • 6.8.8 在多團隊環境中進行敏捷教練的作業 160
    • 6.8.9 大型組織中的敏捷 161
    • 6.8.10 使用敏捷和教練技術 來變得敏捷 161
    • 6.8.11 敏捷匯入的成長 162
    • 6.8.12 細處著手成大事 164
    • 6.8.13 敏捷教練的未來 165
  • 6.9 結論（鮑勃大叔回來了） 165
• 第7章 匠藝 167
  • 7.1 敏捷的宿醉 169
  • 7.2 不孚所望 170
  • 7.3 漸行漸遠 172
  • 7.4 軟體匠藝 173
  • 7.5 思想體系與方法論 174
  • 7.6 軟體匠藝包含實踐嗎 175
  • 7.7 聚焦于價值而非實踐 176
  • 7.8 對實踐的討論 177
  • 7.9 匠藝對個人的影響 178
  • 7.10 匠藝對行業的影響 179
  • 7.11 匠藝對公司的影響 180
  • 7.12 匠藝與敏捷 181
  • 7.13 結論 182
• 第8章 結論 183
• 跋 185
• 索引 191
• 第 4 章 團隊實踐
  • 4.5 站會
• 第 5 章 技術實踐
  • 5.1 測驗驅動開發

第 1章 介紹敏捷 1

1.1 敏捷的歷史 3

• 我第一次嘗試了測驗驅動開發（TDD），從此深深著迷，

1.2 雪鳥會議 10

• 個體和互動高一流程和工具
• 可作業的軟體高于詳盡的檔案
• 客戶合作高于合同談判
• 回應變化高于遵循計劃

1.3 敏捷全貌 14

1.3.1 鐵十字 15

• 質量、速度、成本、完成，你只能任選3個，沒法4個全要，

1.3.2 墻上的圖 15

1.3.3 你知道的第 一件事 18

• 交付日期

1.3.4 會議 18

1.3.5 分析階段 19

1.3.6 設計階段 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 敏捷產出資料 25

1.3.13 幻想與管理 27

1.3.14 管理鐵十字 27

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

1.3.15 業務價值排序 31

1.3.16 全貌至此結束 31

1.4 生命之環 31

• 極限編程是敏捷本質核心的原型，也是最好的代表，

• 極限編程的生命之環（敏捷運動的發起人之一：肯特 貝克）

  • 

• 業務實踐

  • 計劃游戲
  • 小步發布
  • 驗收測驗
  • 完整團隊

• 團隊實踐

  • 可持續節奏
  • 代碼集體所有
  • 持續集成
  • 隱喻

• 技術實踐

  • 結對
  • 簡單設計
  • 重構
  • 測驗驅動開發

1.5 結論 35

第 2章 敏捷的理由 37

2.1 專業性 38

• 敏捷吸引我的第一要素是導讀重視紀律而非形式，
• 要把敏捷做對，你需要結對編程、測驗先行、重構并致力于簡單設計，

2.1.1 到處是軟體 39

2.1.2 程式員統治世界 41

2.1.3 災難 42

• 在把計算機編程編程真正光榮職業的道路上，敏捷軟體開發將是我們邁出的第一步，

2.2 合理的期望 43

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

• 請注意，敏捷中強調測驗、重構、簡單設計以及用戶反饋，就是為了避免交付糟糕的代碼，

2.2.2 從技術上隨時做好交付準備 45

2.2.3 穩定的生產率 46

• 雜亂代碼越多，阻礙越大，進度越慢，團隊進展越慢，專案日程壓力就更大，這又會帶來更多的混亂，
• 增加人力反而會拖慢團隊好幾周，
• 大規模的重新設計極其昂貴，而且很少真正部署上線，

• 開發人員對自己的要求不應該低于此，持續地將架構、設計以及代碼保持在盡可能干凈的狀態

  2.2.4 劃算的適應性 49

• 軟體就是“容易修改的產品”，

• 客戶、用戶和管理者都希望軟體系統容易修改、修改的成本不高并且成本與收益相符，

• 我們將看到測驗驅動開發、重構和簡單設計等敏捷實踐是如何確保以最小的代價安全地更改軟體系統，

2.2.5 持續改進 50

• 結對編程、測驗驅動開發、重構、簡單設計等敏捷實踐強有力地支持持續改進的期望，

2.2.6 無畏之力 50

• 測驗驅動開發的敏捷實踐為你提供了無所畏懼的能力，

2.2.7 QA應該什么也找不到 52

• 驗收測驗、測驗驅動開發以及持續集成等敏捷實踐支持這個期望，

2.2.8 測驗自動化 52

• 手工測驗應該僅限于那些無法自動驗證的事情，以及需要創新能力的探索性測驗上，

• 驗收測驗、測驗驅動開發以及持續集成等敏捷實踐支持這個期望，

  2.2.9 我們互相掩護 54

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

2.2.10 誠實的估算 54

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

2.2.11 你需要說“不” 55

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

2.2.12 持續主動地學習 55

2.2.13 指導 56

2.3 權利條款 56

2.3.1 客戶權利條款 56

2.3.2 開發人員權利條款 57

2.3.3 客戶權利詳討 57

2.3.4 開發人員權利詳討 59

2.4 結論 61

• 敏捷不僅僅是一組規則，還是構成軟體開發職業道德基礎的權利、期望和紀律的組合體，

第3章 業務實踐 63

3.1 計劃游戲 64

3.1.1 三元分析 65

3.1.2 故事和點數 66

3.1.3 ATM的故事 67

3.1.4 故事 74

3.1.5 故事估算 76

3.1.6 對迭代進行管理 78

3.1.7 演示 80

3.1.8 速率 81

3.2 小步發布 82

3.2.1 源代碼控制簡史 83

3.2.2 磁帶 85

3.2.3 磁盤和源代碼控制系統 85

3.2.4 Subversion 86

3.2.5 Git與測驗 87

3.3 驗收測驗 88

3.3.1 工具和方法論 89

3.3.2 行為驅動開發 90

3.3.3 實踐 90

3.4 完整團隊 93

3.5 結論 96

第4章 團隊實踐 97

4.1 隱喻 98

4.2 可持續節奏 100

4.2.1 加班 102

4.2.2 馬拉松 103

4.2.3 奉獻精神 103

4.2.4 睡眠 104

4.3 代碼集體所有 104

4.4 持續集成 107

4.4.1 然后有了持續構建 108

4.4.2 持續構建的紀律 109

4.5 站會 110

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

4.5.1 豬和雞？ 111

4.5.2 公開表示認可 111

4.6 結論 111

第5章 技術實踐 113

5.1 測驗驅動開發 114

• 沒有測驗驅動開發、重構、簡單設計及結對編程的明姐只是虛有其表，起不到作用，

5.1.1 復式記賬 114

5.1.2 TDD三規則 116

• TDD的好處
  • 更少的除錯
  • 高質量的詳細檔案
  • 有趣、完備的測驗
  • 解耦
  • 勇氣
  • 我們之所以實踐TDD，是因為它給了我們勇氣，去保持代碼整潔有序，它給了我們勇氣，讓我們表現得像一個專業人士，

5.1.3 除錯 117

5.1.4 檔案 117

5.1.5 樂趣 118

5.1.6 完備性 119

5.1.7 設計 121

5.1.8 勇氣 121

5.2 重構 123

5.2.1 紅-綠-重構 124

5.2.2 大型重構 125

5.3 簡單設計 125

5.4 結對編程 127

5.4.1 什么是結對 128

5.4.2 為什么結對 129

5.4.3 結對當作代碼評審 129

5.4.4 代價幾何 130

5.4.5 只能兩人嗎 130

5.4.6 管理 130

5.5 結論 131

第6章 成就敏捷 133

6.1 敏捷的價值觀 134

6.1.1 勇氣 134

6.1.2 溝通 134

6.1.3 反饋 135

6.1.4 簡單 135

6.2 怪物博物館 136

6.3 轉型 137

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 創建敏捷組織 141

6.4 教練輔導 142

6.5 認證 143

6.6 大型組織中的敏捷 144

6.7 敏捷工具 148

6.7.1 軟體工具 148

6.7.2 什么才是有效的工具 149

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

6.8.4 將教練技術帶給敏捷教練 158

6.8.5 超越ICP-ACC 158

6.8.6 教練工具 159

6.8.7 只有專業教練技巧是不夠的 159

6.8.8 在多團隊環境中進行敏捷教練的作業 160

6.8.9 大型組織中的敏捷 161

6.8.10 使用敏捷和教練技術 來變得敏捷 161

6.8.11 敏捷匯入的成長 162

6.8.12 細處著手成大事 164

6.8.13 敏捷教練的未來 165

6.9 結論（鮑勃大叔回來了） 165

第7章 匠藝 167

7.1 敏捷的宿醉 169

7.2 不孚所望 170

7.3 漸行漸遠 172

7.4 軟體匠藝 173

7.5 思想體系與方法論 174

7.6 軟體匠藝包含實踐嗎 175

7.7 聚焦于價值而非實踐 176

7.8 對實踐的討論 177

7.9 匠藝對個人的影響 178

7.10 匠藝對行業的影響 179

7.11 匠藝對公司的影響 180

7.12 匠藝與敏捷 181

7.13 結論 182

第8章 結論 183

跋 185

索引 191

• 敏捷
  • 敏捷是將專案切分未迭代的程序，
  • 敏捷團隊要測量每次迭代的輸出，并用測量資料持續地評估時間表，
  • 按照業務價值排序來實作功能，以便優先實施最有價值的東西，
  • 他們盡可能地保持高質量，
  • 通過變更范圍來管理時間表

第 4 章 團隊實踐

4.5 站會

第 5 章 技術實踐

5.1 測驗驅動開發

標籤：其他

上一篇：MFC操作SQL新建資料庫和資料庫表格

下一篇：DORA Research Program