自由行

2009-07-29

[转]四十年软件工程故事

Filed under: 程序员, 转载 — thomas @ 12:19

2008.09.22  来自:CSDN   潘加宇

2008年5月14~16日,在德国迷人的小镇Garmisch,举办了软件工程四十年纪念会 议,Peter Naur、Brian Randell、M. Douglas McIlroy、Albert Endres、Luigi Dadda等40年前软件工程会议的关键人物重聚旧地。

40年前的1968年,正是在此地举行的NATO(北约)科技委员会会议上,“软件工程”作为正式的术语被确定下来,标志着一个新学科的开始。 Peter Naur和Brian Randell主编的会议报告中这样写道:“我们特意选择‘软件工程’这个颇具争议性的词,是为了暗示这样一种意见:软件的生产有必要建立在某些理论基础 和实践指导之上——在工程学的某些成效卓著的分支中,这些理论基础和实践指导早已成为了一种传统。”

软件工程这个学科还很年轻,Peter Naur和Brian Randell今天依然健在。作为著名的编程语言归约BNF范式中的N,Peter Naur因设计和定义了ALGOL 60而在2005年获得图灵奖。因IBM System360的工作于1999年获得图灵奖的Fred Brooks在《人月神话》的结尾比较了化学工程和软件工程。他认为:软件系统可能是人类所创造的最错综复杂的事物,软件工程还很年轻,需要继续探索和尝 试。

这四十年的过程就是探索和尝试的过程,让我们来细细品味其中的科学精神之美。

软件工程是什么

软件工程的定义有很多版本,比较权威的是IEEE给出的定义:(1)将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护,即,将工程应用于软件。(2)在(1)中所述方法的研究。

所以,软件工程远没有想象中那么高大神秘,它研究的就是我们日常开发软件的工作方式。“程序员”这三个字本就属于软件工程的范围。

关于软件工程和计算机科学的区别,Fred Brooks说:A scientist builds in order to learn; an engineer learns in order to build. 更详细的可以看看David Parnas的“Software Engineering Programs Are Not Computer Science Programs”和Steve McConnell所著“Professional Software Development”的第4章。或者对照一下图灵奖获得者:软件工程领域的David Parnas、Frederick P. Brooks和计算机科学领域的Donald E. Knuth、《程序员》上期介绍的YAO。

软件是为人开发的,软件是由人开发的。正是因为人的心理难以捉摸,人的大脑处理复杂性时速度和容量的局限,我们才需要过程来规范人的行为,需要方法 来帮助人脑面对复杂性,需要工具来贯彻这些过程和方法。所以,软件工程的知识体系分为以下几层。我们按照这个金字塔结构,逐层回顾四十年来的历史。

过程

一开始,软件团队是没有过程的,甚至没有团队概念。没有需求规格说明,没有设计,程序员在大脑中直接将代码思考出来,拼凑到一起,交给客户使用。客 户如果有要求,再修改代码,如此反复。这种“编码-修改”做法对于小程序可以应付,当程序规模变得复杂时,付出的代价就很大了。

瀑布

“软件工程”概念的提出,促进了需求、分析、设计、实现、维护等软件生命周期概念的成熟。瀑布模型是最早的软件过程模型,从名字“瀑布”可以看出, 通常人们认为瀑布模型中的各个步骤是一条线完成的。实际上在Winston W. Royce1970年的经典论文“Managing the Development of Large Software Systems”中有反馈的过程(见图3),作者本人也并不提倡以顺序模型作为团队的过程模型,另外,Royce并没有在论文中把他的过程模型叫做“瀑 布”,只是后来其他人这么叫了。很多团队使用时是按照线性的方式使用的,这是一种误解。

这里要提一下,瀑布模型的提出者Winston W. Royce(已于1995年去世)有时被简写为W. Royce,所以经常会引起误会,把他当成Walker Royce,后者是软件项目管理专家,曾任Rational软件公司副总裁,著有《Software Project Management: A Unified Framework》一书。

增量和迭代

使用瀑布模型,可以运行的产品很迟才能看到,这就潜伏了巨大的风险:很可能,集成之日也就是爆炸之日。为了提早获得可以运行的版本,可以先实现一些功能,再实现一些功能……每个增量交付一个可以运行的版本。

增量开发显著降低了风险,而且还因可运行产品的出现大大提升了士气。最有名的实践应该是Microsoft在1989年就开始使用的Daily Build(每日构建),被称为项目的“心跳”。当然,增量开发不一定意味着每日构建,如Fred Brooks所述,Bell Northern Research是“每周构建”。

