1,268
社区成员
发帖
与我相关
我的任务
分享《人月神话》《人件》《最后期限》读后
这一段时间，看了三本经典的软件工程方面的书籍。《人件》，《人月神话》，《最后期限》。最先看的是《人月神话》，对我的思维冲击很大。我将其称为是继《设计模式》后对我冲击最大的书。后面的两本也都是经典之作。
几本书都讲的是如果管理好一个项目。《人月》应该说最全面，也比较权威。其中关于计划，人员配置，增加人力，质量等有全面的描述。可以作为“项目经理速成”来看。《人件》让我们从开发人员心理学方面来看问题，把调动积极性，团队建设作为一个很重要的因素。记得我看完《人月》后，一个网友推荐我去看《人件》，二者相辅相成，的确很好。《最后期限》则独辟蹊径，以讲故事入手，讲如何控制好一个项目。不过，感觉这个项目还是有些理想化：他有充足的人力，包括大量可调配的程序员，以及各种优秀的专业人才。更加过分的是：他的项目都不需要需求分析，也不需要和客户的交流。哈哈，这样的项目恐怕很少吧。不过，的确也是一本好书。
相信其他人吧，一本可以被大家认可为经典的书，一定可以给你收获。
看《人月》，我的感想，包括对精英团队的渴望，对质量控制的更加重视，对增加人手方面的思考。而《人件》，是对每个个体的充分尊重，人并不仅仅为了钱而工作，成就感，舒适。建议所有的老板都去看这本书。还有，听音乐编程，呵呵，编码的时候可以听，但作设计的时候不能听。而《最后期限》，不要给程序员太大的压力，那并不能改善工作。还有设计时期少数人，随着项目发展阶段性的增加人手。
还是把几本书作为一个整体来分析吧，因为它们在我的脑袋中，已经互相融合了，呵呵。加上以前我对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来调节气氛也很不错，呵呵。这一条是我为了凑构整数加上去的。
其实，这一段时间，我看的最主要的书是《Refactoring》，不过现在还没有看完。上周我的业余时间都贡献给了唐浩明的《曾国藩》，觉得曾国藩那么辛苦，终于位极人臣，也善始善终，可他还是很不爽，一辈子快乐得意的日子没有几天。反而不如胡一刀，我前一段也抽时间重新看了一遍《雪山飞狐》，觉得胡一刀夫妇的真挚感情与江湖豪情真是令人神往。我这辈子是没有希望了，但愿我的儿子能出类拔萃，如胡一刀一般潇洒任物，不要像曾国藩那样为功名所累。我的儿子不知道多少年后才出现。：）
“小事以速办见长，大事往往因草率而致误”。这是曾国藩中给我印象最深的一句话。对IT业也适用，我们的领导们在启动一个项目时可以想想这句话。
笔随心动，不知所云。
几本书都讲的是如果管理好一个项目。《人月》应该说最全面，也比较权威。其中关于计划，人员配置，增加人力，质量等有全面的描述。可以作为“项目经理速成”来看。《人件》让我们从开发人员心理学方面来看问题，把调动积极性，团队建设作为一个很重要的因素。记得我看完《人月》后，一个网友推荐我去看《人件》，二者相辅相成，的确很好。《最后期限》则独辟蹊径，以讲故事入手，讲如何控制好一个项目。不过，感觉这个项目还是有些理想化：他有充足的人力，包括大量可调配的程序员，以及各种优秀的专业人才。更加过分的是：他的项目都不需要需求分析，也不需要和客户的交流。哈哈，这样的项目恐怕很少吧。不过，的确也是一本好书。
相信其他人吧，一本可以被大家认可为经典的书，一定可以给你收获。
看《人月》，我的感想，包括对精英团队的渴望，对质量控制的更加重视，对增加人手方面的思考。而《人件》，是对每个个体的充分尊重，人并不仅仅为了钱而工作，成就感，舒适。建议所有的老板都去看这本书。还有，听音乐编程，呵呵，编码的时候可以听，但作设计的时候不能听。而《最后期限》，不要给程序员太大的压力，那并不能改善工作。还有设计时期少数人，随着项目发展阶段性的增加人手。
还是把几本书作为一个整体来分析吧，因为它们在我的脑袋中，已经互相融合了，呵呵。加上以前我对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来调节气氛也很不错，呵呵。这一条是我为了凑构整数加上去的。
其实，这一段时间，我看的最主要的书是《Refactoring》，不过现在还没有看完。上周我的业余时间都贡献给了唐浩明的《曾国藩》，觉得曾国藩那么辛苦，终于位极人臣，也善始善终，可他还是很不爽，一辈子快乐得意的日子没有几天。反而不如胡一刀，我前一段也抽时间重新看了一遍《雪山飞狐》，觉得胡一刀夫妇的真挚感情与江湖豪情真是令人神往。我这辈子是没有希望了，但愿我的儿子能出类拔萃，如胡一刀一般潇洒任物，不要像曾国藩那样为功名所累。我的儿子不知道多少年后才出现。：）
“小事以速办见长，大事往往因草率而致误”。这是曾国藩中给我印象最深的一句话。对IT业也适用，我们的领导们在启动一个项目时可以想想这句话。
笔随心动，不知所云。
...全文
请发表友善的回复…
发表回复
rain_99 2003-11-04
- 打赏
- 举报
snail_8888(蜗牛)，ftp://flyinpig.bingle.org.cn/pub/ebook/用户名和密码能否公布一下？
sysmystery 2003-11-03
- 打赏
- 举报
学习
jkxt1234567 2003-10-12
- 打赏
- 举报
very good
jlsg 2003-09-09
- 打赏
- 举报
前两本都看过，感触颇多。
干这行的都希望完成理想的东西，但是却是最终的梦想。
书中说得都对，但是按着做了只能是死去。
必须有策略才可以，任何教条都是不对的。
干这行的都希望完成理想的东西，但是却是最终的梦想。
书中说得都对，但是按着做了只能是死去。
必须有策略才可以，任何教条都是不对的。
gselec 2003-09-08
- 打赏
- 举报
自己做不到的，寄希望于下一代，中国人的通病。
猛禽 2003-09-05
- 打赏
- 举报
这个CSDN又出错了，再打一遍吧。
我不是要反对《人件》中的观点，只是想指出：完全的自治只能是 Mission Impossible 。再高明的厨师也不可能满足所有食客的味觉需求，所谓“众口难调”
我不是要反对《人件》中的观点，只是想指出：完全的自治只能是 Mission Impossible 。再高明的厨师也不可能满足所有食客的味觉需求，所谓“众口难调”
someonehappy 2003-09-05
- 打赏
- 举报
我还没有看过这些书，正准备买来看。我不知道书里面具体如何把开发比作做饭的，但是就算是做饭给别人吃，也不见的就如楼上的（Raptor(猛禽)）所说得那样，肯定达不到自治的目标。
如果比作做菜，那么专业的程序员应该是属于厨师，他们的工作就是做菜，当然不是做给自己吃的（自己吃饭时候做的除外）。如果一个人热爱自己的工作，并且心情愉快的话，那么肯定能做到开心的为他人提供美食。
当然我觉得真正不用管理完全靠自治来达到那些目标确实太理想化了，应该属于终极目标，实际上应该很难做到，特别在现在的中国。
如果比作做菜，那么专业的程序员应该是属于厨师，他们的工作就是做菜，当然不是做给自己吃的（自己吃饭时候做的除外）。如果一个人热爱自己的工作，并且心情愉快的话，那么肯定能做到开心的为他人提供美食。
当然我觉得真正不用管理完全靠自治来达到那些目标确实太理想化了，应该属于终极目标，实际上应该很难做到，特别在现在的中国。
caton2 2003-07-30
- 打赏
- 举报
《设计模式》，我应该整体看过三遍以上。每一次看都会有新的感触。
特别是与遇到的实际问题要使用某个模式的时候也要再翻翻书，
感觉收获更大。它一直放在我手边。
说起设计模式，我觉得对规模变软件越大的软件，作用会更加明显。
因为小软件，怎么做都可以控制住，用不用模式都无所谓。
其实所谓很多的编程约定规范，（例如现在越来越深入人心的面向接口编程）
都是在软件规模变大后作用才会特别明显的。
我前几天把“Refactoring”看完了，推荐大家也都去看一下。虽然是英文
版，但使用的基本是“中学英语”，读起来感觉不吃力。
“Refactoring”号称是与“设计模式”齐名的，我觉得它对得起这个称号。
特别是与遇到的实际问题要使用某个模式的时候也要再翻翻书，
感觉收获更大。它一直放在我手边。
说起设计模式，我觉得对规模变软件越大的软件，作用会更加明显。
因为小软件，怎么做都可以控制住，用不用模式都无所谓。
其实所谓很多的编程约定规范，（例如现在越来越深入人心的面向接口编程）
都是在软件规模变大后作用才会特别明显的。
我前几天把“Refactoring”看完了，推荐大家也都去看一下。虽然是英文
版，但使用的基本是“中学英语”，读起来感觉不吃力。
“Refactoring”号称是与“设计模式”齐名的，我觉得它对得起这个称号。
guoxyj 2003-07-30
- 打赏
- 举报
我也作过项目，酸甜苦辣呀
理想的软件工程，从来没有经历过
资金、工期、能力等等原因，总觉项目做的不够爽，虽然我做的项目现在都还在使用，效果也还算可以，感觉也是费了好大的劲才达到目的。
现在暂时告别软件公司，静下心来，从头学起，看了不少项目管理和软件工程的书，收获颇丰，以前比较模糊的东西一下子清晰了许多。比如项目成本的计算、计划的制定、风险的分系和规避等等。
有时候，静下心来学习理论，会有助于自己的实践，不知道大家有没有这个感触。
理想的软件工程，从来没有经历过
资金、工期、能力等等原因，总觉项目做的不够爽，虽然我做的项目现在都还在使用，效果也还算可以，感觉也是费了好大的劲才达到目的。
现在暂时告别软件公司，静下心来，从头学起，看了不少项目管理和软件工程的书，收获颇丰，以前比较模糊的东西一下子清晰了许多。比如项目成本的计算、计划的制定、风险的分系和规避等等。
有时候，静下心来学习理论，会有助于自己的实践，不知道大家有没有这个感触。
PhilexPei 2003-07-29
- 打赏
- 举报
设计模式我看了很久还是不能融会贯通。
楼主你看了几遍？
楼主你看了几遍？
zhwyt 2003-07-28
- 打赏
- 举报
软件工程?请问什么样的公司才会用?我是做软件的,在北京,月薪3500,可我不用软件工程,也不知道那有什么用!托普招了5000人(实际上没这么多),搞软件工程,最后"落了个白茫茫大地真干净"!如果说托普这样的公司不能搞这个那国内能搞软件工程的一定不会很多,(我并不是说托普是数一数二的大公司,可也不是太小吧,怎么也叫CMM3呢,CMM3以上的有几个?),我不知道软件工程是什么,中国有没有什么像样的软件开发团队,我对此却不再有兴趣.
猛禽 2003-07-28
- 打赏
- 举报
楼上的也不要太激动，你也不能说你的导师完全不对，他只是用错了地方，这种项目管理是建筑工地上用的项目管理方法。^_^
snail_8888 2003-07-28
- 打赏
- 举报
我同意sanysh的说法，其实项目的管理关键的是实施的具体方法和理念，每个公司要针对自己的情况和具体的项目
ftp://flyinpig.bingle.org.cn/pub/ebook
上有着两本书，大家看看
ftp://flyinpig.bingle.org.cn/pub/ebook
上有着两本书，大家看看
danysh 2003-07-28
- 打赏
- 举报
我不知道CMM到底有多大用处，因为我觉得很多公司只会不动脑子的套用，而且更由于世界上最大的软件公司（Microsoft）没有CMM，象SUN，IBM等之类的大公司也没有CMM，盲目实施CMM又有什么意义。不知我的理解可否正确。
Rose2000 2003-07-28
- 打赏
- 举报
现在的时代，是强调资源整合、团队的力量，不是一个人能够把握的。
zuochao 2003-07-28
- 打赏
- 举报
正是因为中国像样的软件开发团队太少，作坊太多，有的作坊甚至有300人之多，
才形成不了象印度一样庞大的软件产业。不用软件工程思想进行管理，企业无法
做大，造成中国几万个手工作坊，每年软件出口额的总数还不如印度几大软件公司
的出口额。
毕竟已不再是英雄的时代，或者说应该重新解释英雄二字。
才形成不了象印度一样庞大的软件产业。不用软件工程思想进行管理，企业无法
做大，造成中国几万个手工作坊，每年软件出口额的总数还不如印度几大软件公司
的出口额。
毕竟已不再是英雄的时代，或者说应该重新解释英雄二字。
cccbuiler 2003-07-27
- 打赏
- 举报
到现在为止我也读完了这三本书，感想颇多，也写了些东西，但是还没有来得及整理。
但是有一点是一定要说的，这些东西对于每一位程序员和项目经理都是十分必需的，每一个人都应该来看一看。这是事实，我们必须面对的事实。
加班、团队合作、还有人员分配等等，认真读来，受益很多，感触更多。
但是有一点是一定要说的，这些东西对于每一位程序员和项目经理都是十分必需的，每一个人都应该来看一看。这是事实，我们必须面对的事实。
加班、团队合作、还有人员分配等等，认真读来，受益很多，感触更多。
eman1 2003-07-27
- 打赏
- 举报
《人月》和《最后期限》我都看过了，《人件》买了，只看了一点。最近发生了一件事情让我感触很深：
导师让我们干活，开始大家积极性非常高，每天聚在一起讨论，可是导师有一个天大的错误，他总寄希望于施加给我们最大的压力，试图通过这样来提高我们的工作效率，从而提前进度，事实上领导也没有催什么进度，每次他都催我们在某某日之前把目前的一个版本做完，于是，我们被迫连续工作很多天，根本没有时间休息，甚至他会每天打电话给我们每个人，试图了解其他人有没有在干活，如果发现有人休息的话，就会得到他的批评，说我们又放松了，到目前为止，似乎我们根本不应该有休息的时间，大家对他都非常反感，觉得他很没有人性，根本不懂项目管理，却还在和我们开会的时候谈项目管理，说我们的进度控制不到位，说今后走向工作岗位就怎样怎样，我曾经把我的《最后期限》给他看，结果他说没有时间。
现在大家都想躲他，以前对他的那种敬仰的感觉也完全没有了，其实很多项目经理对于人的理解是很不到位的，所以随着时间的流逝和接触的增加使得项目组的成员都很反感。
他甚至在我们面前说：其实有时候我知道你们做不完，但是为了让你们更有效率就故意把进度提前，让你们有点压力，项目管理的时间控制是最终要的。我听了之后就想给他一拳，拿大家不当人。竟然还好意思大谈项目管理........其实他也许仅仅是一个老师，仅仅觉得自己看过基本书，我后来很瞧不起他，有时候真想给他上上课，给他讲讲到底什么是项目管理
导师让我们干活，开始大家积极性非常高，每天聚在一起讨论，可是导师有一个天大的错误，他总寄希望于施加给我们最大的压力，试图通过这样来提高我们的工作效率，从而提前进度，事实上领导也没有催什么进度，每次他都催我们在某某日之前把目前的一个版本做完，于是，我们被迫连续工作很多天，根本没有时间休息，甚至他会每天打电话给我们每个人，试图了解其他人有没有在干活，如果发现有人休息的话，就会得到他的批评，说我们又放松了，到目前为止，似乎我们根本不应该有休息的时间，大家对他都非常反感，觉得他很没有人性，根本不懂项目管理，却还在和我们开会的时候谈项目管理，说我们的进度控制不到位，说今后走向工作岗位就怎样怎样，我曾经把我的《最后期限》给他看，结果他说没有时间。
现在大家都想躲他，以前对他的那种敬仰的感觉也完全没有了，其实很多项目经理对于人的理解是很不到位的，所以随着时间的流逝和接触的增加使得项目组的成员都很反感。
他甚至在我们面前说：其实有时候我知道你们做不完，但是为了让你们更有效率就故意把进度提前，让你们有点压力，项目管理的时间控制是最终要的。我听了之后就想给他一拳，拿大家不当人。竟然还好意思大谈项目管理........其实他也许仅仅是一个老师，仅仅觉得自己看过基本书，我后来很瞧不起他，有时候真想给他上上课，给他讲讲到底什么是项目管理
wyqiang 2003-07-24
- 打赏
- 举报
我也想看完
seraphyesu 2003-07-24
- 打赏
- 举报
我看<人月>确感觉没什么收获,看了很久还没看完.
加载更多回复（35）
