《软件工艺》—第1章谁能取代软件工程？

版权声明 软件工艺 Authorized translation from the English language edition, entitled Software Craftsmanship: The New Imperative, 0201733862 by Pete McBreen, published by Pearson Education, Inc., publishing as Addison-Wesley, Copyright 2001 Pearson Education,

第 1 章 理解软件工程软件工艺为了看清软件工程适用(以及不适用)的范畴,我们首先需要对软件工程有一个深入的理解.为了理解软件工程,我们首先需要了解在早期的软件工程文献中提到的那些项目.稍做研究,你就会发现一个令人惊讶的事实:这些文献中几乎没有对商用软件的报告.在所有的案例中,绝大多数都是大型国防项目或者小型科研项目.在这两类项目中,开发者通常都需要面对极其严峻的硬件/软件条件:而在现代的商用项目中,环境通常会宽松得多. 一个非常典型的例子就是美国国防部于1969年至1975年间开发的SAFEG

第 2 章 软件工程的困境软件工艺软件工程存在的最大问题就是:它假设那种"有组织.有纪律.可计量的开发方式"是唯一可行的方式.软件工程实际上是把工程学的隐喻强加于软件开发之上,从而使我们一叶障目不见泰山,看不到其他开发方式的存在.有一个例子能够将这一问题彰显无遗,那就是软件工程中的"缺陷可能性"和"缺陷排除率"这两个概念: 缺陷可能性:软件项目中预期可能存在的全部错误和缺陷.缺陷排除率:在将软件项目发布给消费者之前,被排除的缺陷占潜在缺陷总数的百

软件工程适合你的项目吗?软件工艺需要同时开发全新的软/硬件系统的系统工程类项目显然是适于使用软件工程方法的,很多国防项目和航天项目都可以归于这一类.如果我要乘坐一架数控驾驶的航天飞机飞向太空的话,我一定会希望飞行控制软件的开发和检验是以一种"有组织.有纪律.可计量的方式"进行的.起码,如果听说这个软件是"由出价最低的软件公司开发的",我的心里一定不会太好受. 另一方面,如果你的企业需要开发大型的.打包销售的消费类软件,并且又善于作出恰当的工程学权衡,那么你很可能会使

"有组织的.可计量的"软件开发过程现实吗?软件工艺对于软件开发来说,所谓"确定的.可重复的过程"真的能够达到吗?SCRUM软件开发过程1的创始人曾经这样说道: 如果某个过程能够完全确定下来(即能够了解过程所涉及的所有细节,从而将其设计为可以重复地多次运行,并且完全能够预测其结果),那么该过程就被称为"确定过程".从理论上来说,一切确定的过程都可以被自动完成.另一方面,如果人们并未了解某个过程中的所有细节,只是大致地知道在某些初始条件下.通过某些调

2.7 敏捷软件开发与软件工艺的关系 经常有人误解软件工艺,认为它与敏捷开发是互斥的,是用来取代敏捷开发的.事实完全不是这样,它们能相互补充.时下的敏捷开发可以给软件组织及软件行业提供一套新思路.敏捷开发方式关注软件产品的价值.提倡根据价值排定优先级.简化繁琐的规章制度.减少浪费.扩大开发人员的参与范围,并提供快速反馈.这使得公司能够更迅速地应对变化,从而变得更加敏捷.敏捷开发方式帮助软件公司做正确的事.而软件工艺则涉及软件开发的专业技术层面.软件工艺是一种理念,许多开发者采用这种理念来激励自己

3.7 软件工艺的历史 早在1992年,Jack W.Reeves就提出,软件开发更像手艺而非工程.虽说如此,但笔者依然认为软件工艺的真正发端是Andy Hunt与Dave Thomas在1999年写的<The Pragmatic Programmer:From Journeyman to Master>.2001年,Pete McBreen出版了<Software Craftsmanship:The New Imperative>,这本书中的大部分理念后来都体现在了软件工艺活动之

3.7.6 <软件工艺宣言>及讲解 我们是有理想的软件工艺师,立志践行软件工艺并帮助他人学习软件工艺,以提升软件开发的专业水准.在此过程中,我们形成如下理念:不仅要开发出可行的软件,还要做工精良.不仅要应对变化,还要持续提升软件价值.不仅要注重个体与交互,还要打造专业的社团.不仅要注重客户协作,还要培养高效的伙伴关系.也就是说,在追求左侧价值的同时,我们也认为右侧那些价值是不容忽视的.软件工艺的实质就体现在宣言里"提升专业水准"这一表述之中.有一群经验丰富且才华卓越的开发者

3.2 维基百科对软件工艺的定义 (软件工艺)"是一种强调软件开发者自身编码技能的软件开发方式.软件开发者发现主流软件业有诸多弊病,如过于关注经济事务而疏于培养开发者的责任心等,于是,他们通过软件工艺来扭转这种局面."笔者不喜欢这个定义.它非常呆板,而且没有抓住软件工艺师(software craftsman)这一身份对于软件开发者的真正意义.