軟件項目的藝術

史蒂夫·麥康奈爾（Steve McConnell）
代表作有《代碼大全》（2019年被《福布斯》技術委員會評為“軟件開發奠基之作”）。先後創辦Construx Software 和 Rain Dog（目前主要為客戶提供投資規劃和管理服務以及開發投資預測和分析工具）。
此前作為 Construx Software 創始人兼首席軟件工程師，他負責領導軟件項目，也為其他公司提供軟件項目咨詢服務，他還通過著書立說的方式， 成為軟件工程知識體系的佈道者。他是《IEEE軟件》和《軟件從業者》雜志的編委會成員、《IEEE計算機》雜志資深審稿人、IEEE 計算機協會及 ACM 的重要貢獻者。
作為社區與公共事務的積極參與者，他擔任過貝爾維尤學校董事會主席、貝爾維尤扶輪社主席、洛克利文社區協會董事會成員、CDC Covid 預測模型的貢獻者、IEEE專委會主席、《IEEE軟件》雜志主編、軟件工程知識體系專家組成員，惠特曼文理學院和西雅圖大學計算機科學顧問委員會成員。
史蒂夫在惠特曼文理學院獲得哲學和計算機科學的雙學士學位，在西雅圖大學獲得了軟件工程碩士學位。
方敏
就職於微軟公司，擔任首席測試總監期間，對必應搜索、中國創新項目、WindowsServer、SQLServer、COM 服務等產品和服務做出了重要的貢獻。他擁有近三十年工程技術團隊和項目管理經驗，精通軟件敏捷開發和傳統軟件項目管理。他註重創新，註重發揮團隊優勢。
方敏是微軟美國華人協會的創始成員之一，該協會有幾千名會員。他是美國西雅圖地區知名的職場發展專家，熱衷於提升在美華人的國際競爭力。曾經多次受邀為母校清華大學舉辦國際化職場發展和軟件技能講座。方敏畢業於清華大學，獲得電子工程學士和碩士學位，後來在美國新墨西哥州礦業技術學院獲得計算機科學碩士學位。
朱嶸
朱嶸早年就職於英國BAE系統公司，在其美國分支機構擔任質量工程師，負責空客和波音多種機型的關鍵質量分析與故障維修。她畢業於哈爾濱工業大學，獲得無線電工程系信息工程專業的學士學位。

詳細目錄

第Ⅰ部分  項目生存思維

第1章　歡迎加入項目生存訓練營 3

1.1　生存需求 4

1.2　生存權利 7

1.3　生存檢查清單：項目健康測試 9

生存檢查清單 10

譯者有話說 10

第2章　軟件項目生存測試 11

2.1　生存測試題 11

2.2　生存測試問捲 11

2.2　生存測試問捲 12

2.3　生存測試結果解釋 14

生存檢查清單 16

譯者有話說 16

第3章　項目生存的概念 17

3.1　軟件開發流程的作用 17

3.1.1　對流程的誤區 18

3.1.2　拯救流程 23

3.1.3　流程與團隊的創新和士氣 25

3.1.4　 過渡到系統化流程的理由 27

3.2　流程的上游和下游 28

3.3　不確定性錐 30

生存檢查清單 33

譯者有話說 34

第4章　項目生存的關鍵方法 35

4.1　規劃 35

軟件規劃示例 37

4.2　規劃檢查點的審查 38

4.2.1　兩階段籌資方法 38

4.2.2　準備規劃檢查點的審查 39

4.2.3　規劃檢查點審查議程 40

4.2.4　規劃檢查點審查的主要意義 41

4.3　風險管理 42

4.4　項目控制 43

4.5　項目的可見性 44

4.6　人件 45

4.6.1　開發人員的興趣與工作分配要對齊 46

4.6.2　向開發人員表達誠摯的謝意 47

4.6.3　提供有利於思考的辦公空間 47

4.6.4　避免開放式工作空間 47

4.7　用戶參與 49

4.8　產品極簡主義 51

4.9　專註於軟件交付 52

生存檢查清單 54

譯者有話說 55

第5章　成功的軟件項目知多少 57

5.1　研發階段 57

5.2　項目流程 59

5.3　分階段交付的好處 60

5.4　分階段交付的成本 63

5.5　階段計劃 64

5.6　團隊建設 66

5.7　代碼量增長曲線 69

5.8　主要里程碑和可交付內容 71

生存檢查清單 77

譯者有話說 77

