读《人月神话》之我见

原创 2003年05月08日 14:18:00

    《人月神话》中,作者Brooks以“焦油坑”类比大型软件项目的开发,从自身所经历的大型软件项目的开发与管理的工作入手,详尽的分析并论述了软件工程中所面临的问题与解决方案。本书并不涉及任何技术细节,正如作者在“20年后的人月神话(The Mythical Man-Month after 20 Years)”一章中所说的,本书之所以时至今日,仍能历久不衰的原因就是:《人月神话》是关于人与团队的书,所以淘汰的程度才会如此缓慢。以下将就个人的理解,浅谈以下《人月神话》中的精华所在。

概念完整性和结构师是《人月神话》的核心观点或核心概念。一个整洁、优雅的软件产品必须向他的用户提供一个完整的概念模型,而这个概念模型使得用户能够很好的了解产品的功能结构、使用以及界面的设定。概念完整性是关系到软件产品的易用性的最重要的因素,也是关系的软件开发流程和产品成败的重要因素。软件产品的概念完整性由谁负责实现?毫无疑问,结构师负责产品所有方面的概念完整性,所以,委派一名系统结构师对于软件开发来说,是最重要的行动。

结构师的工作就是,设计系统的体系结构模型或产品概念模型,包括所有功能的详细说明及调用和控制的方法。对于设计的概念模型,结构师将利用文档对之进行详细地描述和说明,开发团队的每一个人都将拥有这样一份文档说明。当然,团队中的每一个人都可以在举行的讨论会议中抒发个人意见,结构师在吸收有用的意见后,对文档进行调整更新,以确保系统在各方面的设计都是尽善尽美的,以及每一位开发人员都拥有最新的文档,这样的过程将贯穿于整个开发流程,同时,结构师具有绝对的权威,对于会影响到系统概念完整性的想法或新增功能坚决予以排除,在涉及技术方面的问题时,项目经理也要完全服从结构师的意见。如果某些功能不得不加入,但又会影响系统的概念完整性,那么,结构师就不得不考虑调整或推翻已有的设计。

概念完整性在小规模的开发团队中很好控制,对于大型的项目开发,则必须通过树状组织结构,层层控制,除了总结构师外,可以为每一个开发小组指定一名结构师,总结构师可以通过小组内的结构师传达意图或控制开发系统概念完整性,整个团队的组织结构可以仿照外科手术队伍组织。

