2007-7-17 13:20:32
《人月神话》读书笔记(1)
再读了一遍人月神话，把一些重要的内容加上自己的理解摘录下来。这本书应该是真正做过多个项目的人员才能够真正体会读者的一些观点的正确性。(需要人月神话电子版下载的可以直接给我留言留下邮件地址)
焦油坑
1.焦油坑更多应该指大型复杂系统，对项目影响因素太多。无休止得加班，返工，BUG，争论，项目一再得延期而看不到尽头。程序员在焦油坑中挣扎而迷失方向。
2.编程的乐趣＆苦恼：人不是机器，任何开发活动都是创造性的劳动，不要扼杀了这种乐趣，程序员不是在完成代码，而是在创造自己得产品，虽然过程中存在诸多烦恼。
人月神话
1.人员和时间不能互换，压缩工期导致了人员增加导致沟通成本和工作量的增加，导致前期架构和接口设计工作量增加，导致后期模块＆产品集成的工作量增加。
2.计划占用1/3时间，而编码仅占有1/6时间：这个经验数据估计很多软件项目很难做到，有预才有立，前期缺陷泄漏会给项目带来致命风险，使项目后期陷入大量无休止的变更，修改BUG，编码重构工作中。
3.空泛的估算：估算需要历史经验数据的支持，需要又经验的专家，如果项目前期连需求都还很不明确，那计划阶段基本就无法估算出准确的数据，只有在后期再进行估算调整。
4.向进度落后的项目中增加人手只能够使项目进度更加落后。（这句太绝对，需要考虑新增加人手的经验，项目＆未完成工作包现状，交接培训时间等内容）
外科手术队伍
1.核心成员只占团队成员的很少部分，而其它成员全部使辅助成员。核心成员可以很专注的进行设计＆开发工作。
2.如果一个
200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。
(全是牛人的团队能够很好协作？)
民主和专制
1.概念完整性要求设计必须由一个人或少数配合默契的人员来实现。
2.大型系统在设计阶段无需引入编码人员，否则也是资源浪费。(小型团队可以采用敏捷方法，进行增量＆迭代，通过沟通＆交流解决问题，但一样要由一个总体＆架构设计人员完成高层概念的统一）
画蛇添足
1.架构师要乐于接受开发人员建议对自己的系统设计进行改善。
2.架构和设计人员不要剥夺了开发人员的创造力，更多的是提出建议。
3.架构和设计人员如何避免过分设计和华而不实。
贯彻执行
1.如何保证项目规则＆规范和严格执行 （执行力）
2.前期应该有明确的规章制度，每个任务都应该有明确的交付和完成点。
巴比伦塔
1.最高效的沟通方式：面对面
2.常用沟通方式和效果：邮件－>即时通讯MSN->电话->面对面+会议
胸有成竹
1.实践是最好老师，但是如果不能从学习再多实践都没有用。
2.平时项目过程中要注意各阶段工作量数据的收集＆分析，项目完成后要进行复盘，为后续项目积累历史经验数据。
3.项目中应该推行PSP，收集真实得个体数据。
0
推荐到鲜果：
下一篇：《人月神话》读书笔记(2)
上一篇：项目范围管理
评论
谢谢啊
发布者 OurDearAmy
2008-7-24 20:38:40
发布者 人月&神话
2008-7-24 21:01:23
发布者 OurDearAmy
2008-7-24 21:36:44
发布者 U幽鹬
2008-8-1 16:53:19