第Ⅱ部分　項目生存準備

第6章　擁抱變化，精準定位 81

6.1　變更控制過程 81

6.2　變更控制的好處 84

6.3　自動修訂控制的好處 85

6.4　常見的變更控制問題 86

6.4.1　如何考慮變更 86

6.4.2　何時考慮變更 87

6.4.3　如何處理小的變更 88

6.4.4　如何進行人員管理 88

6.4.5　哪些工作產品要進行變更控制 89

6.5　致力於變更控制 91

生存檢查清單 92

譯者有話說 93

第7章　初步計劃 95

7.1　項目願景 95

7.1.1　定義要放棄的內容 97

7.1.2　致力於願景 98

7.2　高管授權 98

7.3　項目規模目標 99

7.4　宣傳計劃和進展 101

7.5　宣傳進度指標 102

7.6　風險管理 104

7.6.1　致力於風險管理 105

7.6.2　風險監督員 107

7.6.3　十大風險清單 108

7.6.4　支持風險跟蹤的工具 112

7.6.5　詳細的風險管理計劃 112

7.6.6　匿名風險報告渠道 112

7.7　人員策略 114

7.7.1　人才發展 114

7.7.2　團隊培養 115

7.7.3　新手開發人員：可用與勝任 115

7.7.4　團隊動態 116

7.7.5　員工培養的關鍵問題 117

7.7.6　團隊組織 117

7.7.7　項目團隊的組織結構 118

7.7.8　“老虎隊” 120

7.8　時間統計 121

7.9　軟件開發計劃 125

生存檢查清單：初步計劃 126

譯者有話說 127

第8章　需求開發 129

8.1　需求開發流程概述 130

8.2　確定一組關鍵的最終用戶 131

8.3　採訪最終用戶 132

8.4　構建簡單的用戶界面原型 132

8.4.1　如果條件允許，應使用情節串連故事板 134

8.4.2　不斷修改原型直到最終用戶對軟件感興趣 135

8.4.3　制定用戶界面樣式指南 136

8.4.4　全面擴展原型 136

8.4.5　請記住，原型是要廢棄的 137

8.4.6　將全面擴展的原型作為基準規範 138

8.5　編寫詳細的最終用戶手冊 139

8.6　創建單獨的、沒有用戶界面的需求文檔 141

生存檢查清單：需求開發 141

譯者有話說 143

第9章　質量保證 145

9.1　為什麽質量很重要 145

9.2　質量保證計劃 146

質量保證計劃的組成部分 147

9.6　缺陷跟蹤 149

9.4　技術審查 151

9.4.1　常規審查模式 151

9.4.2　成功審查的要點 152

9.5　系統測試 154

9.6　Beta測試 157

9.7　質量保證計劃涵蓋的工作產品 160

9.8　質量保證的輔助活動 162

9.9　軟件發布標準 162

生存檢查清單 163

譯者有話說 164

第10章　軟件架構 165

10.1　啟動架構階段 166

10.2　好的架構有哪些特徵 167

10.2.1　系統概述 167

10.2.2　概念的完整性 167

10.2.3　子系統和組織 168

10.2.4　表示法 170

10.2.5　適應場景變化與調整策略 171

10.2.6　分析可重用性，決定購買還是自己動手寫 172

10.2.7　常用功能領域的策略 172

10.2.8　需求的可追溯性 174

10.2.9　支持分階段交付計劃 175

10.3　如何判斷架構已完成 175

10.4　軟件架構文檔 176

生存檢查清單 177

譯者有話說 178

第11章　最後準備 179

11.1　項目估算 180

11.1.1　估算過程指南 180

11.1.2　里程碑目標 185

11.1.3　非技術性的估算考慮 186

11.2　分階段交付計劃 187

11.2.1　將項目劃分為階段 188

11.2.2　階段主題 189

11.2.3　與分階段交付相似的計劃 191

11.2.4　發布版本 192

11.2.5　修訂分階段交付計劃 193

11.3　持續進行規劃活動 193

11.3.1　風險管理 194

11.3.2　項目願景 194

11.3.3　決策機構 195

11.3.4　人員 195

11.3.5　更新軟件開發計劃 196

生存檢查清單 196

譯者有話說 197

第Ⅲ部分　階段成功

第12章　階段計劃 201

12.1　為什麽需要制定階段計劃 201

12.2　階段計劃介紹 203

12.2.1　需求更新 204

