论“软件工程”中的分工有效吗?

发表于:2007-05-26来源:作者:点击数: 标签:
论“软件工程”中的分工有效吗? NetReptile推荐[2005-2-20] 出处:cci .net 作者:www.InnovateDigital. "软件工程"是指我们在学校中学习的那些理论,经过多年的开发实践和技术交流中,我们不断在对传统的软件工程理论进行反思。 问题的提出 在将软件开发分

论“软件工程”中的分工有效吗?


NetReptile推荐 [2005-2-20]
出处:clearcase/" target="_blank" >cci.net
作者:www.InnovateDigital.
 

"软件工程"是指我们在学校中学习的那些理论,经过多年的开发实践和技术交流中,我们不断在对传统的软件工程理论进行反思。

问题的提出

在将软件开发分为3个阶段(需求分析、设计和编程)时,我们很自然地会提出一个问题,"软件开发者应该继续提高专业化程度吗?"毕竟,劳动的分工是工业革命的基础。正是由于将制造业分解成多个精确定义的小任务,一组工人的生产率才能得到突飞猛进。所以,我们想当然地认为:对于软件开发,这种"专业化"的方式也将同样有效。

这看起来显而易见,不是吗?让一些人成为专业的分析师,专门获取和记录用户的需求;让一些人成为设计师,负责从需求文档制造出设计规格文档;程序员则负责根据设计规格进行编码。很显然,这应该是一种更加高效的工作方式,不是吗?答案是否定的。

问题的分析

1. 忽略了沟通的成本

同一件任务被切分而成的小步骤越多,人与人之间传递信息所耗费的时间总量就越多。因此,在不需要大量交流工作中(例如制造业中的很多体力劳动)中,流水式生产线能够运转得很好;但在需要大量交流的脑力劳动(尤其是软件开发)中,这种方式一败涂地。

软件开发的绝大部分工作都是在团队成员的头脑中完成的。如果要强迫每个人专门从事某一项特定的工作,那么任何一个简单的项目都会需要传递更多额外的中间产品。每一次的传递都可能带来潜在的错误和缺陷,因此,每次传递都是相当昂贵的。没错,如果要求每个人都编写大量的文档,以降低其他人作出错误理解或假设的风险,我们当然可以将"由于交流而出错"的可能性降到最低。但是,"编写更多文档"的工作量同样也是计算在项目的开销中的。正如Fred Brooks所指出的,如果决定某项任务成败的因素是项目组成员之间的交流效率,那么加入更多的人就只会延缓项目的进展。

当同一个开发者对需求、设计和源代码都有着深入的理解时,软件开发就能够获得最好的效果。Steven Levy所采访的所有黑客都是独自进行设计和编码的。在对"影响了(个人)计算机产业的19个程序员"的采访中,Susan Lammers也提到了同样的现象。在这些伟大的程序员中,没有任何一个使用过软件工程风格的分工方式,他们通常都是独自深入整个设计和编码工作。很有趣的是,他们几乎每个人都有自己独特的工作风格。

2. 导致混乱

将传统的劳动分工强加于软件开发,结果是导致分析师、设计师、程序员、测试员、用户界面专家、文档工程师、技术支持工程师之间不断地传递信息。过多的交流极大地降低了效率,项目被不断拖延。任何一点变化出现时,都必须将信息沿整条开发链传递下去,并导致一片混乱。项目结束后不久,软件就变成了"遗留系统",因为没人清楚它究竟时如何工作的。

软件工程对技术进行人为的细分,结果导致任何一个人都不可能了解整个应用程序。软件工程解决这个问题的办法不是再开发者之间进行交叉培训,让他们了解全局,而是不断强调文档的神话-良好的文档能让任何人理解整个应用程序。不幸的是,尽管文档能够很好地记录软件中的抉择和协议,但却无法有效地保留、传递关于具体问题的详细信息,而这些具体细微的知识才是最重要的。

软件工程的另一个贻害是:它把文档搞得声名狼藉。很多项目实际上根本没有任何文档,因为年轻的开发者们本能地拒斥这种"软件工程的产物"。

3. 缺乏科学量化的手段

"科学管理"用科学取代了经验法则。在"科学管理"的方法中,数字支配一切。如果要改进什么东西,你首先必须对它进行度量。如果什么东西不能被度量,就不可能对它进行改进。管理者知道一切。任何工作都必然有一条最佳途径。

所以,看到软件工程师发明了许许多多软件开发的度量方法,我们也就不会觉得太惊奇了。甚至,由"科学管理"带来的"时间-动作研究"(time-and-motion study)已经被用于研究软件的使用情况了。在某些特定的问题上,人们已经规定出一些定量法则,例如将光标移动到按钮上需要多长时间(Fitts 法则)、在概率相当的行为之间作出选择需要多长时间(Hick法则)等等。

在对量化管理的狂热之中,人们常常忽视了机械活动与智力活动之间的差异。Fitts法则主要时针对机械活动的-尽管移动鼠标、点击按钮的动作需要眼睛和手的协调,但它仍然只是一个(比较复杂的)机械活动。Hick法则则试图度量人大脑中的活动。这正是软件工程犯下的一个经典错误:它认为能够度量的东西时最重要的,但情况并非如此。

从根本上来说,软件开发还是一项智力活动。打字的速度从来不是、也永远不可能是软件开发的瓶颈。要谈论一项智力活动,唯一的方式就是通过不精确的讨论,因为你能度量的东西对于提升效率根本无济于事。软件工程之所以有害,因为它忽视了开发者之间讨论的价值-而那是我们理解软件开发、提高开发效率的唯一途径。

软件工厂总是表现出一种倾向:它们试图模仿制造业从前的模式。但是,就连制造业也在不断发展。现在,哪怕是最热衷于生产线的人也早已不再谈论"完全集成的制造业"了。如今,汽车企业不再拥有钢铁工厂、煤矿和橡胶种植园。他们不再自己制造轮胎,而是向擅长制造轮胎的企业购买轮胎。对于软件组件,道理也是一样:借助于唾手可得的组件,小型团队也可以开发出优秀的软件。

"软件工厂"的概念没有真正流行,因为软件的制造实在太容易了。如何与用户协作、交流,创建一个良好的设计,并使其不断演进发展,这才是软件业中真正的难题。

忠告

如果你的项目拥有实际上无限的资源,那么软件工程就是一条有效的软件开发途径。但是,如果你的资源有限,如果你养不起数百名软件工程师,请及时放弃软件工程。你必须认识到:软件开发更多地是一项智力的、社会性的工作,而非机械性的工作。认识到这一点之后,你将可以从软件工程中学到有用的东西。

 

原文转自:http://www.ltesting.net