《團隊軟體過程（第2版）》(簡稱“tspi”)，是美國embry-riddle aeronautical大學為計算機科學系研究生和高年級本科生開設的一門軟體工程課的教科書。這本書系統地論述了如何以開發團隊的形式來進行軟體的開發，並對開發過程作出了具體而詳盡的指導，包括團隊成員之間的協調、進度的管理、質量的控制等令讀者最感興趣的方面。
基本介紹
- 書名：團隊軟體過程
- 作者： (美)Watts S. Humphrey
- 原版名稱： Introduction to the Team Software Process
- 譯者：吳超英 師春澤 汪浩
- ISBN：9787115251893
- 頁數：382
- 出版社：人民郵電出版社
- 出版時間：2011 年6月
- 開本：16開
- 原出版社：Addison-Wesley Professional
- 叢書名：軟體工程經典系列
內容簡介,作譯者介紹,目錄,譯者序,前言,
內容簡介
《團隊軟體過程(第2版)》內容包括四個部分：第一部分——緒論，包括前兩章，是對理論的簡單介紹，介紹了什麼是tspi、tspi的組織結構等內容。第二部分——tspi過程，包括第3章到第10章，則是整個小組研究周期的詳細內容，詳細解釋了小組軟體開發的步驟，並且給出了 tspi完整形式的例子。第三部分——小組角色，包括第11章到第15章，提供了小組成員角色的細緻描述：小組領導者、開發經理、計畫經理、質量/進度監督經理，以及技術支持經理。第四部分——使用tspi，包括第16章到第18章，講述了在使用本書的過程中需要注意的一些原則。
《團隊軟體過程(第2版)》實用性與可讀性較強，適用於軟體開發項目經理、程式設計師和一般編程愛好者在開發軟體時參考，也可作為高等學校計算機軟體工程課程的參考書使用。
作譯者介紹
Watts S.Humphrey 是位知名作者，在軟體開發過程和軟體過程改進方面著有多本影響深遠的圖書：Managing the Software Process(1989)、A Discipline for Software Engineering(1995)、Managing Technical People(1997)。Humphrey曾長期在IBM公司擔任高級軟體開發經理，獲得了大量的軟體開發過程方面的經驗，是卡內基梅隆大學軟體工程研究所的研究員，就軟體質量和軟體過程方面的主題著書立說、提供諮詢，並在世界各地發表這方面的演講。
目錄
《團隊軟體過程(第2版)》
第一部分 緒論
第1章 tspi簡介 2
1.1 tspi是什麼 2
工程小組為何需要過程 3
1.2 tspi原則 3
1.3 tspi的設計 3
1.3.1 在個體軟體過程(psp)的基礎上提供一個簡單的框架 4
1.3.2 在幾個周期內開發產品 4
1.3.3 建立標準的質量和績效度量 5
1.3.4 為團隊和學生提供精確的度量 5
1.3.5 進行角色和團隊評階 5
1.3.6 需要過程規範 5
1.3.7 提供團隊問題的指導 6
1.4 tspi的結構和流程 6
周期性開發策略 6
1.5 tspi過程 7
1.6 本書結構和流程 10
1.7 小結 10
第2章 團隊軟體過程的基本原理 11
.2.1 項目為何失敗 11
處理壓力 12
2.2 常見的團隊問題 12
2.2.1 無效的領導力 12
2.2.2 不能做出妥協安排或不善於合作 13
2.2.3 缺少參與 13
2.2.4 拖拉與缺乏信心 13
2.2.5 質量低劣 13
2.2.6 功能多餘 13
2.2.7 無效的組員互評 14
2.3 團隊是什麼 14
2.3.1 團隊規模 14
2.3.2 具有凝聚力的團隊(jelled team) 14
2.3.3 團隊協作的基本條件 15
2.4 建設高效團隊 15
2.4.1 團隊凝聚力 15
2.4.2 挑戰性的目標 15
2.4.3 反饋 16
2.4.4 共同的工作框架 16
2.5 團隊如何發展 16
團隊如何成為具有凝聚力的團隊 17
2.6 tspi如何建設團隊 17
2.6.1 目標 17
2.6.2 角色 18
2.6.3 計畫 18
2.6.4 溝通 18
2.6.5 外部溝通 19
2.7 小結 19
2.8 參考文獻 19
第二部分 tspi過程
第3章 啟動一個團隊項目 22
3.1 為什麼需要團隊啟動過程 22
3.2 團隊目標 23
3.2.1 設定目標需要考慮的因素 23
3.2.2 設定團隊目標 24
3.2.3 tspi的目標設定 24
3.3 團隊成員目標 25
設定團隊成員目標 25
3.4 角色目標 26
3.4.1 團隊領導目標 26
3.4.2 開發經理目標 26
3.4.3 計畫經理目標 27
3.4.4 質量和過程經理目標 27
3.4.5 支持經理目標 27
3.5 tspi啟動腳本 27
3.5.1 學生信息 31
3.5.2 產品目標 33
3.5.3 團隊分工 33
3.5.4 團隊目標 33
3.5.5 團隊會議與第一次團隊會議 33
3.5.6 數據需求 37
3.5.7 項目開始 38
3.5.8 項目資料庫 38
3.5.9 tspi支持工具 38
3.6 小結 38
第4章 開發策略 39
4.1 計畫先行 39
4.1.1 承諾之前先計畫 39
4.1.2 為本課程制定計畫 40
4.2 策略是什麼 40
4.3 概念設計 41
4.4 風險管理 41
管理風險 42
4.5 復用策略 42
4.6 策略腳本 43
4.6.1 入口準則 45
4.6.2 建立策略評判準則 45
4.6.3 完成概念設計 46
4.6.4 選擇開發策略 46
4.6.5 完成初步規模估算 48
4.6.6 完成初步時間估算 48
4.6.7 評估風險 49
4.6.8 建立策略文檔 49
4.6.9 更新開發策略 49
4.6.10 制定配置管理計畫 49
4.6.11 出口準則 50
4.7 小結 50
第5章 開發計畫 51
5.1 計畫的必要性 51
5.1.1 為什麼制定計畫 51
5.1.2 平衡的計畫 52
5.1.3 對照計畫跟蹤進展 52
5.1.4 詳細計畫 53
5.1.5 處理未計畫任務 54
5.1.6 估算級別 54
5.1.7 實現計畫 55
5.2 tspi計畫過程 56
5.3 tspi支持工具 57
5.4 開發計畫腳本 57
5.4.1 入口準則 60
5.4.2 項目計畫步驟2.1 60
5.4.3 項目計畫步驟2.2 60
5.4.4 項目計畫步驟3.1 63
5.4.5 項目計畫步驟3.2 63
5.4.6 項目計畫步驟4.1 66
5.4.7 項目計畫步驟4.2 66
5.4.8 項目計畫步驟5 67
5.4.9 項目計畫步驟6 72
5.4.10 項目計畫步驟7 72
5.4.11 最後的計畫步驟 73
5.4.12 出口準則 77
5.5 跟蹤工作情況 77
5.5.1 項目跟蹤步驟1 78
5.5.2 項目跟蹤步驟2 78
5.5.3 項目跟蹤步驟3 78
5.5.4 項目跟蹤步驟4 79
5.5.5 項目跟蹤步驟5 79
5.5.6 項目跟蹤步驟6 79
5.5.7 項目跟蹤步驟7 79
5.5.8 項目跟蹤步驟8 79
5.6 質量計畫 80
5.6.1 概要比率 80
5.6.2 零缺陷率(pdf) 81
5.6.3 每頁缺陷數 81
5.6.4 缺陷數/kloc 82
5.6.5 缺陷比率 83
5.6.6 開發時間比率 83
5.6.7 a/fr 83
5.6.8 評審速率和審查速率 84
5.6.9 缺陷注入率 84
5.6.10 缺陷排除率 85
5.6.11 階段收益 86
5.6.12 過程收益 86
5.6.13 處理低質量部件 86
5.6.14 出口準則 87
5.7 小結 87
5.8 參考文獻 87
第6章 定義需求 88
6.1 需求是什麼 88
6.2 為什麼需要需求 89
6.3 需求變更 89
需求提取 90
6.4 軟體需求規格說明書 90
6.4.1 需求可追溯性 91
6.4.2 平衡工作量 92
6.5 tspi需求腳本 92
6.5.1 入口準則 95
6.5.2 要求陳述評審 95
6.5.3 要求陳述澄清 96
6.5.4 需求任務分配 96
6.5.5 需求文檔 96
6.5.6 系統測試計畫 96
6.5.7 需求和系統測試計畫審查 97
6.5.8 需求更新 97
6.5.9 用戶srs評審 97
6.5.10 需求基線 97
6.5.11 出口準則 98
6.6 小結 98
6.7 參考文獻 98
第7章 與團隊一起設計 99
7.1 設計原則 100
7.2 在團隊中設計 100
7.2.1 利用整個團隊 100
7.2.2 設計研究 101
7.2.3 利用所有團隊成員的才智 101
7.3 設計標準 102
7.3.1 設計表達標準 102
7.3.2 用例或psp操作場景 103
7.3.3 狀態機分析 103
7.3.4 產生精確的設計 103
7.4 復用性設計 104
7.4.1 可復用接口標準 104
7.4.2 可復用文檔標準 104
7.4.3 可復用部件質量 105
7.4.4 套用支持 105
7.5 可用性設計 105
7.6 可測試性設計 106
黑盒測試與白盒測試 106
7.7 設計評審和審查 106
審查的其他好處 107
7.8 tspi設計腳本 107
7.8.1 入口準則 110
7.8.2 高層設計 110
7.8.3 設計標準 110
7.8.4 產品總體結構 110
7.8.5 設計任務分配 112
7.8.6 設計規格說明書 113
7.8.7 集成測試計畫 113
7.8.8 設計審查 113
7.8.9 設計更新 113
7.8.10 設計基線 114
7.8.11 出口準則 114
7.9 小結 114
7.10 參考文獻 115
第8章 產品實現 116
8.1 設計完成準則 116
8.1.1 設計級別 116
8.1.2 平行實現 117
8.2 實現標準 117
8.2.1 標準評審 117
8.2.2 編碼標準 118
8.2.3 規模標準 118
8.2.4 度量其他類型產品的規模 119
8.2.5 缺陷標準 119
8.2.6 缺陷預防 120
8.3 實現策略 121
8.3.1 實現策略：評審 121
8.3.2 實現策略：復用 122
8.3.3 實現策略：測試 122
8.4 評審和審查 122
8.4.1 隨機缺陷 122
8.4.2 對測試的影響 123
8.4.3 完全測試的困難 123
8.4.4 源程式的設計審查 123
8.5 imp腳本 124
8.5.1 入口準則 127
8.5.2 實現計畫 127
8.5.3 詳細設計與設計評審 127
8.5.4 測試開發 128
8.5.5 詳細設計審查 128
8.5.6 編碼及代碼評審 128
8.5.7 代碼審查 129
8.5.8 單元測試 129
8.5.9 組件質量評審 129
8.5.10 組件發布 133
8.5.11 出口準則 133
8.6 小結 133
8.7 參考文獻 134
第9章 集成與系統測試 135
9.1 測試原則 135
9.2 tspi測試策略 136
9.3 構建和集成策略 137
9.3.1 大爆炸策略 137
9.3.2 一次一個策略 137
9.3.3 測試群策略 137
9.3.4 扁平系統策略 138
9.4 系統測試策略 138
可選系統測試策略 138
9.5 測試計畫 139
9.6 跟蹤與度量測試 140
9.6.1 測試日誌 140
9.6.2 缺陷易發模組 141
9.6.3 模組缺陷數據 142
9.6.4 跟蹤缺陷數據 142
9.7 文檔 143
9.7.1 文檔的重要性 143
9.7.2 文檔設計 143
9.7.3 文檔提綱 144
9.7.4 書寫風格 144
9.7.5 文檔評審 145
9.8 tspi測試腳本 145
9.8.1 入口準則 149
9.8.2 測試開發 149
9.8.3 構建 149
9.8.4 集成 150
9.8.5 系統測試 150
9.8.6 回歸測試 151
9.8.7 文檔 151
9.8.8 出口準則 151
9.9 小結 151
9.10 參考文獻 152
第10章 結項總結 153
10.1 為什麼要進行結項總結 153
10.2 結項總結能為你做什麼 153
10.3 過程改進建議 154
10.4 tspi結項總結腳本 154
10.4.1 入口準則 157
10.4.2 評審過程數據 157
10.4.3 質量評審 158
10.4.4 角色評估 158
10.4.5 準備周期報告 159
10.4.6 周期報告 159
10.4.7 角色報告 159
10.4.8 工程師個人報告 160
10.4.9 撰寫報告 160
10.4.10 角色評估 160
10.4.11 角色評估建議 162
10.4.12 出口準則 162
10.5 小結 163
10.6 參考文獻 163
第三部分 團隊角色
第11章 團隊領導角色 167
11.1 團隊領導的目標 167
11.1.1 團隊成員的共同目標 167
11.1.2 團隊領導的目標1 168
11.1.3 團隊領導的目標2 168
11.1.4 團隊領導的目標3 168
11.1.5 團隊領導的目標4 169
11.1.6 團隊領導的目標5 169
11.2 有用的團隊領導的技能和能力 169
11.2.1 有擁護者的領導 170
11.2.2 領導需要表現 170
11.2.3 領導需要面對困境 172
11.2.4 領導處理人際關係 172
11.3 團隊領導的主要活動 172
11.3.1 團隊領導的主要活動1 173
11.3.2 團隊領導的主要活動2 176
11.3.3 團隊領導的主要活動3 176
11.3.4 團隊領導的主要活動4 176
11.3.5 團隊領導的主要活動5 177
11.3.6 團隊領導的主要活動6 178
11.3.7 團隊領導的主要活動7 181
11.3.8 團隊領導的主要活動8 181
11.4 團隊領導的項目工作 181
11.5 小結 181
第12章 開發經理角色 183
12.1 開發經理的目標 183
12.1.1 團隊成員的共同目標 184
12.1.2 開發經理的目標1 184
12.1.3 開發經理的目標2 184
12.2 對開發經理有益的技能和能力 185
12.3 開發經理的主要活動 187
12.3.1 開發經理的主要活動1 187
12.3.2 開發經理的主要活動2 188
12.3.3 開發經理的主要活動3 188
12.3.4 開發經理的主要活動4 189
12.3.5 開發經理的主要活動5 189
12.3.6 開發經理的主要活動6 190
12.3.7 開發經理的主要活動7 191
12.3.8 開發經理的主要活動8 191
12.3.9 開發經理的主要活動9 193
12.3.10 開發經理的主要活動10 194
12.3.11 開發經理的主要活動11 194
12.4 開發經理的項目活動 194
12.5 小結 194
第13章 計畫經理角色 196
13.1 計畫經理的目標 196
13.1.1 團隊成員的共同目標 196
13.1.2 計畫經理的目標1 197
13.1.3 計畫經理的目標2 197
13.2 對計畫經理有益的技能和能力 198
13.3 計畫經理的主要活動 198
13.3.1 計畫經理的主要活動1 199
13.3.2 計畫經理的主要活動2 201
13.3.3 計畫經理的主要活動3 201
13.3.4 計畫經理的主要活動4 204
13.3.5 計畫經理的主要活動5 207
13.3.6 計畫經理的主要活動6 208
13.4 計畫經理的項目活動 208
13.5 小結 208
第14章 質量和過程經理角色 209
14.1 質量和過程經理的目標 209
14.1.1 團隊成員的共同目標 209
14.1.2 質量和過程經理的目標1 210
14.1.3 質量和過程經理的目標2 210
14.1.4 質量和過程經理的目標3 211
14.1.5 質量和過程經理的目標4 212
14.2 對質量和過程經理有益的技能和能力 212
14.3 質量和過程經理的主要活動 213
14.3.1 質量和過程經理的主要活動1 214
14.3.2 質量和過程經理的主要活動2 214
14.3.3 質量和過程經理的主要活動3 214
14.3.4 質量和過程經理的主要活動4 215
14.3.5 質量和過程經理主要活動5 215
14.3.6 質量和過程經理的主要活動6 216
14.3.7 質量和過程經理的主要活動7 218
14.3.8 質量和過程經理的主要活動8 218
14.3.9 質量和過程經理的主要活動9 218
14.4 質量和過程經理的項目活動 219
14.5 小結 220
第15章 支持經理角色 221
15.1 支持經理的目標 221
15.1.1 團隊成員的共同目標 221
15.1.2 支持經理的目標1 222
15.1.3 支持經理的目標2 222
15.1.4 支持經理的目標3 222
15.1.5 支持經理的目標4 223
15.2 對支持經理有益的技能和能力 223
15.3 支持經理的主要活動 223
15.3.1 支持經理的主要活動1 223
15.3.2 支持經理的主要活動2 224
15.3.3 支持經理的主要活動3 224
15.3.4 支持經理的主要活動4 225
15.3.5 支持經理的主要活動5 225
15.3.6 支持經理的主要活動6 226
15.3.7 支持經理的主要活動7 227
15.3.8 支持經理的主要活動8 227
15.4 支持經理的項目活動 227
15.5 小結 229
第四部分 使用tspi
第16章 管理自我 232
16.1 責任心 232
16.1.1 一個失敗的項目 232
16.1.2 履行責任 233
16.1.3 決不放棄 233
16.1.4 面對現實 234
16.1.5 負責任所帶來的風險 234
16.1.6 陳述事實 234
16.1.7 事實往往是可以爭議的 235
16.2 目標導向性 235
16.2.1 著眼於日程表 235
16.2.2 目標提供了工作重點和優先權 236
16.2.3 你想讓我做什麼？ 236
16.3 原則性 237
16.3.1 不與團隊中其他人合作 237
16.3.2 如何遵循處事的幾個原則 237
16.4 小結 240
16.5 參考文獻 240
第17章 在團隊中工作 241
17.1 具有凝聚力的團隊 241
17.2 團隊工作的責任 242
17.3 團隊成員間的溝通 242
17.3.1 可見性 242
17.3.2 聆聽 242
17.3.3 協商 243
17.3.4 為什麼有原則的協商是有效的 244
17.3.5 花費足夠的時間 245
17.4 作出和履行承諾 245
17.4.1 負責的承諾 245
17.4.2 做出承諾 246
17.5 參與團隊活動 246
17.5.1 勇於發表自己的看法 246
17.5.2 支持堅持己見的人 247
17.5.3 喚起別人的注意 247
17.5.4 對他人的意見要給予關注 247
17.6 團隊建設的責任 248
17.7 接受並承擔團隊所分配的角色 248
17.8 建立並努力完成團隊目標 249
17.9 建立和維護團隊 249
17.9.1 難以相處的團隊成員 250
17.9.2 院校團隊的問題 250
17.9.3 尋求幫助 251
17.9.4 支持 251
17.10 小結 251
17.11 參考文獻 252
第18章 團隊工作 253
附錄a tspi採樣練習的要求說明 256
a.1 目的 256
a.2 “變化計數器”功能要求說明 256
a.3 “程式分析器”功能要求說明 259
a.4 參考文獻 260
附錄b 軟體配置管理 261
b.1 軟體配置管理問題 261
b.2 軟體配置管理概要 262
不需要的項 262
b.3 scm計畫 262
b.3.1 配置標識計畫 262
b.3.2 配置控制規程 263
b.3.3 配置控制委員會 263
b.3.4 變更申請表 263
b.4 系統基線 265
b.4.1 基線提交 265
b.4.2 備份規程 266
b.4.3 配置狀態報告 266
b.5 scm過程自動化 267
b.6 軟體配置管理過程 267
b.6.1 第一步：制定scm計畫 269
b.6.2 第二步：管理系統基線 269
b.6.3 第三步：管理變更 270
b.6.4 第四步：報告scm狀態 271
附錄c 軟體審查 272
c.1 什麼是審查 272
c.1.1 審查是如何進行的 272
c.1.2 評審的時機 272
c.1.3 使用規定的審查程式 273
c.2 什麼使審查有效 273
c.2.1 審查整個程式 273
c.2.2 集思廣益 273
c.2.3 採取不同的視角 273
c.2.4 提供發現錯誤的機會 274
c.2.5 全面測試的重要性 274
c.2.6 只審查經個人評審過的產品 274
c.3 審查方法 274
c.3.1 檢查單 275
c.3.2 視角 275
c.3.3 產品側重點 275
c.3.4 審查實踐 276
c.4 審查數據 276
c.4.1 審查速率 276
c.4.2 評審占開發比率 276
c.4.3 審查收益 277
c.5 審查報告：ins表 277
c.6 估算遺留的缺陷數 280
c.6.1 估算總數 280
c.6.2 估算程式中的缺陷數 280
c.6.3 軟體審查中的捕獲-重捕獲方法 280
c.6.4 2個工程師的估算範例 281
c.6.5 3個工程師的估算範例 282
c.6.6 注意 284
c.6.7 一些改進 284
c.7 具有高個人審查收益的重要性 285
c.8 安排審查時間 285
c.9 tspi審查腳本 286
c.9.1 入口準則 287
c.9.2 計畫審查工作 287
c.9.3 召開審查介紹會 288
c.9.4 評審產品 288
c.9.5 召開審查會議 288
c.9.6 遍歷產品 288
c.9.7 估算遺留缺陷數 289
c.9.8 總結審查會議 289
c.9.9 修改產品，驗證缺陷修復 289
c.9.10 出口準則 289
c.10 參考文獻 290
附錄d tspi腳本 291
附錄e 角色腳本 319
附錄f tspi表格及其使用說明 333
附錄g tspi標準與規格說明 379
譯者序
人民郵電出版社邀請我們重新翻譯《團隊軟體過程》 (Introduction to the TeamSoftware Process)這本書，我們欣然答應了。該書面向軟體工程師和團隊管理者而寫，將軟體工程與管理方法很好地融合在一起，具有很強的實踐指導意義。該書集成了軟體工程、估算、計畫與跟蹤、質量管理和自我指導團隊的概念，使之更容易結合一個組織機構內的現有實踐。TSP適合大多數業務開發和技術，可以在小周期、螺旋增量式周期或者在瀑布模型中疊代實施，敏捷而有規範地管理，正是適合當前的開發模式，也更適應小型軟體組織機構開發管理的特點。雖然這本書出版了很多年，但是書中的精髓還沒有真正為人們理解和掌握。如今TSP在世界範圍越來越廣泛地被採用，CMU/SEI每年都舉辦TSP研討會，提供一個交流TSP實踐方法和概念的場所。2010年年會的主題為“改變軟體工程的世界”，不得不使我們要加倍關注它在當今軟體工程和管理上的價值。
軟體開發是一個極具有挑戰性的工作。每個項目都可能面臨不斷變更的需求，進度永遠是緊迫的，資源也總是短缺的。在其他行業，工程師是個令人羨慕的職業。而對軟體業來講，大部分的工程師大都以一個受害者的形象在行業中出現，他們陷入困境不能自拔。該書的作者Watts Humphrey說軟體工程師要想擺脫這個局面，需要做到四件事：第一，具有正確的態度；第二，適當的技能；第三，要有改進的勇氣；第四，富有可信度。TSP/PSP幫助軟體工程師做到了。
本書主要是針對開發軟體密集型產品的工程團隊而寫的指導書。使用團隊軟體過程幫助軟體工程師、項目經理和組織機構建立一個成熟和有規範的工程實踐，在最短的時間和較低成本條件下生產出安全、可靠的軟體。本書對經過Personal Software Process (PSP，個體軟體過程)培訓後的工程師和學生特別有用，它介紹了TSP和具體的改進軟體團隊工作需要的具體步驟。TSP不但提高團隊績效，同時也能提高工程師的個人績效。TSP已經在世界近百家企業採用，如IBM、微軟、oracle、Adobe等。據2008年的統計，特別是微軟，已經投資大約300萬美元在IT公司引進TSP，已經培訓了上千名PSP開發人員，超過200個TSP項目。由於微軟已經在質量和進度預測方面得到了改善，預計TSP已經為它們節省8400萬美元。墨西哥政府自2000年開始，出資支持企業實施TSP。同時TSP是對CMMI模型的補充，提供了最優實踐和操作實例來指導團隊獲得更優的性能績效。它可以加速實施CMMI各個等級，特別是高成熟度等級，是高性能實施過程改進的最佳途徑。TSP已經套用在各種領域的小型和大型組織機構，都取得了相似的結果。例如在企業生產力方面提升了25%，甚至更多；減少成本和進度偏差55+/—10%以下；測試成本和進度減少超過80%。
Watts Humphrey曾經說過，軟體是大量的知識智力工作，當人們不理解他們正在做的事的話就很難去管理這些人。自1986年，他將全部精力獻身於軟體工程領域，努力通過實踐有效的管理原則來改變軟體軟體工程的世界。他創造了個體軟體過程(PersonalSoftware Process，PSP)，來幫助軟體工程師通過使用有規範的、數據驅動的方式進行自我管理他們的項目。Humphrey獲得了舉世矚目的成就，終於在2005年榮獲美國總統頒發的國家技術獎章。
我們將這本書再版翻譯出來，推薦給讀者，目的是提供更具體詳細的關於小組軟體過程的方法和實踐，期望將這些方法運用到你的組織機構中，對軟體開發和改進產生深刻的影響。本書內容豐富，通俗易懂，實用性強，可作為大學、研究生計算機專業教材，更適合企業中的軟體開發團隊作為實訓和培訓的指導教材。
在我國，已有一些企業在實施CMMI前或過程中，將PSP和TSP作為建立實踐基礎的必要階梯。PSP和TSP的引入和推廣，已經成為培養優秀軟體工程師的搖籃。
從國內整體來看，軟體工程師的從業專業水準還沒有與國際接軌，積極推廣PSP和TSP是解決軟體開發人才短缺、縮短培養周期的主要途徑之一，也是為持續過程改進，提高生產率、軟體質量和縮短開發工期的長遠之計。
在這本書的翻譯過程中，從SEI傳來了一個不幸的訊息，Watts Humphrey於2010年10月28日與世長辭了，我們為失去這位偉大的行業領袖而遺憾，這個譯文也是為了紀念他，希望他的遺產能為中國軟體產業的發展和改進造福。
最後，由於我們的水平有限，在本書的翻譯中難免有錯誤或不妥之處，懇請讀者批評指正。
吳超英 師春澤 汪浩
2011年3月
前言
這本書是為已經學習並使用過個體軟體過程(PSP)的學生和工程師準備的。你可能在研究生課程、高級培訓課程或者初級導論課程中學過PSP。或者，你可能是工程師，正在探索如何在實際的團隊工作環境中套用PSP。不論是哪種情況，只要你學過PSP，你就具備了使用本書中的方法和實踐的基礎。
學習過PSP之後，你可能需要指導，以便弄清如何將它套用於軟體過程的諸多任務上。這就是團隊軟體過程(TSP)的主旨：為在軟體開發領域中套用成熟的工程學方法提供一個框架。
關於團隊協作有很多東西可講，本書只涵蓋了最基本的內容。TSPi(團隊軟體過程導論)介紹了團隊的概念，組建團隊的基本步驟，以及在團隊中工作的方法。但是要注意，本書是為導論課程設計的，並沒有涵蓋在大規模工業項目中使用TSP的全部資料。
TSPi是如何幫助工程師的
本書向工程師介紹有關軟體開發團隊協作的內容。TSPi提供了一系列結構化的步驟，告訴工程師每一步該做什麼，並且詳細闡述了如何將這些步驟連線起來以開發完整的產品。TSPi還提供了兩個饒有趣味且相對具有挑戰性的項目練習，每個練習都具有適當的規模。既不過大，以保證在幾周之內可以完成：也不過小，以保證可以模擬典型的小規模項目。如果有能力的工程師遵循本書的指導，那么他們一定能開發出完整的工作產品。
在本書建議的TSPi策略中，團隊在兩到三個周期內開發一個產品。在第一個周期內，團隊構建工作產品核心。在後續的每個周期內，逐漸向核心加入新功能。這種策略體現了使用歷史項目數據來制定新項目計畫的好處。另外，由於在每個周期中都有新的角色，工程師們可以在一個項目中就經歷兩到三種不同類型的工作。經過幾個開發周期後，工程師們就會對團隊協作方法有一個廣泛的了解，這樣一來，他們就更有可能在自己將來的工作中繼續使用TSPi方法。
為何要學習TSPi課程
經實踐證明，在培養軟體工程專業的學生方面，項目課程是行之有效的，因此，越來越多的大學開始開設相關課程。這些課程很受學生歡迎，修習人數一般都會超過預期。學生想學習可套用於將來工作的知識，而團隊訓練課程正好滿足了他們的需要。畢業後的學生及其僱主普遍反映，軟體項目課程為實際工作打下了良好的基礎。
現在，在團隊項目課程方面，已經有很多有益的實踐。儘管大多數此類課程都是成功的，但普遍有三個問題：第一，學生經常去嘗試過大的項目；第二，他們大多只強調產品而忽略了過程；第三，總有一些成員會破壞團隊氣氛。雖然TSPi不能完全避免這些問題，但它提供了有關避免這些問題或減少這些問題影響的有益指導。
為了高效利用課程時間，團隊軟體課程應該精心組織，並且要基於經實踐證明的項目經驗。如果沒有明確定義的過程或結構化的團隊框架，工程師就必須自己決定該如何完成項目。如果沒有過程和框架，工作組就必須自己學習團隊建設和團隊協作的基本要素，而這一過程通常都會伴隨著痛苦的嘗試和失敗。顯然，這樣做代價高昂並且沒有必要，因為團隊協作的原則通常眾所周知、簡單明了。
TSPi以行之有效的團隊協作方法訓練工程師，首先幫助他們熟悉團隊建設的過程，然後指導他們使用經過明確定義和度量的框架來開發產品。在經過PSP訓練的前提下，工程師一般都能遵循TSPi腳本步驟，並使用TSPi支持工具來計畫和管理自己的工作。遵循TSPi的指導，項目工作會變得更有效率，工程師也可以更加專注於學習軟體工程，而不是在團隊建設和團隊管理方面花費大量的時間。
TSPi明確定義了團隊角色，每個團隊成員都要以某種角色進行工作。每個角色都有詳細說明，指出這個角色應該做什麼，何時以及如何去完成任務。在每個團隊成員都知道他們自己和其他人應該做什麼的情況下，他們就能更好地作為一個團隊高效工作。如果一個團隊成員沒有完成工作，其他團隊成員就會知道相關情況，從而及時地採取措施處理相關問題。如果團隊不能獨立解決人際關係問題，他們可以求助於教師或管理人員。本書的教師手冊給出了處理很多常見的團隊協作問題的有效方法。
如果學生團隊成員擔任明確的角色和職責，並使大家都了解，教師就能給出更加公平和詳細的成績。除了給整個團隊打分，還可以給每個人的表現打分。這不僅激勵學生表現得更好，同時也是一種更公平的給團隊訓練課程打分的方式。
本書組織結構
本書是為引導團隊學習TSPi過程而設計的。前兩章(第一部分)是簡介，第二部分闡述了完整的團隊開發周期。書中詳細解釋了過程腳本，並且給出了TSPi表格的完整示例。
第三部分給出了TSPi團隊成員角色的詳細說明：團隊領導、開發經理、計畫經理、質量和過程經理，以及支持經理。當閱讀有關每個角色的章節後，你可以將TSPi角色腳本作為工作參考。
TSPi課程伊始，每個學生都要填寫一個INFO表格(見附錄F)，這個表格記錄了有關學生興趣和背景的信息。教師根據這些信息將整個班級劃分為5人小組，再給每個小組成員分配初始角色。如果個別小組有4或6個人，教師就必須對角色進行適當調整。每個角色都要有人擔任，每個工程師必須擔任至少一個角色。對於一個4人的小組，支持經理角色的任務要在所有小組成員間分攤。對於一個6人小組，質量和過程經理角色要分割為兩個角色：質量經理和過程經理。
選擇團隊成員並進行角色分配之後，各個團隊就啟動各自的項目，並定期匯報項目進展。每個開發周期結束時，工程師要評估團隊的整體表現和每個角色的個人表現。基於這些信息，教師就能評估每個團隊和每個人的工作，並且在後續的開發周期中更好地分配角色。如果有必要，教師可以對團隊的人員組成進行調整，但是，除非出現了嚴重問題，否則團隊的人員組成應該在整個課程中保持穩定。
使用標準及預定義的問題
儘管TSPi可以套用於各類項目，但本書只提供了兩個標準和預定義的問題，它們是為滿足課程多樣性的要求而專門設計的。雖然使用真實的客戶需求也有好處，但是，因為以下三個原因，我們不推薦這樣做。第一，課程有嚴格的進度要求。雖然多數客戶一開始都同意按照固定的時間表推進項目，但是很少有客戶真正知道開發軟體需要多長時間。另外，因為入門工程師一般不知道如何按照嚴格的進度來管理項目，所以項目失敗的幾率是很高的。這個問題的根源在於，實際的客戶需求大多既不夠清晰也不穩定，導致頻繁變更和大量延期。
. 第二，團隊協作課程應該為特定主題而設計。雖然開發工作產品是項目的目標之一，但是本課程的主要目的是展示使用成熟的軟體工程方法的好處。對於真實的客戶需求，滿足客戶要求永遠都是最高優先權。一旦需求變更或客戶插進來回答問題，工作就會延期，進度就會壓縮，導致團隊經常把精力集中在完成產品上，而忽略了過程。從結果來看，事與願違，我們從這類課程中得到的主要經驗就是如何避免開發軟體。
第三，使用標準及預定義的問題，有助於比較各團隊的表現。同樣的需求有不同的實現方式，所有的團隊都可以加入課程評價。每個團隊都可以介紹自己的方案，解釋有關設計、實現和測試的問題。這個過程能夠充分體現出各種開發方案的實際效果，同時也為評價將來的團隊提供了參考數據。
雖然使用預定義的標準練習具有很多好處，但是這也讓學生沒有機會接觸某些重要問題。例如，如果沒有實際經驗，就很難察覺用戶需求描述的混亂和模糊。應付模糊和多變的需求是一種重要的經歷，但是這可以在專門講授需求過程的課程中進行詳細學習。本書採取這種方案，首先是要講授高效的團隊協作和過程方法，然後，在後續課程中集中研究大規模開發項目中的複雜問題。
給教師的建議
本書可以多種方式使用。最主要的用法就是作為一學期或兩學期的團隊訓練課程的教材。這種情況下，TSPi可用來開發一個單獨的產品，例如附錄A中介紹的兩個產品之一。一學期的課程大概有2—3個周期，而兩學期的課程大概有3個或者更多的周期，以開發更大規模的產品或者附錄A中產品的完整版本。過程步驟可根據項目工作的規模進行適當增加和減少。表P1、P2、P3給出了3種課程方案。
在表P1所示的每個開發周期內，團隊計畫並跟蹤每一步工作，最終完成一個完整的小型項目，包括需求、設計、編碼和測試。在每個開發周期結束時，團隊評估整個團隊和每個角色的表現，之後，教師重新分配團隊角色。在一個包含3個開發周期的項目中，工程師們實質上獲得了3個完整項目和3種不同團隊角色的經驗。同時，他們也得到了每個開發周期的數據，在每個開發周期中，他們都可以學習如何使用從前面的開發周期中獲得的經驗。
本書還可在其他課程中作為團隊協作練習來使用。小型項目可以在3～7周的單個開發周期中完成，例如，簡單的需求開發周期大概需要3～4周，設計開發周期大概需要四周或五周，而最短的完整開發項目可能需要6周或7周。表P2展示了一個時間跨度為幾周的，開發一系列需求的團隊項目。類似地，表P3展示了一個設計項目。本書還可用於半個學期的課程教學，這樣一來，完整的3個周期的課程需要15周，兩個周期的課程需要11周，單個周期的開發項目只需要7周。
不管採用哪種課程方案，標準TSPi腳本都將指導學生成立團隊、計畫並實施項目。除非團隊已經有過TSPi課程經歷，否則任何團隊都不太可能在少於3周或4周的時間內完成任何一個項目周期。原因在於，新的團隊成員需要時間去學習團隊過程，還要學會如何作為一個團隊一起工作。這也是第一個TSPi周期需要7周時間，而後續周期只需要4周時間的原因所在。
學習本課程的基礎
本課程的主要先修課是PSP課程，無論在研究生課程中或在PSP導論課程學習過都可以。如果學生是在幾個學期以前學習的PSP，則要求他們在最近的課程中使用過PSP，否則，他們就需要一到兩節課來回顧一下PSP計畫、數據收集和質量管理的相關知識。如果學生使用PSP的經驗不足或者根本沒有用過PSP，那么就需要在整個課程期間對他們進行仔細的指導和幫助。
在嘗試團隊項目以前，學生應該具有軟體設計和軟體需求的知識背景，配置管理、項目管理和軟體測試的相關知識和經驗也會很有幫助。另外，學生還必須熟練掌握一門程式語言，熟練使用編程工具。
Watts S.Humphrey
Sarasota,Florida
