第10章 提纲挈领
为什么要有正式的文档
书面记录决策是有必要的
文档能够作为同其他人的沟通渠道
文档可作为数据基础和检查列表
项目经理的任务是制定计划，并实现计划。但是只有书面计划是精确的和可以沟通的
第12章 干将莫邪
项目经理应该制定一套策咯，并为通用工具的开发分配资源：与此同时，他还必须意识到专业工具的需求。
同时还需要配备调试机器或者软件，以便在调试过程中，所有类型的程序参数可以被自动计数和测量。
同天文工作者一样，大部分系统调试工作总是在夜间完成。
拋开理论不谈，一次分配给某个小组的连续的目标时间块被证明是最好的安排方法，比不同小组的穿插使用更为有效
第13章 整体部分
好的自上而下的设计从几个方面避免了 bug
清晰的结构和表达方式更容易对需求和模块功能进行精确地描述
模块分割和模块独立性避免了系统级的 bug
细节的抑制使结构上的缺陷更加容易识别
设计在每个精化步骤上都是可以测试的
重视单元测试、系统集成测试
搭建充分的测试平台
第14章 祸起萧墙
里程碑的选择只有一个原则：里程碑必须是具体的，特定的，可度量的时间，能够进行清晰定义
暴露问题的两种方式
减少角色冲突，鼓励共享。通俗点就是不要越俎代庖
建立评审机制，让问题充分暴露
第15章 另外一面
高估了流程图的作用？？40年前作者主要是做的系统软件，但现在面向业务的应用软件，流程图还是很重要的
子文档化的程序。40年前就提出这个，的确是非常伟大的思想
第16-17章 没有银弹
软件开发建议
仔细地进行市场调研，避免开发已上市的产品；
在获取和制定软件需求时，将快速原型开发作为迭代计划的部分；
有机地更新软件，随着系统的运行、使用和测试，逐渐添加越来越多的功能；
不断挑选和培养杰出新生代的概念设计人员。
软件开发总是苦难的，天生就没有银弹
复杂度：不仅仅导致技术产生困难，还引发了很多管理上的问题
一致性：很多复杂性来自保持与其他接口的一致性，对软件的任何再设计，都无法简化这些复杂特性。
可变性：成功的软件都会发生变更
不可见性：软件的客观存在不具有空间的形体特征
Parnas 写道：重用是一件说起来容易，做起来难的事情。它同时需要良好的设计和卓越的文档。即使我们看到了非常罕见的优秀设计，但如果没有好的文档，我们也不会看到能重用的构件。
第2章 人月神话
导致项目缺乏合理的进度安排的原因
对估算技术缺乏有效的研究
进度和工作量相互混淆
对估算缺乏信心，导致不做精细估算
对进度缺少跟踪和监督
进度偏移时，只有考虑增加人力
用人月为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人的数量和时间是可以相互替换的。
Books法则：进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later.)
第3章 外科手术团队
团队中一个两倍差距的程序员其生产率有可能相差10倍，这也是为什么优秀的公司总是花高薪请优秀人的原因，并非人傻钱多
像外科手术一样来分解工作和划分团队职能
第4章 贵族专治、民主政治和系统设计
概念的完整性要求设计必领由一个人，或者非常少数互有默契的人员来实现。
第5章 画蛇添足
第二个系统是设计师们设计的最危险的系统
第一个系统比较谨慎，容易控制边界
第三个系统之后，经过前期的验证，可以做通用性的抽象设计，并吸取前两个系统的经验教训
第6章 贯彻执行
标准要统一：不要带两个时钟出海，要么带一个，要么带3个
测试的重要性：项目经理最好的朋友就是每天面对的独立的测试小组
第9章 削足适履
对项目经理而言，必须研究用户及用户需求，以设置待开发系统的规模
空间和时间的平衡，现在我们在架构上经常用空间换时间，因为硬件存储的成本在降低，但40年前不一样
