|
再读了一遍人月神话，把一些重要的内容加上自己的理解摘录下来。这本书应该是真正做过多个项目的人员才能够真正体会读者的一些观点的正确性。 焦油坑 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，收集真实得个体数据。 削足适履 1.你控制不住项目规模，那就就控制不住整个项目 (项目范围管理) 2.数据的表现形式是编程的根本 (强调非功能需求？) 未雨绸缪 1.为变更而计划系统（项目计划中留适当余量，设定允许的需求变更程度) 2.设计和开发要考虑变更，避免后期大量重复代码和代码的重构 3.变更应该受到控制，应该有专门的组织来处理和确定变更 (CCB委员会) 整体和部分 1.剔除BUG的设计 (敏捷中测试驱动的开发) 2.单元测试->集成测试->系统测试->验收测试 (如何没部都做到位，加强前期测试用例的评审，加强开发人员测试知识的培训) 另外一面 1.需要什么样的文档 (源代码+注释就是最好的文档),复杂系统需要高层系统和架构设计的文档。 2.你写一个文档就要让文档发挥作用，否则就不要写。 没有银弹 1.没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。 2.我们总在期待着软件工厂和自动化编程，但更多时候只是我们的一种期望和无法达到的热情。 3.提高生产率方法(构件购买＋快速原型＋增量迭代＋卓越设计人员) 4.期待在MDA思路上推出可用的自动化产品 | 
收藏
分享
有用
无用