人月神话，人件，最后期限 读后 (转)

人月神话，人件，最后期限 读后 (转)[@more@]

  这一段时间，看了三本经典的软件工程方面的书籍。《人件》，《人月神话》，《最后期限》。最先看的是《人月神话》，对我的思维冲击很大。我将其称为是继《设计模式》后对我冲击最大的书。后面的两本也都是经典之作。

  几本书都讲的是如果管理好一个项目。《人月》应该说最全面，也比较权威。其中关于计划，人员配置，增加人力，质量等有全面的描述。可以作为“项目经理速成”来看。《人件》让我们从开发人员心理学方面来看问题，把调动积极性，团队建设作为一个很重要的因素。记得我看完《人月》后，一个网友推荐我去看《人件》，二者相辅相成，的确很好。《最后期限》则独辟蹊径，以讲故事入手，讲如何控制好一个项目。不过，感觉这个项目还是有些理想化：他有充足的人力，包括大量可调配的程序员，以及各种优秀的专业人才。更加过分的是：他的项目都不需要需求分析，也不需要和客户的交流。哈哈，这样的项目恐怕很少吧。不过，的确也是一本好书。

相信其他人吧，一本可以被大家认可为经典的书，一定可以给你收获。

  看《人月》，我的感想，包括对精英团队的渴望，对质量控制的更加重视，对增加人手方面的思考。而《人件》，是对每个个体的充分尊重，人并不仅仅为了钱而工作，成就感，舒适。建议所有的老板都去看这本书。还有，听音乐编程，呵呵，编码的时候可以听，但作设计的时候不能听。而《最后期限》，不要给程序员太大的压力，那并不能改善工作。还有设计时期少数人，随着项目发展阶段性的增加人手。

  还是把几本书作为一个整体来分析吧，因为它们在我的脑袋中，已经互相融合了，呵呵。加上以前我对XP的一些认识，总结几条心得吧：

1， 质量是第一位的，不要为了赶进度而降低质量。

2， 作为项目经理，可能唯一的权利就是决定不做哪些功能（SCOpe）.

3， 迭代式开发，高频率内部发布。

4， 不到项目的最后阶段，绝对不要加班。

5， Play to win,not to avoid loss.

6， 较松散的Pair work,一个人基本了解另外一个人的工作。真正的Pair Work成本还是有些高。

7， 自动单元测试。（保证质量）

8， 不仅仅要做Code Review，在开始一个功能点的开发前，一定要进行设计评审，以免设计有缺陷或与其他部分有冲突。

9， 团队，交流，共同承担责任，不能指责某一个人。

10，  如果一个男生为主的团队，有一个PPMM来调节气氛也很不错，呵呵。这一条是我为了凑构整数加上去的。

XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

其实，这一段时间，我看的最主要的书是《Refactoring》，不过现在还没有看完。上周我的业余时间都贡献给了唐浩明的《曾国藩》，觉得曾国藩那么辛苦，终于位极人臣，也善始善终，可他还是很不爽，一辈子快乐得意的日子没有几天。反而不如胡一刀，我前一段也抽时间重新看了一遍《雪山飞狐》，觉得胡一刀夫妇的真挚感情与江湖豪情真是令人神往。我这辈子是没有希望了，但愿我的儿子能出类拔萃，如胡一刀一般潇洒任物，不要像曾国藩那样为功名所累。我的儿子不知道多少年后才出现。：）

“小事以速办见长，大事往往因草率而致误”。这是曾国藩中给我印象最深的一句话。对IT业也适用，我们的领导们在启动一个项目时可以想想这句话。

  笔随心动，不知所云。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752019/viewspace-962448/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752019/viewspace-962448/