《人月神话》经典观点整理(之一):哪些过时了,哪些还有效?

下面的文章是第一章和第二章的主要观点,后续章节的我回头再发。看这篇文章能够迅速了解Brooks的思想。
 
另外一个需要大家仔细考虑的就是,Brooks的《人月神话》是在几十年前写的,在软件行业发展这么多年后,各方面的情况都发生了翻天覆地的变化,那么,Brooks的哪些观点已经不符合当前的情况了呢?我们又能提出哪些新问题,作为对《人月神话》的一个与时俱进的补充呢?
 
 
第1章 焦油坑 

1.1 编程系统产品(Programming Systems Product)开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量,将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量,这些高成本的构件在根本上是相互独立的。 
 
<我自己的拙见:在现在这个时代了,已经不止是9倍了,业务的复杂度大大提升,产品和程序的距离也是越拉越大>
 
1.2 编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”,提供了五种乐趣: 
  • 创建事物的快乐 
  • 开发对其他人有用的东西的乐趣 
  • 将可以活动、相互啮合的零部件组装成类似迷宫的东西,这个过程所体现出令人神魂颠倒的魅力 
  • 面对不重复的任务,不间断学习的乐趣 
  • 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动,其存在、移动和运转方式完全不同于实际物体 
1.3 同样,这个行业具有一些内在固有的苦恼: 
  • 将做事方式调整到追求完美,是学习编程的最困难部分 
  • 由其他人来设定目标,并且必须依靠自己无法控制的事物(特别是程序);权威不等同于责任 (我的拙见:一言道尽编程里最困扰人的事情)
  • 实际情况看起来要比这一点好一些:真正的权威来自于每次任务的完成 ?? 任何创造性活动都伴随着枯燥艰苦的劳动,编程也不例外 
  • 人们通常期望项目在接近结束时,(bug、工作时间)能收敛得快一些,然而软件项目的情况却是越接近完成,收敛得越慢 (我的拙见:无奈吧,这是规律)
  • 产品在即将完成时总面临着陈旧过时的威胁 (我的拙见:这一句说得真好)
第2章 人月神话 

2.1 缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来影响还大。 

2.2 良好的烹饪需要时间,某些任务无法在不损害结果的情况下加快速度。 
 
2.3 所有的编程人员都是乐观主义者:“一切都将运作良好”。 

2.4 由于编程人员通过纯粹的思维活动来开发,所以我们期待在实现过程中不会碰到困难。 

2.5 但是,我们的构思是有缺陷的,因此总会有bug。 

2.6 我们围绕成本核算的估计技术,混淆了工作量和项目进展。人月是危险和带有欺骗性的神话,因为它暗示人员数量和时间是可以相互替换的。 
(这是这本书的一个核心观点)

2.7 在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。 

2.8 关于进度安排,我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。 

2.9 作为一个学科,我们缺乏数据估计。 
 
2.10因为我们对自己的估计技术不确定,所以在管理和客户的压力下,我们常常缺乏坚持的勇气。 

2.11 Brook法则:向进度落后的项目中增加人手,只会使进度更加落后。 
(这是这本书的一个核心观点)
2.12向软件项目中增派人手从三个方面增加了项目必要的总体工作量:
  • 任务重新分配本身和所造成的工作中断;
  • 培训新人员;
  • 额外的相互沟通。 
阅读更多
换一批

没有更多推荐了,返回首页