软件工艺

《软件工艺》针对软件开发，来自提出了一些相当棘手和敏感的问题，并给出了颇具争议性的结论:从一个数百年来一直兴旺发达的系统--工艺学中获得启示，寻找答案。《软件工艺》用5个部分共19章的篇幅，系统地阐述作者的观点，并试图回答一直困扰着软件行业的难题--我们360百科应该如何重组软件构造的过程，使其能够如我们所愿地有效运转?第1部分共4章，对传统的观点提出质疑--软件工程真的是解决未农让软件开发问题的灵丹妙药吗?第2部分共活走垂脚菜里地内2章，这一部分提出了本书的观点，即以软件工艺的视角看待软件开发。第3部分以7章的篇幅，从不同的角度全面地展现了软件工艺理论所带来的主要变化，以及如何实践这个观念。第4部分共3章，对比了软件工艺与软件工程，并为各自适用的范畴重新划定了界限。第5部分共3章，分别讨论软件开发中的权宜之计和注尽阳玉具等约长期问题。 《软件工艺》荣获2002年度Jo派实回如整报lt图书大奖。阅读本书，速算章律二意子纸占有助于引发读者在软件开发问题上的独立思考，《软件工艺》适合软件行业的所有从业人员阅读参考。

• 书名 软件工艺
• 作者 Pete McBreen
• 出版社 人民邮电出版社
• 页数 240页
• 开本 32

基本介绍

内容简介

　　《软件工艺》曾获有软件行马构业奥斯卡之称的Jolt图书大奖，由知名技术作者、C来自SDN技术主编孟岩，资深技术编辑韩磊倾力推荐，知名IT技术专家 熊节主笔翻译。《软件工艺》是颠覆软件工程、开发回归人本，值得深思回味的经典力作。

作者简介

　　Pete McBeen是一位独立360百科顾问，对软件开发情有独钟。尽管将很多时间用于写作、教学和顾问工作，但服他仍然坚持每年至少在一个真实项目中亲手从事编程工作。P下小酸止技ete特别善于为软件开发者面临的问题找到创造性检个冷员阶罗胞种的解决方案。在过去的很多年中，他参与了各种正式与非正式的过程改进活动，所以他能够以超然的态度看待软件业普遍存在的问题，并敏锐地意识到:"软件开发理应有其乐趣。否则，开发过程就么测社落友燃毛耐是错的。"Pete住在加拿大亚伯达省的小镇考昆，没有再回到大城市居住的计划。

图书目录

　　第一部分置疑软件工程

　　第1章理解软件工程 3

　　软件工程的悖论 4

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

　　得到可用的硬件之后志映各，软件开发者如何加快想行格述口着武属交付的速度? 5

　　传统洋检效端加胡木收种开发过程的内蕴 6

　　软件工程的当代解读 7

　　"足够好"的软件-庶民的软件工程 9

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

　　第2章软件工程的困境 11

　　"有组织的、可计量的"软件开发过程现实吗? 14

　　我们当然量书急四可以将软件开发中的某些部分自动化，不是吗? 16

　　"足够好"的软件开发方法的危害 17

　　谁能取代软件工程? 19

　　第3章理解软件开发 21

　　软件资产 23

　　软件开发需要团队协作 25

　　软件开发的分工有用吗? 26

　　没有一劳永逸 27

　　寻找比"软件工程"更合用的隐喻 30

　　第4章寻找一斯个比软件工程更好的隐喻 3阿胶劳女百坏情3

　　软件开发的工艺 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