标签：
人月神话感想
在阅读这本书之前,已经很多次听到关于人月神话这本书以及他的作者Brooks的消息了. 在软件领域, 《人月神话》具有深远影响力而且畅销不衰.这一次,正好老师的作业要求我们阅读这本书,我终于使有机会阅读这本经典之作了.在这过去的几个星期里面,一点一滴的阅读这本书,粗略的了解了这本书.
首先,让我印象深刻的是《人月神话》提出的两条著名的法则：
1.人月神话：向一个已经延后的项目中投入更多的人力资源只会让它更延后。
人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法. 当读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。这让我明白了一个重要的道:理项目的进度是不能够光靠人力的增加来推进的.
2.没有银弹:没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
虽然现在有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。
这两个原则已经在过去的几十年间得到了验证.我相信在未来,它以依旧是成立的.
另外,在焦油坑那一章里面,有一句话让我难以忘怀:岸上的船,如同海上的灯塔,无法移动.
是呀, 过去几十年的大型 系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理解它。 这就是生活真理。要想解决一件事，首先要了解事情的始末。提出问题就是解决问题的答案。
人月神话还让我了解到, 软件系统可能是人类创造中最错综复杂的事物.往往一个很小的功能，实在也需要开发职员的架构设计方面的完善，对 其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发职员昼夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素.
总而言之，《人月神话》是一部IT界的神话，经久不衰.它就像是一颗“银弹”，教会我们如何去消灭软件项目这只“人狼”，指引着每个IT从业者认真开发,开拓进取.人月神话将带领IT界的精英们创造一个又一个IT界的神话.
.
标签：
原文地址：http://www.cnblogs.com/double1/p/4300505.html
