《人月神话》读后感*part1
Posted aming-
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了《人月神话》读后感*part1相关的知识,希望对你有一定的参考价值。
人月神话这本书大致讲述的是在程序项目过程中的管理及安排等。作者认为,在很多方面,管理一个大型的计算机编程项目和其它行业的大型工程很相似——比大多数程序员所认为的还要相似;在很多另外的方面,它又有差别——比大多数职业经理所认为的差别还要大。《人月神话》这本书就是围绕此展开的。
其实感觉这几部老师让看的书都大同小异。每个书又有每个书的特点。
从有程序项目伊始,大多数团队都开发出了可运行的系统。不过,其中只有非常少数的项目满足了目标、时间进度和预算的要求。软件开发这个职业就是这样,大型项目必须要有多人参与。当出现了一些错误,每个人的看法不同。这就导致了问题解决的的比较缓慢。这就与下面的“外科医生”板块相呼应。外科手术就是说,大型项目的每一个部分由一个团队解决,但是该队伍以类似外科手术的方式组建,而并非一拥而上。也就是说,同每个成员截取问题某个部分的做法相反,由一个人来进行问题的分解,其他给予他所需要的支持,以提高效率和生产力。这样就解决了问题的解决问题。只有一个人才可以决定大局,这样事情就变得简单起来。一个人下达命令,其他人跟从指令工作,工作层层递进的安排下去,每个人管自己的区域,这样项目才可以有序的执行。
在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还大。而导致这种普遍性灾难的原因有五点:
首先,我们对估算技术缺乏有效的研究,更加严肃地说,它反映了一种悄无声息,但并不真实的假设——一切都将运作良好。
第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互混淆。
第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工作。
第四,对进度缺少跟踪和监督。其他工程领域中,经过验证的跟踪技术和常规监督程序,在软件工程中常常被认为是无谓的举动。
第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。这就像使用汽油灭火一样,只会使事情更糟。越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。
当项目告急,增加人手并不是一个好的选择,新安排的人还需要了解项目,进行培训,这个时间投入是没有必要的。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手,实际上是延长了,而不是缩短了时间进度。应该在项目之前就对项目的安排时间作出规划。书中作者建议1/3 计划,1/6 编码,1/4 构件测试和早期系统测试,1/4 系统测试,所有的构件已完成。这样能更好的进行项目的实践。
项目的怎么才能完整?一个人一个想法也不行。概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。概念的完整性的确要求系统只反映唯一的设计理念,用户所见的技术说明来自少数人
的思想。实际工作被划分成体系结构、设计实现和物理实现,但这并不意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反,整个系统将会开发得更快,所需要的测试时间将更少。同工作的水平分割相比,垂直划分从根本上大大减少了劳动量,结果是使交流彻底地简化,概念完整性得到大幅提高。
以上是关于《人月神话》读后感*part1的主要内容,如果未能解决你的问题,请参考以下文章