12.2.2　詳細設計 204

12.2.3　軟件構建 205

12.2.4　產生測試用例 205

12.2.5　用戶文檔更新 206

12.2.6　技術審查 206

12.2.7　修正缺陷 206

12.2.8　技術協調 207

12.2.9　風險管理 207

12.2.10　項目跟蹤 208

12.2.11　集成和發布 208

12.2.12　階段結束總結 209

12.3　微型里程碑 209

12.3.1　創建完整的里程碑列表 211

12.3.2　達到預期質量水平 212

12.3.3　定義微型里程碑 213

12.3.4　小型項目的微型里程碑 213

12.3.5　人員管理的考慮 214

12.3.6　項目如果錯過了微型里程碑，怎麽辦 215

12.4　階段計劃和管理風格 216

生存檢查清單 217

譯者有話說 218

第13章　詳細設計 219

13.1　重新審查架構 219

13.1.1　程序組織 219

13.1.2　分析重用 220

13.1.3　需求的解決方案 220

13.1.4　需求的可追溯性 220

13.1.5　軟件構建計劃 221

13.1.6　修正架構中的缺陷 221

13.1.7　項目需要做多少詳細設計 221

13.2　技術審查 224

13.2.1　檢測功能缺陷 225

13.2.2　檢測需求缺陷 226

13.2.3　缺失需求 226

13.2.4　不需要的功能 227

13.2.5　審查項目目標 228

13.2.6　交叉培訓 229

13.2.7　審查和生產力 230

13.3　詳細設計文檔 230

13.4　項目第一階段的特殊考慮 231

生存檢查清單：詳細設計 232

譯者有話說 234

第14章　軟件構建 235

14.1　源代碼質量 236

14.1.1　編程標準 236

14.1.2　項目目標 238

14.1.3　簡潔 239

14.2　軟件集成流程 239

14.2.1　完成意味著徹底完成 240

14.2.2　為其他開發人員提供穩定的基礎 242

14.2.3　每日構建和冒煙測試 242

14.2.4　第一階段的特殊考慮 245

14.2.5　避免過早開發基礎設施 246

14.3　跟蹤進度 246

14.3.1　收集狀態信息 247

14.3.2　可見性 247

14.3.3　每周項目跟蹤更新 248

14.3.4　與客戶和上層管理人員溝通 249

14.4　控制變更 249

14.5　保持專註 251

14.6　軟件構建是不是只有這些事兒 251

生存檢查清單：軟件構建 253

譯者有話說 254

第15章　系統測試 255

15.1　測試的哲學 255

15.2　系統測試範圍 257

15.3　測試組對每日構建的支持 257

15.4　開發人員對系統測試的支持 258

15.5　QA策略 259

生存檢查清單：系統測試 259

譯者有話說 260

第16章　軟件發布 261

16.1　認真對待發布 261

16.2　何時發布 263

16.2.1　缺陷計數 264

16.2.2　統計每個缺陷的工作量 265

16.2.3　缺陷密度預測 265

16.2.4　缺陷集 267

16.2.5　缺陷播種 268

16.2.6　缺陷建模 270

16.2.7　軟件發布決定 271

16.2.8　缺陷跟蹤和宣傳 272

16.3　發布清單 272

16.4　批準發布簽字 275

生存檢查清單：軟件發布 277

譯者有話說 278

第17章　階段結束 279

17.1　舉行變更委員會大型會議 280

17.2　重新校準估算 280

17.2.1　重新估算生產效率 281

17.2.2　“重新估算”還是“失誤” 283

17.3　根據項目計劃評估績效 284

17.4　項目文件歸檔 285

17.5　更新軟件項目日誌 286

生存檢查清單：階段結束 287

譯者有話說 288

第Ⅳ部分　項目完成

第18章　項目歷史 291

18.1　收集項目數據 291

18.1.1　項目回顧會議 292

18.1.2　項目回顧調查問捲 292

18.2　軟件項目歷史文檔 293

18.3　為未來項目準備項目歷史結論 295

18.4　分發軟件項目歷史副本 296

生存檢查清單：項目歷史 296

譯者有話說 297

第19章　項目生存急救包 299

19.1　NASA成功法則 299

19.1.1　項目取得成功的關鍵 300

19.1.2　絕對不做的事情 302

19.2　其他項目生存資源 303

19.2.1　書籍 304

19.2.2　因特網資源 307

結語 309

參考文獻 310

軟件項目術語表 311