25年来,软件工程的发展不可同日而语,可做软件项目的精华思想确实没有多大的改变。---这仅仅是个人的看法。假如做了几个项目再回头来读读这本书,可能很多有亲身的体会。比如说:软件项目的乐趣所在,软件项目中的时间管控题目,软件项目中的资源配置题目,这些都很实在,很朴素,可是我们却总不能很好地往做好它,往管控整个项目.大到一个贸易系统,小到一个模块,实在都存在一个做项目的思想,可现实中我们很难做到这点。我读此本书个人的一些体会:1.是什么让我大学毕业便抛弃自己专业踏进IT的之路?爱好,对编程的乐趣,当别人使用你做的系统或软件时那种成就感。这就是如书中所言:职业的乐趣所在:创建事物的快乐,开发对他人有用的东西,将零散的文字组装成一个有用的东西,不断学习的乐趣,创造性的工作。 这些确实是吸引我一直在这路上奔波的东西。2.是什么困扰我们的项目不能按时交付的因素?缺乏公道的时间进度管控是造成项目滞后的主要原因。 有些时候对于乐观,有些时候过于妥协,经常缺乏坚持。做了几个项目,发现自己在时间管控方面需要努力,当然,客户的不确实需求因素也经常会左右我的决定--究竟,在企业做IT项目与纯粹的软件公司做软件项目有不一样的地方。3.很多项目的失败,是由于彼此之间缺乏沟通以及交流的结果这点我深有体会,由于我吃过大亏。很多时候在制造性企业做IT,客户的前期需求有很大的不确定性,可能在开始时大家都以为说的是同一个事儿,但当做出来之后客户发现与自己想像的相差太远。同时,用户在操纵上的习惯题目也会成为一个不能忽视的因素,这也应该算作是需求的一部分吧。用户与开发项目组假如不在需求上认真“较真”,那以后的题目就会不断涌来了。这些需要靠什么往约束呢?靠文档,靠白字黑字的文档。4.软件系统可能是人类创造中最错综复杂的事物往往一个很小的功能,实在也需要开发职员的架构设计方面的完善,对其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字,实际是中开发职员昼夜奋战的结果。很多时候,客户的需求修改,在他们眼里看起来是如此地asy,可他们却忽视了很多他们看不到的因素---当然,这不是说怪我们的客户。我只是觉得,只有大家彼此沟通,彼此理解,才会做出精品来。
[《人月神话》读后感2]