《软件工艺》向我们展现了另一种选择——关注“从事商用软件开发的人”的工艺学模型。本书告诉读者：技术人员迫切需要转变观念，技术不仅仅是技术本身，更应该是为客户提供价值的基础。如何培养程序员对技术的精通？如何发展小型开发团队中创造性的协作？如何加强与客户的的沟通？本书作者给了我们一种方法，它将造就技艺精湛的开发者，他们能创造坚固耐用的应用程序，并不断扩展、升级它们。

本书针对软件开发，提出了一些相当棘手和敏感的问题，并给出了颇具争议性的结论：从一个数百年来一直兴旺发达的系统——工艺学中获得启示，寻找答案。

本书用5个部分共19章的篇幅，系统地阐述作者的观点，并试图回答一直困扰着软件行业的难题——我们应该如何重组软件构造的过程，使其能够如我们所愿地有效运转？第1部分共4章，对传统的观点提出质疑——软件工程真的是解决软件开发问题的灵丹妙药吗？第2部分共2章，这一部分提出了本书的观点，即以软件工艺的视角看待软件开发。第3部分以7章的篇幅，从不同的角度全面地展现了软件工艺理论所带来的主要变化，以及如何实践这个观念。第4部分共3章，对比了软件工艺与软件工程，并为各自适用的范畴重新划定了界限。第5部分共3章，分别讨论软件开发中的权宜之计和长期问题。

本书荣获2002年度Jolt图书大奖。阅读本书，有助于引发读者在软件开发问题上的独立思考，本书适合软件行业的所有从业人员阅读参考。

第一部分 置疑软件工程

第1章 理解软件工程/3

软件工程的悖论/4

等待硬件开发时，软件开发者在干什么？/5

得到可用的硬件之后，软件开发者如何

加快交付的速度？/5

传统开发过程的内蕴/6

软件工程的当代解读/7

“足够好”的软件—庶民的软件工程/9

软件工程适合你的项目吗？/10

第2章 软件工程的困境/11

“有组织的、可计量的”软件开发过程现实吗？/14

我们当然可以将软件开发中的某些部分

自动化，不是吗？/16

“足够好”的软件开发方法的危害/17

谁能取代软件工程？/19

第3章 理解软件开发/21

软件资产/23

软件开发需要团队协作/25

软件开发的分工有用吗？/26

没有一劳永逸/27

寻找比“软件工程”更合用的隐喻/30

第4章 寻找一个比软件工程更好的隐喻/33

软件开发的工艺/35

与传统工艺学的比较/37

软件开发工艺的复兴/38

第二部分 软件工艺

第5章 重拾软件开发/45

工艺学致力于改善软件开发的现状/46

工艺学鼓励开发者编写优秀的软件/47

吹响号角/48

第6章 无须执照的工艺学/51

工艺是私人性的/51

同行认可和推荐是获得更好软件的办法/52

执照只是假象/53

执照是在向风车开战/55

工艺学关注个人/57

软件开发者不是太少，而是太多/57

第三部分 软件工艺隐含的意味

第7章 工艺学对系统的用户有何影响/65

软件容易拷贝，所以软件工艺能够有效/66

批量市场的难题/67

工匠与用户有一种不同的关系/69

但是，请记住：购买者很可能不是

使用者/70

优秀的软件应该签上开发者的名字/71

为作品签名会使情况发生变化/72

工匠应当对作品负责/72

工匠需要挑剔的用户/73

更小、更坚固的软件更有利于用户/73

软件工艺带来协作式开发/74

第8章 顾客与工匠的关系/75

给我一个真实的交付日期/75

揭穿“足够好的软件”的谬论/76

另一种选择/78

不要只考虑出价最低的开发者/79

差劲的客户将很难吸引优秀的开发者/80

让软件工匠因为自己的作品而获得荣誉/80

要求开发者对作品负责/81

利用开发者之间的差异/81

雇佣优秀开发者组成的小团队/82

优秀的开发者究竟值多少？/83

但我们如何知道开发者有多优秀呢？/84

根据交付的成果来衡量开发者的水平/85

在选择工匠时，客户在成本和质量之间作出权衡/87

软件工匠的专业分工/88

客户与软件工匠有长期的联系/90

维护者是一个荣耀的身份/90

软件工艺有益于长期使用的软件/92

客户与软件工匠志趣相投/92

第9章 工匠的管理/95

软件工匠不是雇工/96

好的开发者比管理者更有价值/96

软件开发的实际过程无法详细定义/97

软件工匠与管理者的关系/98

以管理优秀的开发者为乐为荣/98

优秀的管理者理解项目的节奏/99

软件工匠喜欢创造软件/100

软件开发的根本从来没有改变过/100

家有一老，如有一宝/101

软件工艺要求全新的管理方式/103

软件工艺不是“有计划报废”/103

软件工匠坚持自己的要求/104

第10章 成为软件工匠/107

软件工艺拒绝精细的分工/107

过度的专业化会延误开发、导致错误/108

软件工匠建造能够理解的系统/109

工艺学需要献身精神/109

如何成为软件工匠？/110

学徒是比学校教育更有效的学习方式/111

技师是工艺学传统的关键/111