增量经常和迭代连在一起说,不过两者是有区别的。增量是逐块建造的概念,迭代是反复求精的概念。二者不一定要绑在一起使用,但很明显,结合这两种方 式是一种有效的做法。现在很多过程所说的迭代开发,默认的意思就是增量&迭代。Jeff Patton最近用两幅图表达了增量和迭代(http://www.agileproductdesign.com/blog/dont_know_what_i_want.html)。

统一过程

1987年,Ivar Jacobson离开Eric-sson,成立了Objective Systems公司。他吸纳了增量迭代的思想,开发出Objectory过程,并且把过程当软件卖,价格卖到25000美元一份,以至于Ivar Jacobson不想在Addison-Wesley等出版社出书公开他的方法,因为卖一本书才得到3美元。1991年,Ericsson收购了该公司, 并更名为Objectory AB(北欧出大师,所以我们常在软件开发的书籍和文章中看到××AB等文字,AB是瑞典语Altiebolag的缩写,意思是“公司”),Ivar Jacobson又回到了Ericsson。

1995年,Rational从Ericsson收购了Objectory,Ivar Jacobson开始和Grady Booch、James Rumbaugh一起开发UML。Philippe Kruchten则负责把Objectory过程和Rational公司多年的积累Rational Approach融合在一起,开发出了“Rational Unified Process”以及4+1视图模型。RUP的中心思想是:用例驱动、架构为中心、迭代和增量。虽然是一个商业产品,但详尽的内容和灵活的组织,使得 RUP成为软件团队中流传最广的软件过程模型,也成为团队学习软件工程和实施过程改进的重要资料。

Ivar Jacobson在IBM收购后离开了Rational。2005年,他发布了Essential Unified Process(EssUP)将之描述为“超轻和超敏捷的”RUP,并且提出了过程定义(PD)和过程(P)的观点,他认为统一过程是一个过程定义 (PD),不是过程(P),团队不能看着别人的P好,就想着拿来就用,必须要找到自己的点。

2007年,Ivar Jacobson的新观点是“过程够了,实践吧(Enough of Processes: Let’s Do Practices)”。
Doug Rosenberg和Kendall Scott的ICONIX过程借鉴了Ivar Jacobson和统一过程的思想,而且以其小巧易懂,受到不少开发人员的欢迎。

敏捷运动

敏捷运动在20世纪90年代中期兴起,当时敏捷过程被称为“轻量”过程。2001年,Kent Beck、Alistair Cockburn、Ward Cunningham、Martin Fowler、Jim Highsmith、Ron Jeffries、Jon Kern、Robert C. Martin、Steve Mellor、Ken Schwaber等人聚集在犹他州的Snowbird,决定把“敏捷”作为新的过程家族的名称,并提出以下宣言:

随后,敏捷联盟成立,这是一个致力于传播敏捷过程的非营利组织。敏捷联盟每年召开敏捷大会,今年已经是第6年。

关于敏捷过程,比较全面的介绍文章是Martin Fowler的“The New Methodology”。每隔一段时间,Fowler会随着形势的变化更新此文。该文2005年12月版本列出的各种流行敏捷过程包括:极限编程 (XP)、Scrum、Crystal、上下文驱动测试(Context Driven Testing)、精益开发(Lean Development)、统一过程(Unified Process)。

极限编程(XP)是敏捷过程的代表。1996年,Kent Beck为了挽救Chrysler Comprehensive Compensation (C3)项目而创建了XP过程,虽然Chrysler最终取消了该项目,但是Ron Jeffries和Ward Cunningham等人参与到了XP的工作中。1999年,Kent Beck出版了“Extreme Programming Explained: Embrace Change”一书。XP一代相当于程序员的宣言,受到了程序员的热烈欢迎。2004年,该书第2版出版,Kent Beck说自己几乎完全重写了整本书,书中关于程序员是宇宙中心的内容少了很多,更多的是谈程序员和编程工作必须处于业务环境中,他们需要成为正常商业世 界中的一部分。

过程评估和CMM

从1968年开始,Watts S. Humphrey是IBM负责软件部门的副总裁。1986年,Watts S. Humphrey离开IBM后,加入了SEI(卡内基?梅隆大学软件工程研究所),开始开发CMM(Capability Maturity Model,能力成熟度模型)。CMM一开始的目的是为军方制定一个好用的评估承包商的标准,因为SEI本来就是军方资助的机构。

1989年,在《Managing the Soft-ware Process》一书中,Humphrey描述了CMM。CMM可以看作是一个软件过程元模型,定义软件组织达到一定能力成熟度所需的关键过程域(KPA)。
20世纪90年代中期,CMM开始在世界范围内流传开来,成为一些政府采纳的评估软件组织的标准,政府甚至对通过评估的软件组织加以资助。在这种激励下, 想获得政府订单或者政府资助的软件组织纷纷力争通过CMM评估。目前,通过CMM/CMMI评估的组织数量前三位国家是:美国、印度和中国。

方法

在20世纪60年代,程序员随意地编写代码。虽然当时已经出现了FORTRAN等高级语言,但程序员把代码写在一起,代码中使用GOTO语句来跳转,使得程序的内部结构像“意大利面”,整个程序又像一块铁板,无法单独抽取其中一部分复用。

功能分解

1968年,Edsger W. Dijkstra发表《Go To Statement Considered Harmful》,认为GOTO语句是有害的,应该把程序划分成多个子单元,每个子单元只做一件事,当重复的语句集合出现时,只需要调用相应子单元(函 数)。这相当于封装和复用了共同的行为。

数据流

当软件的规模不断变大,大到不能一下子映射到代码级别时,就需要更大颗粒的分析设计方法。20世纪70年代,数据流法出现了,有三种流行的流 派:DeMarco方法(1978)、Gane/Sarsen方法(1979)以及Yourdon/Constantine方法(1979)。

数据流法把系统看作数据的加工机,数据流进去,经过加工,变成新的数据流出来。从最顶层开始(因为此时系统看作是一个整体,所以表达的就是功能需求),一层一层向下求精,一直求精到泡泡所代表的加工成为可以编码的动作。

实体/关系

20世纪70年代末,关系数据库开始变得流行。Peter Chen(陈品山)在1976提出实体关系(ER)模型,用实体和关系映射现实中的事物和概念。该模型提供了数据的图形视角,并能轻松转换为关系数据库模 型。分析员很快认识到,ER模型可以用来表达大型软件的数据库设计,更宏观地把握业务,而且还有助于分析员和用户交流。

数据流法结合实体关系法,曾经是比较流行的开发软件的方法。这种做法的一个问题是数据和行为是分离的,行为可以随意读写数据。另一个问题是分析和设计之间表达不一致,使得从设计回溯到分析相当困难。这正是面向对象分析设计所要改进的。

面向对象

Alan Kay说“面向对象”这个词是他在1967年首先使用的(http://www.purl.org/stefan_ram/pub /doc_kay_oop_en),但人们普遍认为,1967年由挪威的Ole-Johan Dahl和Kristen Nygaard设计的Simula-67是第一门面向对象语言,它是作为ALGOL的一个超集出现的。虽然Simula没有后继版本,但这个语言对后来的 许多面向对象语言的设计者产生了很大的影响,80年代初,Alan Kay在Palo Alto研发的Smalltalk语言被广泛使用(Kent Beck就是Smalltalk的拥护者),掀起了一场“面向对象运动”,许多面向对象语言随之诞生。Grady Booch在他的最新著作“Object-Oriented Analysis and Design with Applications”第3版中归纳。

面向对象的思想就是:假设系统由“对象”这样一种东西构成,对象封装了结构和行为。这种思考方式和人类的认知相当贴近,更有利于人脑去把握问题的复杂性。分类是人类认知的一种基本技能,分类哲学的讨论可以追溯到柏拉图的《政治家》和亚里士多德的《范畴》。

结构化分析设计和面向对象编程之间不能很好地过渡,到1980年代后期,不同的方法学家开始提出自己的面向对象分析设计方法学。这些方法学主要 有:Booch、Shlaer/Mellor、Wirfs-Brock责任驱动设计、Coad/Yourdon、Rumbaugh OMT、Jacobson OOSE。

UML

这种百花齐放的局面带来了一个问题:各方法学有自己的一套概念、定义、标记符号和术语,但总的来说大同小异。这些细微的差异通常会造成混乱,使开发人员无从选择,也妨碍了面向对象分析设计的推广。
1994年,在Rational工作的Rumbaugh和Booch开始合并OMT和Booch方法。随后,Jacobson带着他的OOSE方法学也加 入了Rational公司,一同参与这项工作。他们三个人被称为“三友”(three amigo)。这项工作造成了很大的冲击,因为在此之前,各种方法学的拥护者觉得没有必要放弃自己已经采用的表示法,而接受统一的表示法。

1996年,三友开始与James Odell、Peter Coad、David Harel等来自其他公司的方法学家合作,吸纳了他们的成果精华。1997年9月,所有建议被合并成一套建议书提交给OMG。1997年11月,UML被 OMG全体成员一致通过,并采纳为标准。UML诞生时,Martin Fowler就作了如下预测:

你应该使用UML吗?一个字:是!旧的面向对象符号正在快速地消逝。它们还会残留在UML稳固前出版的书上面,但新的书、文章等等将会全部以UML 作为符号。如果你正在使用旧的符号,你就应该在1998年间转换到UML。如果你正要开始使用建模符号,你就该直接学习UML。

时间过去10年了,事实正是如此。以UML为契机,掀起了一股普及软件工程的热潮,比起UML出现之前,软件工程的书籍出现了爆炸性的增长。制定 UML标准的角色(OMG)、根据标准开发工具的角色(UML工具厂商)、使用UML工具开发软件的角色(开发人员)这三种角色的剥离,也导致建模工具数 量和种类出现了爆炸性的增长。

现在,UML已经被ISO吸纳为标准,UML1.4.2即ISO/IEC 19501,UML2.1.2即ISO/IEC 19505。

模式运动

1979年,Christopher Alexander开始使用“模式”来描述建筑的构造方法。1987年,Kent Beck和Ward Cunningham尝试把这种思路应用到软件开发中,并在OOPSLA大会上发表了自己的看法。一直到1994年10月,被称为四人帮(GoF)的 Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides所写的《设计模式》上市(此书是1995年的版权,看来国内外出版业差不多,我们可以在2007年12月买到2008年1月第1版的 书),模式的概念才流行起来。此书到2007年为止共重印36次,被翻译成13种其他语言,而且有不计其数的兄弟书籍诞生出来,“言必称模式”成为一种时 髦,可谓影响深远。

现在,除了最常提到的GoF的23种设计模式之外,不断有各种各样的模式提出来,包括分析模式、架构模式、过程模式、组织模式、实现模式、反模式……

工具

很长一段时间内,软件开发工具指的就是代码工具,而且编辑、调试、编译是分离的。后来慢慢出现了IDE(集成开发环境),各大工具厂商更是在IDE市场激战。这方面的故事,大家可以看李维的《Borland传奇》。

在软件工程工具如分析设计、过程管理等工具方面,却是一片空白。一直到1982年,Nastec公司开发出了DesignAid,该工具提供绘制系 统设计图和建立数据字典的功能。到了1990年代,随着方法学繁荣和图形界面的普及,才出现了大量的设计工具,典型的代表是Rational Rose和Popkin System Architect。

最初的设计工具以独立的产品存在,而且只是提供了画图的功能,然后慢慢有了代码正向逆向工程。开发人员在设计工具里建好模型,再通过一个转换器在代 码环境生成代码。设计工具的一个变种是成为代码环境的插件(Rational XDE,Together for VS.net等),直接在代码环境中创建设计模型,和代码高效同步。

接下来的趋势是设计工具和生命周期其他工具集成。2002年10月,Borland收购了当时UML工具厂商中的老二Togethersoft,这 成为了导火索。之后,IBM、Telelogic、Borland等大厂商通过并购和放弃,打造出了新的品类——应用生命周期管理(ALM)工具。微软的 工具Visual Studio Team System也在朝ALM工具方向进化。图12列出了三家ALM厂商一些产品的对比。

现在,Rational和Telelogic都已经被IBM收入旗下,但Sparx Systems、NoMagic、Gentleware等中小厂商纷纷加入到这个市场中,竞争依然激烈。我们来看看代表性厂商Rational的历史,也可以从一个侧面了解工具的发展。

结语

1999年,我创建了UMLChina,从那时开始关注软件工程各方面的进展。到现在为止,我已经上门为超过100个软件开发团队提供需求和设计技 能(根据我们上面的分类,这属于“方法”层面)服务。我发现一个有趣的现象,在开始服务之前的商议过程中,很多开发团队(不是每个团队)或多或少都会有人 (不是每个人)或明或暗地表达出这样的观点:自己团队的难处与众不同,奇特的困难降临在他们身上,偏偏别人得以幸免。

尽管UMLChina一直强调自己的服务是“聚焦最后一公里”,坚信每一个开发团队都会在细节上和其他团队有所不同,而且也应该有所不同。但很多时候,我还是感觉到,开发团队还是高估了自己的“个性”,低估了“共性”。

最核心的共性问题,仍然是质量——能最大化获取利润的质量。它无非是两条路:增加收入——如何把东西更好地“卖”出去(给客户,给领导……);减少 成本——如何用可复用的要素(组件、过程……)降低制造的成本。这些正是软件工程的不同分支(需求工程、架构设计、过程改进……)要研究的。四十年来的研 究成果,肯定会有一些适合您的团队。这些成果是先行者们从自己或别人的血泪中提炼出来的,我们没有必要再重复挥洒血泪了。

潘加宇,UMLChina首席专家,潜心研究和实践UML/UP相关技术的应用。

2009-07-18

搜索你自己

Filed under: 程序员, 随笔 — thomas @ 23:37

今天看到一篇关于社交网站的报道,提到了个人隐私信息的保护问题。晚间觉得无事,便用自己的姓名搜索了一番。

谷歌的结果:(为了保护隐私信息略去姓名,大家可以自己尝试一下)
Results 1 – 10 of 10 Chinese (Simplified) pages for “xxx“. (0.05 seconds)

百度的结果:
百度一下,找到相关网页7篇,用时0.016秒

结果发现,几年前在某网站上传了一些代码。当初上传本省是为了方便网友下载,结果那个网站实行“配额制”,也就是说需要上传才能下载,可是又会有几个人愿意或者方便的传代码上去交换呢?于是除了有26次下载外,只是“沉睡”在某个网站的服务器硬盘盘中。

最初传到51files网站的内容,不到一年就失效了,估计网站已经不复存在了。如今笔者自己开设个人网站,想当初花了数个夜晚编写的代码,尽管功能不多,也属不易。那就放在自己的网站上吧,共网友下载、学习。

[相关链接]

ARP协议浅析(4):回顾

http://liuxk.net/blog/?p=155

2009-07-08

[转]手机操作系统:寡头之争

Filed under: 转载, 通信产品公司新闻 — thomas @ 00:41
http://www.sina.com.cn 2009年07月07日 16:02 互联网周刊

借助Windows,微软成就了在PC上的霸业。当终端厂商、软件厂商、互联网公司以及运营商纷纷跻身“手机操作系统俱乐部”,智能手机平台将会几分天下?

本刊记者 马荟

手机操作系统的市场永远不乏变动与新闻。2008年,智能手机操作系统市场在全球范围内依次被Symbian、Palm OS、iPhone(手机上网) OS、Windows Mobile和Linux等占据,其中,仅Symbian就夺走几乎半壁江山。而在中国,Windows Mobile紧随Symbian系统之后。随着谷歌Android的成熟推进和中国移动进军手机操作系统领域,中国手机平台上的争斗愈发激烈复杂。

手机操作系统作为智能手机上丰富应用程序的依托,已经成为3G时代各个厂商必争的兵家之地,呈现出相比PC时代更热闹的局面。无论是依托手机设 备的渠道制高点,还是寄望于软件或者服务上的优势,手机操作系统门槛并没有因为机遇的到来而降低。具有不同“背景”和DNA的手机操作系统,将使出何种奇 招跑马圈地?

“小视窗”征程

面对诺基亚等终端厂商的天生强势,微软在手机操作系统市场的日子并没有在PC领域那么舒服。Windows Mobile在全球的市场份额始终徘徊不前,而在中国,前有诺基亚Symbian系统,后有苹果和谷歌的追赶。微软也意识到,仅有软件平台难以在复杂的市 场环境和用户口味中走得更远。微软今年推出名为“Skymarket”的应用程序商店,一方面,希望复制苹果的巨大成功;另一方面,也有意在移动互联网领 域实现向“软件加服务”模式的转型。

与其他手机操作系统相比,Windows Mobile能实现桌面电脑系统与手机系统无缝结合,包括Outlook等Office办公套件,可以实现远程办公和几乎与电脑上无异的操作方式。

面对谷歌Android的高调进入,微软CEO鲍尔默信心十足。他曾在采访中表示“Android并不成熟”,而且“开源解决方案对手机制造商 没有太大吸引力”。目前全球五大手机厂商中的四家选择支持Windows Mobile,而在中国市场,由于iPhone、谷歌G1入华进程迟缓,RIM旗下的黑莓也还不能很好适合中国用户习惯,对于智能手机生产厂家而 言,Windows Mobile也就成了Symbian之外不错的选择。

开源崛起

在所谓开源的手机操作系统中,有些产品突围的关键可能并不是因为其开放的基因。在开源阵营中,Linux移动终端操作系统因其开放源代码的优势 获得了包括摩托罗拉和NTT DoCoMo等终端厂商和运营商的关注。而同样基于开源系统的Symbian操作系统和谷歌Android,却分别因其终端优势和在互联网领域的优势,分 别成为最有“普及”实力和最有“前景”的手机操作系统。

尽管诺基亚早已不承认自己是手机厂商,而是一个互联网公司,但其手机带给Symbian的天生优势确实是Symbian成功的最重要原因之一。 Symbian依托诺基亚手机在用户中的影响力,成为现今手机领域中应用范围最广的操作系统,其Series也分别针对不同用户有不同的界面设计。

《商业周刊》曾撰文称,谷歌和Symbian协会开放手机操作系统平台并不意味着手机行业的和平与和谐。2007年11月,谷歌发布基于 Linux平台的开源手机操作系统Android,号称是首个为移动终端打造的真正开放和完整的移动软件。尽管谷歌去年公布了Android的源代码,但 Symbian协会主管李·威廉姆斯表示,基于Linux的谷歌Android平台只是穿着“公开”的外衣,而实质上并未公开,“这只是营销手 法,Android仍处于谷歌控制之下”。

对此,谷歌也提出反击:“谷歌嵌入Android平台的技术都已经开放,我们的竞争对手所知的内容跟我们一样多”。借助Android,谷歌将 继续把其“软件网络化、产品服务化”的理念深入到移动互联网领域,把其应用程序和互联网服务推送到移动互联网上,复制其在互联网上的神话。

运营商布局

从整个手机行业来看,企业之间的竞争已经演变为手机操作系统之间的竞争。而运营商的在手机操作系统上的布局,也颇有“你方唱罢我登场”的意味。

同作为运营商,中国移动和中国联通无论是与苹果谷歌合作,还是推出自己的操作系统,虽然步调不同,但是方向却格外相似。

实际上,中国移动早在一年前就开始在手机操作系统上的布局,此前,中国移动与苹果公司在引入iPhone过程中历经曲折并最终夭折。其后,中国 移动与谷歌签署了秘密协议,双方就基于Android开发手机操作系统达成相关合作,中国移动有了可以和iPhone对抗的砝码。

中国联通也向苹果公司伸出橄榄枝,与中国移动走的道路颇为相似。此前已有消息称,中国联通将开发自主的手机操作系统UniPlus,以对抗中国移动的手机操作系统OMS和其定制开发的OPhone。另一边,中国电信也表示,把开发手机操作系统“纳入公司的考虑范围”。

而相比中国移动推出基于其OMS操作系统的手机,中国联通和中国电信的动作明显慢了半拍。据悉,中国移动已经与联想达成合作,在国内推出首款 Ophone手机O1。联想的这款TD-SCDMA手机已经在业内专家和手机发烧友的人群开始试用。在测试中,联想将配备专门的技术团队和客服团队,以收 集试用者的意见及建议,从而持续改进O1手机的表现。

借助Windows,微软成就了在PC上的霸业。当终端厂商、软件厂商、互联网公司以及运营商纷纷跻身“手机操作系统俱乐部”,智能手机平台将会几分天下?可以预见的是,随着3G应用的逐渐深入,传统手机操作系统的版图将被改变,洗牌不可避免。

2009-07-04

[转]软件开发的精益理念

Filed under: 思想, 知识, 精益, 转载 — thomas @ 01:16

来源 : 不明

精益生产是制造业领域的一大创举,而如果把精益生产的简单原则运用到软件开发上,我们称之为精益编程(Lean Programming)。有人预言,精益编程的效果可能与20世纪80年代精益生产所带来的生产改进一样重大。精益生产的10条简单原则对精益编程同样适用。实际上自适用软件开发及肯特·贝克的极限编程(Extreme Programming)中都运用了这些原则。

精益原则一:消除浪费

精益生产的第一个原则就是消除浪费。利用价值流分析可以发现流程中的所有活动,并能找出最终添加到产品中的价值,然后价值流分析会试图找到更为有效的方法去产生同一价值。

在软件开发过程中制作的文档、图表及模型是软件开发项目 的一部分,但它们往往是消耗品,可以用来帮助系统的生产,但未必是最终产品。一旦系统交付,用户对这些中间过程的消耗品并不在乎。所以此类消耗品需要证明 自己不仅能为最终产品增值,而且还是获得最终价值的最有效的方法。

精益原则二: 尽量减少冗余库存

库存太多会耗用资源、延长响应时间以及隐藏质量问题。软件开发的库存是指不属于最终产品的那些文档。分析一下就会发现,制作这类文档所花费的时间占据了产品周期的一大部分,而最大的浪费还是因为文档无法正确、全面地抓住用户需求而开发了不符合用户需求的系统。

我们知道用户很难依据文档去设想系统的细节;即使是在实际使用前,用户也不可能正确预测系统的运行;甚至在系统交付之后,用户还可能发现这并不是今后整个使用期间自己所期望的系统运行方式。而在评估文档的价值时,这些因素都必须考虑在内。

精益原则三: 缩短系统的响应时间

20世纪80年代,TQM(全面质量管理)原则教会我们如何在数小时而不是数天或数周之内完成产品生产;在传统软件开发需要几个月或几年时间的时候,电子商务项目往往能够在几周之内完成。

丹尼斯·弗雷利曾提议利用降低制造周期所用的技术来缩短软件开发周期。他建议充分利用小批量流畅流程原则。

迭代开发基本上就是把这些原则运用到软件编程上。按照这种方法,在整个开发周期不断设计和交付小而完整的部分。迭代周期从几周到几个月不等,每个迭代阶段都涵盖从收集需求到验收测试的整个开发过程。

精益原则四:获取需求 延迟决策

制造行业过去常常认为,如果营销部分能够准确预测市场需求那该多好。但后来发现这种想法是不对的,相反,应该大大缩短系统的响应时间,以便系统能够对变化做出充分的反应,从而抛弃对预测的依赖。其实IBM目前所推广的EBusiness On Demand正是出于这样的思路,而此前戴尔的成功也是与这个理念分不开的。

使需求保持灵活性,并尽可能贴近交付系统,将为软件开发提供更强的竞争优势。在软件开发的早期阶段敲定设计同样带有预测性,所以软件系统的设计应该随时捕获新的需求,并对变化做出响应。

精益原则五:满足客户需求

导致软件项目失败最常见的原因就是需求不全面或不正确,针对这种风险,软件开发商在继续设计系统之前,会尽量收集详细的用户需求,然后由用户确认。

但很多用户在确认需求文档时经常会拖拖拉拉,他们担心自己认可的项目到头来会是个错误,所以等待他们确认文档会浪费大量时间。从这个角度来说,获得用户的同意非但不能鼓励用户参与,反而会造成开发人员和用户之间的对立。

准确抓住用户需求的有效办法就是借助于迭代系统开发,及早开发核心特性并且通过每个迭代阶段的可用性演示获得客户反馈。

精益原则六:结合反馈 一次做好

当在生产线上发现劣质产品时,很多制造企业会对劣质品进行返工,但效果不佳。相反,如果在整个制造流程中运用测试和控制手段,确保每次移交时每个部件都是合格的,这样就很容易查明产品何时偏离了规格。

业界已经公认,软件交付后找到问题并修正的成本是早期设计阶段的100倍,所以企业需要在编写程序之前验证详细设计的合理性。当然软件的规格在不断变化,企业需要利用各种技术手段不断适应变化。

各种测试技术是整个开发过程中适应变化的最佳手段。另一种应对变化的技术就是再构,即通过受控的方式改进现有软件的设计,利用再构,初始设计可以专注于眼前的问题,以后再考虑将来的需求。

精益原则七:对员工下放权力

如果软件开发环境不如预期,主管的本能反应往往是实行更严格的流程,更加详细地明确员工如何完成任务。精益生产则建议采取截然相反的方法,如果开发出现了问题,不要引进外面的专家,而是为员工提供评估及改进各自领域的工具,给予员工足够的权力,最终自己解决问题。

跟精益生产一样,精益编程同样重视团队的协作。软件开发 至少需要一次信息移交,即从用户到编程人员,但更多的时候不止一次,比如从用户到设计人员,再到编程人员。有观点认为,这类书面信息最好全部移交,但实际 上在移交纸面信息时,会无形中丢失大量有效信息,而让小组成员协同工作则效率要高得多,同时还减少了文书工作。

精益原则八:取消局部优化

在过去,不让机器满负荷运作是难以接受的,但在精益生产中这却是合理的。

一些受过训练的项目经理会非常关注某些局部的管理,正如 制造工人致力于尽量提高机器的生产效率一样。但精益编程是受时间和反馈的驱动,所以局部生产力的优化会削弱整个制造流程。在用户所处环境不断变化的今天, 如果把局部优化放在非常重要的位置,那当用户需求发生变化时,所有优化工作都付之东流。

如果某个局部的功能有一定的框架限制,只要它不会拖延工期,就不必为它担心。

精益原则九:利用逐步采购

供应链并不是在今天才产生,让供应商相互竞争,保证以最低的成本获得原材料也是很常见的,但精益生产又一次改变了这种惯例。美国管理大师爱德华兹·戴明认为,与供应商基于信赖的关系创造了给双方公司带来最大效益的环境。

事实证明,减少供应商的数量,其合作关系具有更高的质量。长期的合作关系可以帮助企业改进产品设计及生产流程,而且几乎无需文书工作。

很多软件企业认识到,传统的软件开发合同造成了隐性浪费。而对软件用户来说,相对稳定的软件开发商可以专注于为用户提供更优秀的软件,并可在开发中尽可能迟地使需求稳定下来。

精益原则十:缔造精益文化

这个原则不用解释也一目了然,如今优秀的软件开发意味着能够不断适应变化。其实在类似CMM的模型中缺乏对变化迅速做出响应的灵活性。

从某种意义上来说,迭代项目环境成了运行环境,因为流程重复出现,就可以把流程改进技术从一个迭代阶段运用到另一个阶段。不过我们需要的不仅仅是涵盖某个项目的改进模型,只要学习现有的项目,就可以改进未来项目的性能。

注:这篇文章在网站及博客中被多次转载。在<”软件开发” “精益理念”>组合关键字中搜索结果如下:
Results 110 of about 129 for “软件开发” “精益理念”. (0.20 seconds)

作者对于精益思想中“价值、价值流、流动、拉动、尽善尽美”的核心观点把握的很到位。但是具体技术、实施方面涉及太少,或许原作者有很好的实践没有总结出来,或者是藏于互联网的信息海洋中,笔者将持续的关注这个话题。

Èí¼þ¿ª·¢µÄ¾«ÒæÀíÄî
À´Ô´£ºÖйú×Ôѧ±à³ÌÍø   ·¢²¼ÈÕÆÚ£º2007-11-21
¾«ÒæÉú²úÊÇÖÆÔìÒµÁìÓòµÄÒ»´ó´´¾Ù£¬¶øÈç¹û°Ñ¾«ÒæÉú²úµÄ¼òµ¥Ô­ÔòÔËÓõ½Èí¼þ¿ª·¢ÉÏ£¬ÎÒÃdzÆ֮Ϊ¾«Òæ±à³Ì£¨Lean Programming£©¡£ÓÐÈËÔ¤ÑÔ£¬¾«Òæ±à³ÌµÄЧ¹û¿ÉÄÜÓë20ÊÀ¼Í80Äê´ú¾«ÒæÉú²úËù´øÀ´µÄÉú²ú¸Ä½øÒ»ÑùÖØ´ó¡£¾«ÒæÉú²úµÄ10Ìõ¼òµ¥Ô­Ôò¶Ô¾«Òæ±à³ÌͬÑùÊÊÓá£Êµ¼ÊÉÏ×ÔÊÊÓÃÈí¼þ¿ª·¢¼°¿ÏÌØ¡¤±´¿ËµÄ¼«ÏÞ±à³Ì£¨Extreme Programming£©Öж¼ÔËÓÃÁËÕâЩԭÔò£¬Öйú×Ôѧ±à³ÌÍø£¬www.zxbc.cn ¡£
¾«ÒæÔ­ÔòÒ»£ºÏû³ýÀË·Ñ
¾«ÒæÉú²úµÄµÚÒ»¸öÔ­Ôò¾ÍÊÇÏû³ýÀË·Ñ¡£ÀûÓüÛÖµÁ÷·ÖÎö¿ÉÒÔ·¢ÏÖÁ÷³ÌÖеÄËùÓл£¬²¢ÄÜÕÒ³ö×îÖÕÌí¼Óµ½²úÆ·ÖеļÛÖµ£¬È»ºó¼ÛÖµÁ÷·ÖÎö»áÊÔͼÕÒµ½¸üΪÓÐЧµÄ·½·¨È¥²úÉúͬһ¼ÛÖµ¡£
ÔÚÈí¼þ¿ª·¢¹ý³ÌÖÐÖÆ×÷µÄÎĵµ¡¢Í¼±í¼°Ä£ÐÍÊÇÈí¼þ¿ª·¢ÏîÄ¿µÄÒ»²¿·Ö£¬µ«ËüÃÇÍùÍùÊÇÏûºÄÆ·£¬¿ÉÒÔÓÃÀ´°ïÖúϵͳµÄÉú²ú£¬µ«Î´±ØÊÇ×îÖÕ²úÆ·¡£Ò»µ©ÏµÍ³½»¸¶£¬Óû§¶ÔÕâЩÖмä¹ý³ÌµÄÏûºÄÆ·²¢²»ÔÚºõ¡£ËùÒÔ´ËÀàÏûºÄÆ·ÐèÒªÖ¤Ã÷×Ô¼º²»½öÄÜΪ×îÖÕ²úÆ·ÔöÖµ£¬¶øÇÒ»¹ÊÇ»ñµÃ×îÖÕ¼ÛÖµµÄ×îÓÐЧµÄ·½·¨¡£
¾«ÒæÔ­Ôò¶þ£º ¾¡Á¿¼õÉÙÈßÓà¡°¿â´æ¡±
¿â´æÌ«¶à»áºÄÓÃ×ÊÔ´¡¢ÑÓ³¤ÏìӦʱ¼äÒÔ¼°Òþ²ØÖÊÁ¿ÎÊÌâ¡£Èí¼þ¿ª·¢µÄ¡°¿â´æ¡±ÊÇÖ¸²»ÊôÓÚ×îÖÕ²úÆ·µÄÄÇЩÎĵµ¡£·ÖÎöһϾͻᷢÏÖ£¬ÖÆ×÷ÕâÀàÎĵµËù»¨·ÑµÄʱ¼äÕ¼¾ÝÁ˲úÆ·ÖÜÆÚµÄÒ»´ó²¿·Ö£¬¶ø×î´óµÄÀË·Ñ»¹ÊÇÒòΪÎĵµÎÞ·¨ÕýÈ·¡¢È«ÃæµØץסÓû§ÐèÇó¶ø¿ª·¢Á˲»·ûºÏÓû§ÐèÇóµÄϵͳ¡£
ÎÒÃÇÖªµÀÓû§ºÜÄÑÒÀ¾ÝÎĵµÈ¥ÉèÏëϵͳµÄϸ½Ú£»¼´Ê¹ÊÇÔÚʵ¼ÊʹÓÃÇ°£¬Óû§Ò²²»¿ÉÄÜÕýÈ·Ô¤²âϵͳµÄÔËÐУ»ÉõÖÁÔÚϵͳ½»¸¶Ö®ºó£¬Óû§»¹¿ÉÄÜ·¢ÏÖÕâ²¢²»ÊǽñºóÕû¸öʹÓÃÆÚ¼ä×Ô¼ºËùÆÚÍûµÄϵͳÔËÐз½Ê½¡£¶øÔÚÆÀ¹ÀÎĵµµÄ¼Ûֵʱ£¬ÕâЩÒòËض¼±ØÐ뿼ÂÇÔÚÄÚ¡£
¾«ÒæÔ­ÔòÈý£º Ëõ¶ÌϵͳµÄÏìӦʱ¼ä
20ÊÀ¼Í80Äê´ú£¬TQM£¨È«ÃæÖÊÁ¿¹ÜÀí£©Ô­Ôò½Ì»áÎÒÃÇÈçºÎÔÚÊýСʱ¶ø²»ÊÇÊýÌì»òÊýÖÜÖ®ÄÚÍê³É²úÆ·Éú²ú£»ÔÚ´«Í³Èí¼þ¿ª·¢ÐèÒª¼¸¸öÔ»ò¼¸Äêʱ¼äµÄʱºò£¬µç×ÓÉÌÎñÏîÄ¿ÍùÍùÄܹ»ÔÚ¼¸ÖÜÖ®ÄÚÍê³É¡£
µ¤Äá˹¡¤¸¥À×ÀûÔøÌáÒéÀûÓýµµÍÖÆÔìÖÜÆÚËùÓõļ¼ÊõÀ´Ëõ¶ÌÈí¼þ¿ª·¢ÖÜÆÚ¡£Ëû½¨Òé³ä·ÖÀûÓá°Ð¡ÅúÁ¿¡±ºÍ¡°Á÷³©Á÷³Ì¡±Ô­Ôò¡£
µü´ú¿ª·¢»ù±¾ÉϾÍÊÇ°ÑÕâЩԭÔòÔËÓõ½Èí¼þ±à³ÌÉÏ¡£°´ÕÕÕâÖÖ·½·¨£¬ÔÚÕû¸ö¿ª·¢ÖÜÆÚ²»¶ÏÉè¼ÆºÍ½»¸¶Ð¡¶øÍêÕûµÄ²¿·Ö¡£µü´úÖÜÆÚ´Ó¼¸Öܵ½¼¸¸öÔ²»µÈ£¬Ã¿¸öµü´ú½×¶Î¶¼º­¸Ç´ÓÊÕ¼¯ÐèÇóµ½ÑéÊÕ²âÊÔµÄÕû¸ö¿ª·¢¹ý³Ì¡£
¾«ÒæÔ­ÔòËÄ£º»ñÈ¡ÐèÇó ÑÓ³Ù¾ö²ß
ÖÆÔìÐÐÒµ¹ýÈ¥³£³£ÈÏΪ£¬Èç¹ûÓªÏú²¿·ÖÄܹ»×¼È·Ô¤²âÊг¡ÐèÇóÄǸöàºÃ¡£µ«ºóÀ´·¢ÏÖÕâÖÖÏë·¨ÊDz»¶ÔµÄ£¬Ïà·´£¬Ó¦¸Ã´ó´óËõ¶ÌϵͳµÄÏìӦʱ¼ä£¬ÒÔ±ãϵͳÄܹ»¶Ô±ä»¯×ö³ö³ä·ÖµÄ·´Ó¦£¬´Ó¶øÅ×Æú¶ÔÔ¤²âµÄÒÀÀµ¡£ÆäʵIBMÄ¿Ç°ËùÍƹãµÄE£­Business On DemandÕýÊdzöÓÚÕâÑùµÄ˼·£¬¶ø´ËÇ°´÷¶ûµÄ³É¹¦Ò²ÊÇÓëÕâ¸öÀíÄî·Ö²»¿ªµÄ¡£
ʹÐèÇó±£³ÖÁé»îÐÔ£¬²¢¾¡¿ÉÄÜÌù½ü½»¸¶ÏµÍ³£¬½«ÎªÈí¼þ¿ª·¢Ìṩ¸üÇ¿µÄ¾ºÕùÓÅÊÆ¡£ÔÚÈí¼þ¿ª·¢µÄÔçÆڽ׶ÎÇö¨Éè¼ÆͬÑù´øÓÐÔ¤²âÐÔ£¬ËùÒÔÈí¼þϵͳµÄÉè¼ÆÓ¦¸ÃËæʱ²¶»ñеÄÐèÇ󣬲¢¶Ô±ä»¯×ö³öÏìÓ¦¡£
¾«ÒæÔ­ÔòÎ壺Âú×ã¿Í»§ÐèÇó
µ¼ÖÂÈí¼þÏîĿʧ°Ü×î³£¼ûµÄÔ­Òò¾ÍÊÇÐèÇó²»È«Ãæ»ò²»ÕýÈ·£¬Õë¶ÔÕâÖÖ·çÏÕ£¬Èí¼þ¿ª·¢ÉÌÔÚ¼ÌÐøÉè¼Æϵͳ֮ǰ£¬»á¾¡Á¿ÊÕ¼¯ÏêϸµÄÓû§ÐèÇó£¬È»ºóÓÉÓû§È·ÈÏ¡£
µ«ºÜ¶àÓû§ÔÚÈ·ÈÏÐèÇóÎĵµÊ±¾­³£»áÍÏÍÏÀ­À­£¬ËûÃǵ£ÐÄ×Ô¼ºÈϿɵÄÏîÄ¿µ½Í·À´»áÊǸö´íÎó£¬ËùÒԵȴýËûÃÇÈ·ÈÏÎĵµ»áÀË·Ñ´óÁ¿Ê±¼ä¡£´ÓÕâ¸ö½Ç¶ÈÀ´Ëµ£¬»ñµÃÓû§µÄͬÒâ·Çµ«²»ÄܹÄÀøÓû§²ÎÓ룬·´¶ø»áÔì³É¿ª·¢ÈËÔ±ºÍÓû§Ö®¼äµÄ¶ÔÁ¢¡£
׼ȷץסÓû§ÐèÇóµÄÓÐЧ°ì·¨¾ÍÊǽèÖúÓÚµü´úϵͳ¿ª·¢£¬¼°Ô翪·¢ºËÐÄÌØÐÔ²¢ÇÒͨ¹ýÿ¸öµü´ú½×¶ÎµÄ¿ÉÓÃÐÔÑÝʾ»ñµÃ¿Í»§·´À¡¡£  [Page]
¾«ÒæÔ­ÔòÁù£º½áºÏ·´À¡¡¡Ò»´Î×öºÃ
µ±ÔÚÉú²úÏßÉÏ·¢ÏÖÁÓÖʲúƷʱ£¬ºÜ¶àÖÆÔìÆóÒµ»á¶ÔÁÓÖÊÆ·½øÐзµ¹¤£¬µ«Ð§¹û²»¼Ñ¡£Ïà·´£¬Èç¹ûÔÚÕû¸öÖÆÔìÁ÷³ÌÖÐÔËÓòâÊԺͿØÖÆÊֶΣ¬È·±£Ã¿´ÎÒƽ»Ê±Ã¿¸ö²¿¼þ¶¼ÊǺϸñµÄ£¬ÕâÑù¾ÍºÜÈÝÒײéÃ÷²úÆ·ºÎʱƫÀëÁ˹æ¸ñ¡£
Òµ½çÒѾ­¹«ÈÏ£¬Èí¼þ½»¸¶ºóÕÒµ½ÎÊÌâ²¢ÐÞÕýµÄ³É±¾ÊÇÔçÆÚÉè¼Æ½×¶ÎµÄ100±¶£¬ËùÒÔÆóÒµÐèÒªÔÚ±àд³ÌÐò֮ǰÑéÖ¤ÏêϸÉè¼ÆµÄºÏÀíÐÔ¡£µ±È»Èí¼þµÄ¹æ¸ñÔÚ²»¶Ï±ä»¯£¬ÆóÒµÐèÒªÀûÓø÷ÖÖ¼¼ÊõÊֶ⻶ÏÊÊÓ¦±ä»¯¡£
¸÷ÖÖ²âÊÔ¼¼ÊõÊÇÕû¸ö¿ª·¢¹ý³ÌÖÐÊÊÓ¦±ä»¯µÄ×î¼ÑÊֶΡ£ÁíÒ»ÖÖÓ¦¶Ô±ä»¯µÄ¼¼Êõ¾ÍÊÇÔÙ¹¹£¬¼´Í¨¹ýÊܿصķ½Ê½¸Ä½øÏÖÓÐÈí¼þµÄÉè¼Æ£¬ÀûÓÃÔÙ¹¹£¬³õʼÉè¼Æ¿ÉÒÔרעÓÚÑÛÇ°µÄÎÊÌ⣬ÒÔºóÔÙ¿¼Âǽ«À´µÄÐèÇó¡£
¾«ÒæÔ­ÔòÆߣº¶ÔÔ±¹¤Ï·ÅȨÁ¦
Èç¹ûÈí¼þ¿ª·¢»·¾³²»ÈçÔ¤ÆÚ£¬Ö÷¹ÜµÄ±¾ÄÜ·´Ó¦ÍùÍùÊÇʵÐиüÑϸñµÄÁ÷³Ì£¬¸ü¼ÓÏêϸµØÃ÷È·Ô±¹¤ÈçºÎÍê³ÉÈÎÎñ¡£¾«ÒæÉú²úÔò½¨Òé²ÉÈ¡½ØÈ»Ïà·´µÄ·½·¨£¬Èç¹û¿ª·¢³öÏÖÁËÎÊÌ⣬²»ÒªÒý½øÍâÃæµÄר¼Ò£¬¶øÊÇΪԱ¹¤ÌṩÆÀ¹À¼°¸Ä½ø¸÷×ÔÁìÓòµÄ¹¤¾ß£¬¸øÓèÔ±¹¤×ã¹»µÄȨÁ¦£¬×îÖÕ×Ô¼º½â¾öÎÊÌâ¡£
¸ú¾«ÒæÉú²úÒ»Ñù£¬¾«Òæ±à³ÌͬÑùÖØÊÓÍŶӵÄЭ×÷¡£Èí¼þ¿ª·¢ÖÁÉÙÐèÒªÒ»´ÎÐÅÏ¢Òƽ»£¬¼´´ÓÓû§µ½±à³ÌÈËÔ±£¬µ«¸ü¶àµÄʱºò²»Ö¹Ò»´Î£¬±ÈÈç´ÓÓû§µ½Éè¼ÆÈËÔ±£¬ÔÙµ½±à³ÌÈËÔ±¡£Óй۵ãÈÏΪ£¬ÕâÀàÊéÃæÐÅÏ¢×îºÃÈ«²¿Òƽ»£¬µ«Êµ¼ÊÉÏÔÚÒƽ»Ö½ÃæÐÅϢʱ£¬»áÎÞÐÎÖжªÊ§´óÁ¿ÓÐЧÐÅÏ¢£¬¶øÈÃС×é³ÉԱЭͬ¹¤×÷ÔòЧÂÊÒª¸ßµÃ¶à£¬Í¬Ê±»¹¼õÉÙÁËÎÄÊ鹤×÷¡£
¾«ÒæÔ­Ôò°Ë£ºÈ¡Ïû¾Ö²¿ÓÅ»¯
ÔÚ¹ýÈ¥£¬²»ÈûúÆ÷Âú¸ººÉÔË×÷ÊÇÄÑÒÔ½ÓÊܵģ¬µ«ÔÚ¾«ÒæÉú²úÖÐÕâÈ´ÊǺÏÀíµÄ¡£
һЩÊܹýѵÁ·µÄÏîÄ¿¾­Àí»á·Ç³£¹ØעijЩ¾Ö²¿µÄ¹ÜÀí£¬ÕýÈçÖÆÔ칤ÈËÖÂÁ¦ÓÚ¾¡Á¿Ìá¸ß»úÆ÷µÄÉú²úЧÂÊÒ»Ñù¡£µ«¾«Òæ±à³ÌÊÇÊÜʱ¼äºÍ·´À¡µÄÇý¶¯£¬ËùÒÔ¾Ö²¿Éú²úÁ¦µÄÓÅ»¯»áÏ÷ÈõÕû¸öÖÆÔìÁ÷³Ì¡£ÔÚÓû§Ëù´¦»·¾³²»¶Ï±ä»¯µÄ½ñÌ죬Èç¹û°Ñ¾Ö²¿ÓÅ»¯·ÅÔڷdz£ÖØÒªµÄλÖã¬Äǵ±Óû§ÐèÇó·¢Éú±ä»¯Ê±£¬ËùÓÐÓÅ»¯¹¤×÷¶¼¸¶Ö®¶«Á÷¡£
Èç¹ûij¸ö¾Ö²¿µÄ¹¦ÄÜÓÐÒ»¶¨µÄ¿ò¼ÜÏÞÖÆ£¬Ö»ÒªËü²»»áÍÏÑÓ¹¤ÆÚ£¬¾Í²»±ØΪËüµ£ÐÄ¡£
¾«ÒæÔ­Ôò¾Å£ºÀûÓÃÖ𲽲ɹº
¹©Ó¦Á´²¢²»ÊÇÔÚ½ñÌì²Å²úÉú£¬Èù©Ó¦ÉÌÏ໥¾ºÕù£¬±£Ö¤ÒÔ×îµÍµÄ³É±¾»ñµÃÔ­²ÄÁÏÒ²ÊǺܳ£¼ûµÄ£¬µ«¾«ÒæÉú²úÓÖÒ»´Î¸Ä±äÁËÕâÖÖ¹ßÀý¡£ÃÀ¹ú¹ÜÀí´óʦW¡¤°®µÂ»ª×È¡¤´÷Ã÷ÈÏΪ£¬Ó빩ӦÉÌ»ùÓÚÐÅÀµµÄ¹Øϵ´´ÔìÁ˸øË«·½¹«Ë¾´øÀ´×î´óЧÒæµÄ»·¾³¡£
ÊÂʵ֤Ã÷£¬¼õÉÙ¹©Ó¦É̵ÄÊýÁ¿£¬ÆäºÏ×÷¹Øϵ¾ßÓиü¸ßµÄÖÊÁ¿¡£³¤ÆڵĺÏ×÷¹Øϵ¿ÉÒÔ°ïÖúÆóÒµ¸Ä½ø²úÆ·Éè¼Æ¼°Éú²úÁ÷³Ì£¬¶øÇÒ¼¸ºõÎÞÐèÎÄÊ鹤×÷¡£
ºÜ¶àÈí¼þÆóÒµÈÏʶµ½£¬´«Í³µÄÈí¼þ¿ª·¢ºÏͬÔì³ÉÁËÒþÐÔÀË·Ñ¡£¶ø¶ÔÈí¼þÓû§À´Ëµ£¬Ïà¶ÔÎȶ¨µÄÈí¼þ¿ª·¢ÉÌ¿ÉÒÔרעÓÚΪÓû§Ìṩ¸üÓÅÐãµÄÈí¼þ£¬²¢¿ÉÔÚ¿ª·¢Öо¡¿ÉÄܳٵØʹÐèÇóÎȶ¨ÏÂÀ´¡£¾«ÒæÔ­ÔòÊ®£ºµÞÔ쾫ÒæÎÄ»¯
Õâ¸öÔ­Ôò²»ÓýâÊÍҲһĿÁËÈ»£¬Èç½ñÓÅÐãµÄÈí¼þ¿ª·¢Òâζ×ÅÄܹ»²»¶ÏÊÊÓ¦±ä»¯¡£ÆäʵÔÚÀàËÆCMMµÄÄ£ÐÍÖÐȱ·¦¶Ô±ä»¯Ñ¸ËÙ×ö³öÏìÓ¦µÄÁé»îÐÔ¡£
´ÓijÖÖÒâÒåÉÏÀ´Ëµ£¬µü´úÏîÄ¿»·¾³³ÉÁËÔËÐл·¾³£¬ÒòΪÁ÷³ÌÖظ´³öÏÖ£¬¾Í¿ÉÒÔ°ÑÁ÷³Ì¸Ä½ø¼¼Êõ´ÓÒ»¸öµü´ú½×¶ÎÔËÓõ½ÁíÒ»¸ö½×¶Î¡£²»¹ýÎÒÃÇÐèÒªµÄ²»½ö½öÊǺ­¸Çij¸öÏîÄ¿µÄ¸Ä½øÄ£ÐÍ£¬Ö»ÒªÑ§Ï°ÏÖÓеÄÏîÄ¿£¬¾Í¿ÉÒԸĽøδÀ´ÏîÄ¿µÄÐÔÄÜ¡£  [Page]
µ½Ä¿Ç°ÎªÖ¹£¬¾«ÒæÉú²úµÄÊ®´óÔ­ÔòÒѾ­±»ÆÕ¼°µ½Á˶à¸öÐÐÒµ£¬°üÀ¨ÎïÁ÷¡¢¿Í»§·þÎñ¡¢Ò½ÁƱ£½¡¡¢½ðÈÚ¡¢½¨Öþ¡¢Èí¼þµÈÁìÓò¡£

2009-07-01

精益2009(1)-似曾相识

Filed under: 思想, 精益 — thomas @ 01:02

在去年的这个时候参加了《第三届敏捷中国技术大会》
相关报道:

http://www.agilechina.net/

http://subject.csdn.net/agile_lean.htm

http://news.csdn.net/n/20080519/116087.html

这次会议有两个收获,一是,见到书本上的人物Martin Fowler。二是,接触了敏捷思想和精益思维。

马先生头顶了有点秃,不如照片上面青年,也可能拍的比较早。软件开发者通常思考太多抽象问题,掉头发是比较普遍的,而大师想的就更多了,所以这也好理解。要不是读过他几本书,兴许还真把他当作一个普通老外了。虽然是这样,马先生精神还是不错的,讲起话来很连贯,讨论问题也相当机敏。

马先生的书相当不错,比如《UML精粹》,《重构-改善既有代码的设计》等等。语言通俗易懂,不耍文弄字,又能将把深刻的思想表现在简单的叙述之中,这样的作者着实不多。

另外是接触了敏捷思想和精益思维。当时听完几场讲座,逐渐想通了设计决策时机的问题。当然对于软件工程而言并不大,但很重要。推迟设计决策直到条件具备,看起来只是一个原则,如果配合单元测试、重构、持续集成等等的手段,那就能披荆斩棘,稳步向前了。敏捷经过这几年终于掀起一个潮流。

对“精益”总的印象是,是“敏捷”的源头,但是精益思维或者说精益思想到底是什么?一些讲师只是说,精益思想来自于制造业,那些大师,在主张敏捷之前,研习过“精益”方面的著作,吸取了很多宝贵的思想。给我的感觉是,武学高手在突飞猛进之前研究过《易筋经》一样。精益思想的口号是“消灭浪费”,然后提到一些制造也软件开发的相似之处,除此之外言之甚少。一般是开头会提几句,然后就是具体的软件开发的过程、工具和技术。

不过精益思想的口号对笔者而言并不陌生,笔者本科的专业就是机械,对于机械设计和制造有一些了解。后来因为机缘投身于软件开发。对于软件开发中“浪费”也颇有体会。所以对于精益思想与软件开发,还是留下一些疑问。在会后不久,初选了精益思想丛书中的《精益思想》、《精益之道》。但是并没有时间和心情来仔细阅读。

直到前不久,感冒在家歇息,百五聊赖之中,看到书架之中摆在上面的书,本该去年就看的书,竟然还没有仔细研读过。惭愧之余,便坐下来翻看。看过前言后就发现这个“小批量”和“大批量”的不同生产模式对比中竟然包含了深刻的思想。于是手不释卷读了将近200页。对于精益制造已经了解了很多,也比较容易接受,不过软件开发与机械制造毕竟是不一样的生产,那么在软件开发中运用精益思想有必须有哪些相关的过程、工具、技术、管理方式呢?搜索了一下,结果如下:
Results 110 of about 965 for “精益软件开发”. (0.18 seconds)
主要是一些书籍和一些经验贴。比起RUP而言,还不够成熟。即使“精益制造”在某些制造企业中已经很成熟了,不过总的比例还是比较低的。而基于精益思想的极限编程、SCRUM、敏捷方法在很多软件企业中还处于发展阶段。笔者在与以前的一些同事交流中,发现他们所在的公司实施的敏捷实践,存在很大的偏差。“精益软件开发”还只是初生牛犊。

Powered by WordPress