除此之外,软件开发过程中,时间延迟也是一个不容忽视的问题。Brooks在《人月神话》中提出了一个著名的论断:(盲目地)“向进度落后的项目中增加人手,只会使进度更加落后。”(Adding manpower to a late software project makes it later. 。开发人员的数量与开发所用的时间之间的关系,并不是线性的,其中还参杂了沟通和培训等主观因素的存在。那么,对于时间延迟应该如何解决呢?首先,要在项目开始前,利用项目经理的经验,对系统开发流程中的每一个步骤,做出大胆充分的估计,即使是毫无根据的估计也比不做估计而凭假想制定计划好得多。在此基础之上制定出项目进度表,进度表中的每一件事——“里程碑”,必须是具体的、特定的、可度量的事件,能够进行清洗的定义。此外,可在开发团队之外,设立计划和控制小组,该小组的主要职责就是向产品线经理询问什么时候设定和更改里程碑,以及里程碑是否被到达。计划和控制小组作为监督人员,明白地指出了不易察觉的延迟,并强调关键的因素。他们是早期预警系统,防止项目以一次一天的方式落后一年。 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

系统测试也是我们需要关注的要点。在开发过程中,系统测试是随着开发团队工作的开始而开始的,在编写代码之前,测试小组就要对规格说明进行测试,以详细的检查说明的完整性和明确性。开发人员自己不会完成这项工作:“他们不会告诉你他们不懂。相反,他们乐于自己摸索出解决问题和澄清疑惑的办法。” 随着开发进程的进行,首先要对所完成的部分进行构件单元测试,以使问题保留在较小的范围内,这样比较容易处理。最后,才是系统集成调试。如果不按照这样的方式进行测试,那么在最后的系统集成调试中出现的任何问题,都将是致命的。这就意味着前面的付出都被白白的浪费掉了。

Brooks认为,传统的瀑布开发模型是错误的。“瀑布模型的基本谬误是它假设项目只经历一次过程,而且体系结构出色并易于使用,设计是合理可靠的,随着测试的进行,编码实现是可以修改和调整的。换句话说,瀑布模型假设所有错误发生在编码实现阶段,因此它们的修复可以很顺畅地穿插在单元和系统测试中。”并提出了比较先进的开发模型——增量开发模型,“为舍弃而计划。”通过渐进的精华的迭代开发过程,对原型系统不断否定和完善,最终实现开发目标。我想,这一点对于任何开发人员来说都是深有感触地,任何一个系统,即使是天才,也不可能一次性的成功地完成开发。

最后,软件工程中并不存在“银弹”,即所谓的尚方宝剑,到目前为止,即使软件工程理论取得了长足的进步,也不能从跟上解决软件开发过程中所谓的内在的、必然的问题:复杂性、一致性、多变性、不可见性。现行的众多技术,只能解决一些边缘问题,对于这些本质的问题,还是望尘莫及的。对于这一点,还存在着众多的争论

《人月神话》中所蕴含的软件工程理论都是非常优秀的,以上仅是本人针对自身所参加过的项目开发,在读过本书之后的一点理解与体会。有不当之处,望不吝指正!

杀不死的人狼——我读《人月神话》(一)

=====前言=====在这与这段文字之前,我已经阅读过种种关于《人月神话》的文字。评论者既有刘天北这样的美食家,试图在书页中夹点胡椒面以慢慢品味,为了表现食客特有的风格,他的书页都比别人数得仔细。也...
  • aimingoo
  • aimingoo
  • 2007年03月12日 03:08
  • 11778

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

下面的文章是第一章和第二章的主要观点,后续章节的我回头再发。看这篇文章能够迅速了解Brooks的思想。   另外一个需要大家仔细考虑的就是,Brooks的《人月神话》是在几十年前写的,在软...
  • joeyon
  • joeyon
  • 2015年03月06日 11:28
  • 963

读《人月神话》

所谓人月(Man-Month),是软件开发中工作量的度量,然而它却不是线性的,10个人10个月可以完成的工作,很多情况下100个人并不能在1个月完成。读完《人月神话》一书,我的理解与摘抄:当人数增多时...
  • liuyuan185442111
  • liuyuan185442111
  • 2015年08月12日 12:05
  • 441

人月神话解读与感受

在研究生期间我们的课程设置中有一门必修课程是软件工程,其中有一个作业是读人月神话并写一篇读后感。虽然我本科的专业是偏向于网络工程,并且我们也开设过软件工程这门课。但是对于像我这样的二流选手,在本科期间...
  • DaveBobo
  • DaveBobo
  • 2016年04月11日 17:45
  • 3539

【书评】人月不必再相望,嫦娥已然在身旁——人月神话(40周年纪念版)

参与活动主题《人月神话(40周年纪念版)再版 扒一扒你遇到过最NB开发项目》有奖活动,三重惊喜,有奖试读&作者互动@关注有礼!为什么是《人月神话》?这本书在业界真的很名,几乎无人不知,然而我却只知其名...
  • testcs_dn
  • testcs_dn
  • 2015年06月21日 15:17
  • 2922

《人月神话》阅读心得

巴比伦塔的失败启示 ——《人月神话》读后感 12330227 计应2班 吕顺   初读人月神话,我就深深地被其中所涉及到的软件开发中遇到的各种难题和解决对策所折服。坐着布鲁克斯用一种高瞻远瞩的视角详细...
  • lv0525
  • lv0525
  • 2015年05月17日 18:57
  • 437

《人月神话》一句话总结各章核心观点

第1章 焦油坑:提出软件产品现在处于进度和质量焦油坑当中,难以摆脱。 第2章 人月神话:人月估算法是错误的,这会暗示人月可互换,这种方式严重的忽视了一个重要的成本,沟通成本。 第3章 外科手术队伍...
  • u010266093
  • u010266093
  • 2014年06月03日 15:45
  • 802

《人月神话》经典摘录

1 “人月”的欺骗 人们通常期望项目在接近结束时,软件项目能收敛的更快一些。然而,情况却是越接近完成,收敛得越慢。 产品在完成前总面临着陈旧过时的威胁,只有实际需要...
  • ruoyiqing
  • ruoyiqing
  • 2014年08月23日 11:26
  • 739

FEC之我见一

顾名思义,FEC前向纠错,根据收到的包进行计算获取丢掉的包,而和大神沟通的结果就是 纠错神髓:收到的媒体包+冗余包 >= 原始媒体包数据    直到满足 收到的媒体包+ 冗余包 >= 原始媒体包数据...
  • zjqlovell
  • zjqlovell
  • 2016年03月25日 12:08
  • 772

KMP算法之我见:从运动角度理解next数组

人说MKP算法是最适合算法入门的了,可是它的next数组理解起来似乎不是那么容易,说真的它有点像C语言,入门有点难,但是只要理解了其中的精髓,你会发现并不禁惊叹“哦,真是太美妙了” 说明:本文,n...
  • abc_12366
  • abc_12366
  • 2018年02月01日 23:58
  • 96
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:读《人月神话》之我见
举报原因:
原因补充:

(最多只允许输入30个字)