软件工艺

本书证明了优秀程序员对于成功软件开发的决定性影响！它告诉我们：·技术人员迫切需要转变观念。·技术不权是技术本身，更应该是为客户提供价值的基础。·我们该如何培养程序员对技术的精通？·如何发展小型开发团队中创造的协作？·如何加强与客户的沟通？如果你是一位渴望让自己的技艺出类拔萃的程序员……如果你是一位渴望雇用的优秀开发的项目经理……这本《软件工艺》就是为你准备的！PeteMcBreen是一名独立顾问，对软件开发情有独钟，尽管将很多时间用于写作、教学和顾问工作，但他仍然坚持每年至少在一个真实项目亲手从事编程工作。他特别善于为软件开发者面临的问题找到创造性的解决方案。在过去的很多的中，他参与了各种正式和非正式的过程改进活动，所以他能够以超然的态度看等软件业普遍存在的问题，并敏锐地意识到：“软件开发理应有其乐趣，否则，开发过程就是错的，他住在加拿大亚伯达省的小镇考昆，没有再回到大城市居住的计划。译者简介熊节，普通程序员，喜编程，乐此而不疲，酷爱读书，好求新知，记性好忘性大，故凡有所得必记诸文字，有小得，无大成。胸有点墨，心无大志，惟愿宁静淡泊而已。夜阑人静，一杯清水，几本闲书，神交于各方名士，献曝于天下同好，吾愿足矣。本书针对软件开发，提出了一些相当棘手和敏感的问题，并给出了颇具争议性的结论：从一个数百年来一直兴旺发达的系统——工艺学中获得启示，寻找答案。本书用5个部分共19章的篇幅，系统地阐述作者的观点，并试图回答一直困扰着软件行业的难题——我们应该如何重组软件构造的过程，使其能够如我们所愿地有效运转？第1部分共4章，对传统的观点提出质疑——软件工程真的是解决软件开发问题的灵丹妙药吗？第2部分共2章，这一部分提出了本书的观点，即以软件工艺的视角看待软件开发。第3部分以7章的篇幅，从不同的角度全面地展现了软件工艺理论所带来的主要变化，以及如何实践这个观念。第4部分共3章，对比了软件工艺与软件工程，并为各自适用的范畴重新划定了界限。第5部分共3章，分别讨论软件开发中的权宜之计和长期问题。本书荣获2002年度Jolt图书大奖。阅读本书，有助于引发读者在软件开发问题上的独立思考，本书适合软件行业的所有从业人员阅读参考。

　　Pete McBreen 是一名独立顾问，对软件开发情有独钟，尽管将很多时间用于写作、教学和顾问工作，但他仍然坚持每年至少在一个真实项目亲手从事编程工作。他特别善于为软件开发者面临的问题找到创造性的解决方案。在过去的很多的中，他参与了各种正式和非正式的过程改进活动，所以他能够以超然的态度看等软件业普遍存在的问题，并敏锐地意识到：“软件开发理应有其乐趣，否则，开发过程就是错的，他住在加拿大亚伯达省的小镇考昆，没有再回到大城市居住的计划。译者简介熊节，普通程序员，喜编程，乐此而不疲，酷爱读书，好求新知，记性好忘性大，故凡有所得必记诸文字，有小得，无大成。胸有点墨，心无大志，惟愿宁静淡泊而已。夜阑人静，一杯清水，几本闲书，神交于各方名士，献曝于天下同好，吾愿足矣。

第一部分  置疑软件工程
第 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