工艺学传统已经延续多年/112

第11章 工艺的掌握/115

软件工艺大师是什么样子？/116

善用你的老员工/116

“掌握技艺”意味着使用稳定的技术/117

软件工匠不会仅仅因为工具“最新最好”

而使用它/118

软件工程对COBOL的谋杀/119

技艺需要花时间去掌握/120

“掌握”意味着承担起传递工艺的责任/121

工匠挑选学徒和技师/122

第12章 学徒开发者/123

我们必须扭转开发者培训质量下滑的局面/123

大学文凭与项目开发无关/125

会编程不等于会开发软件/125

如果必须送初学者去培训，选择好的

培训课程/127

工艺的掌握，学徒比培训更有效/127

成为学徒是重要的一步/128

为了降低对工作的影响，工匠慎选

学徒/128

重要的是学，不是教/129

学徒不是学校/129

活到老学到老/130

学徒审查师傅的作品，并从中学习/131

学徒的角色/132

从低风险的任务开始/133

晋升到产品开发/133

因为能力而晋升/134

学徒不是廉价劳动力/134

学徒期是时间和精力的投资/136

学徒如何成为技师/137

第13章 技师开发者/139

技师在工艺学传统中的位置/140

技师开发者/140

技师很少单独工作/141

技师关注应用程序的交付/141

技师在软件工艺中扮演关键角色/143

第四部分 重新定位软件工程

第14章 软件工程项目/149

软件工程的目标是大型系统项目/150

软件工程需要专业分工/151

软件工程项目依旧使用瀑布过程/151

编程是一项刻板的工作/152

软件开发不是软件工程项目的瓶颈/152

形形色色的软件工程项目/153

敏捷方法代替缜密的软件工程/154

第15章 “软件工程”隐喻的危害/155

无法以低成本实施软件工程/155

鱼与熊掌可以兼得？/156

相信估算软件工程项目的确需要

很长的时间/156

软件工程鼓励“科学管理”/157

软件工程轻视不精确的讨论/159

软件工厂：软件的生产线/160

跨项目复用极难实现/161

冒险的“长时间复用”/162

“标准软件开发过程”的迷思/164

传统的分工无助于软件开发/165

“最佳实践”是“科学管理”的遗毒/166

最佳实践使人墨守成规/166

最佳实践阻碍了过程革新/167

软件工程强迫我们忽视个人/168

软件开发者不是可替换的资源/169

伪造一个“理想的开发过程”/169

开发过程，不嫌其多/170

抛弃软件工程的瀑布式过程/171

瀑布方法需要大型团队来实施/172

小型团队绝不要尝试软件工程/173

第16章 学习软件工程的经验/175

尺度和复杂度/175

做软件，不容易/176

应用程序需要良好的结构/177

变化的代价很高——如果你不允许变化的话/178

交流至关重要/179

文档总是错的/180

用增量式开发来控制风险/180

精确的估算很难得到/181

借用这些经验/183

第五部分 星期一的早上

第17章 经验——项目成功的指示灯/189

根据声望选择软件工匠/189

信任工匠的推荐/190

最后，开始大范围搜索/191

根据声望和作品来评价工匠/191

考察工匠的作品/192

工匠的试演/193

由软件工匠来组建开发团队/194

根据个人了解和推荐挑选团队成员/194

年富力强的开发团队/195

为低预算团队担心/196

通力协作/196

使用增量式开发/197

尽早解决问题/198

任何人都能学会协作式开发/198

回避极端技术/199

经验的价值/200

他们去年在哪里？/201

奖励优秀开发者/201

想要人才，就得付高薪/202

我们付得起那么多钱吗？/203

做好吃惊的准备/204

第18章 为测试和维护而设计/207

是软件应用，不是软件项目/208

应用程序只会退休，不会结束/208

维护团队理应拒绝丑陋的软件/209

可维护软件需要有自动测试/209

使应用程序能够被测试/210

为维护而设计/211

创建可维护软件需要经验丰富的

开发者/212

可维护软件能够生存多年/213

长寿的应用程序需要长寿的开发工具/213

开放源码，软件工艺的最爱/214

Java对项目的健康有害/214

可维护软件需要稳定的基础设施/215

优秀的软件是全球性的/216

保证软件的全球性/217

拒绝“有计划报废”/218

优秀的软件需要优秀的用户界面/218

能够安全使用的软件/219

可维护软件易于诊断/220

外包的危害/221

外包忽视了软件开发的本质/222

在外包中坚持软件工艺/223

借助外来的工匠/224

维护是软件生命中最重要的部分/224

提高维护者的地位/225

维护者当受赏/226

并非所有软件都必须可维护/226

“为测试和维护设计”不能一蹴而就/227

第19章 活到老，学到老/229

创造学习的环境/229

用内部研讨创造学习环境/230

邀请所有人参加讲座/231

学习时间是一种投资/231

掌握软件开发的技艺/231

鼓励参加用户组和技术会议/233

慎选培训课程/234

课前联系/234

课后跟踪/235

亡羊补牢/235

鼓励员工活跃于开发者社群中/236

鼓励出席技术会议/236

鼓励开发者担任讲师/237

鼓励开发者写书/237

沉思的实践者/238