團隊軟件過程

《團隊軟件過程(第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