今天对人月内容的一部分总结学习到了新的高度，我们爱编程，但是又不喜欢动手，这里结合心理学我们快速的学习，我们在王老师的带领下学习领悟这本名著可谓是大快人心得乐趣
1. 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到，Sackman和Humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。
2. 小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。
3. 两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。
4. 对于真正意义上的大型系统，小型精干的队伍太慢了。
5. 实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。
6. 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。
1. 概念完整性是系统设计中最重要的考虑因素。
2. 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
3. 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
4. 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
5. 体系结构、设计实现、物理实现的许多工作可以并发进行。
1. 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
2. 结构师如何成功地影响实现：
i. 牢记是开发人员承担创造性的实现责任；结构师只能提出建议。
ii. 听取开发人员在体系结构上改进的建议。
3. 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。
1. 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
2. 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
3. 出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。
4. 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。
5. 项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。
为什么巴比伦塔会失败？
1. 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果的组织。
2. 因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
3. 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。
1. 仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。
2. 构建独立小型程序的数据不适用于编程系统项目。
3. 程序开发与程序规模成指数增长趋势。
4. 当使用适当的高级语言时，程序编制的生产率可以提高5倍。
这一章主要是要解决项目投资与磁盘空间和内存之间的矛盾，但是这个矛盾在电脑硬件发展到现在的层次已经可以忽略掉了。
1. 软件项目的要求：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。
2. 即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。 这一章强调文档重要性，但并没有将一些教条主义的道理让你相信文档的重要性，而是给项目经理给出了实实在在的操作步骤。
1. 对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤，如果将开发的第一个系统丢弃原型发布给用户，可以获得时间，但是它的代价很高。对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。
2. 用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
3. 软件产品易于掌握的特性和不可见性，导致了它的构建人员面临着永恒的需求变更。
4. 目标和开发策略上的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。
5. 对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。
6. 维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。
7. Campbell指出了一个显示产品生命期中每月bug数的有趣曲线，它先是下降，然后攀升。
8. 缺陷修复总会以（20－50）%的机率引入新的bug。
9. 在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。
10. 同样，设计实现的人员越少、接口越少，产生的错误也就越少。
11. 所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程。
。