章节：人月神话
  当进度与计划出现偏差时，千万不要盲目的向开发团队增加人手，那样只能带来毁灭性的灾难，使开发进度变的更加缓慢。

章节：外科手术队伍
  新型高效团队的分工：外科医生，副手，管理员，编辑，两个秘书，程序员，工具维护员，测试人员，语言专家。
  当项目过大时，首先要做的是就是分派任务，然后进行协调，当然首先得要协调概念的完整性，这个时候的协调就不再是所有项目的开发者，而仅仅是那些“外科医生”。

章节：贵族专制、民主政治和系统设计
  系统的结构师的工作是运用专业技术知识来支持用户的真正利益。
  概念的完整性要求设计必须由一个人或者非常少数互有默契的人员来实现。
  产品的成本性能比很大程度上依靠实现人员,易用性很大程度上依赖结构师。

章节：画蛇添足
  结构师要想成功的前提：
  1.牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，不能支配；
  2.时刻准备为所指定的说明建议一种实现的方法，同时准备接受其他任何能达到目标的方法；
  3.对建议保持低调和平静；
  4.准备放弃坚持所作的改进建议；

  第二个系统是设计师们所设计的最危险的系统！避免危险的方法：自我约束准则。

章节：贯彻执行
  手册强调的是精确。
  形式化定义的优点是精确性高，缺点是不易理解。填补这一确定的方法是插入记叙性文字。
  会议分成两个级别：周例会和年度大会。
 1.周例会是每周半天的会议，由所有的结构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持，赋予首席系统结构师最终决断权。
 2.年度大会一般持续两周，一般是每六个月举行一次，出席人员由体系结构小组，编程人员，实现人员的结构代表，编程经理，市场和实现人员参与，由项目经理主持，会议是为解决平时所堆积起来的问题而举行的。
  结构师应该建立电话日志，并且每周交流一次。

章节：为什么巴比伦塔会失败
  交流的缺乏导致争辩，沮丧和群体猜忌。很快，团队开始分裂---大家选择了孤立，而不是相互争吵。
  软件项目开发时队员交流途径有电话，会议，工作手册。
  项目手册的第一步是对所有的备忘录编号，接着就开始进行实时更新，在更新时必须在页面上标记发生改变的文本，分发的变更页附带独立的总结性文字，对变更的重要性以及批注进行记录。
  彻底解决手册太厚的方法：编程人员仅仅了解自己负责的部分，而不是整个系统的开发细节时，工作效率最高。但其先决条件是精确和完整地定义所有借口。
  产品负责人的角色：组建团队，划分工作及制订进度表。他主要是与团队外部，向上和水平地沟通，他建立团队内部的沟通和报告方式。最后他确保进度目标的实现，根据环境的变化调整资源和团队的构架。
  技术主管的角色：他对设计进行构思，识别系统的子部分，指明从外部看上去的样子，勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程度。提供解决问题的答案，根据需要调整系统设计。他所做的工作几乎完全是技术性的。
  大型项目中，产品负责人作为管理者是更适合的安排。
  开发中最重要的就是交流与沟通，特别是在大型的项目中。

章节：胸有成竹
  对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要的注释，并可能存在错误的情况。
  使用适当的高级语言，编程的生产率可以提高5倍。

章节：削足适履
  数据的表现形式是编程的根本。

章节：提纲挈领
  项目经理文档管理做法：项目开始时，立刻正式生成若干文档作为自己的数据基础，哪怕这些迷你文档非常简单：接着，他会和其他人员一样要求各种文档。文档中必须包含以下几点：
 1.产品开发目标。
 2.产品技术说明。
 3.时间进度表。
 4.资金预算。
 5.人员组织图。
  永远记住：项目经理的任务不是决策，而是沟通！文档建立也是为了实现这个目标！

章节：未雨绸缪
  组织架构的设计要尽量做到最小化成员间的接口，以便在将来能使系统在最大程度上易于修改。
  软件维护主要包含对设计缺陷的修复。用户越多，发现的错误就会越多。
  设计实现的人员越少，接口越少，产生的错误也就越少。
  不论是谁，即使是最数量的软件维护工作，也只是放缓了系统退化到非稳态的进程。

章节：干将莫邪
  多种多样的开发工具不但不会促进沟通，反而会妨碍沟通！项目经理应分配一个人专门用于管理工具。
  应分配固定的时间让每个单元小组成员使用机器，这样尽管机器的利用程度可能会有些降低，但有助于提高生产率。
  给每个小组开发成员分配一个区域，用来存放他的程序拷贝、测试用例以及单元测试需要的测试辅助例程和数据，在这个开发库中，不存在任何限制开发人员的规定，他可以自由处置自己的程序，他是它们的拥有者。当开发人员准备将软件单元集成到更大的部分时，他向集成经理提交一份拷贝，后者将拷贝放置在系统集成子库中。此时，原作者不可以再改变代码，除非得到了集成经理的批准。

章节：整体部分
  自顶向下的设计：开始是勾画出能得到主要结果的，但比较粗略的任务定义和大概的解决方案。然后，对该定义和方案进行细致的检查，以判断结果与期望之间的差距。同时，将上述步骤的解决方案，在更细致的步骤中进行分解，每一项任务定义的精化变成了解决方案中算法的精化，后者还可能伴随着数据表达方式的精化。
  关键的地方和构件无bug程序的核心，是把系统的结构作为控制结构来考虑，而不是独立的跳转语句。

章节：祸起萧墙
  当人们听到某个项目的进度发生了灾难性偏离时，可能会认为项目一定是遭受了一系列重大灾难。然而，通常灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。
  里程碑的选择只有一个原则，它必须是具体的、特定的、可度量的事件，能够进行清晰定义。

章节：另外一面
  将文档负担降低到最低的方法：
  1.借助那些出于语言的要求而必须存在的语句，来附加尽可能多的“文档”信息。因此，标签、声明语句、符号名称均可以作为工具，用来向读者表达尽可能多的意思。
  2.尽可能地使用空格和一致的格式提高程序的可读性，表现从属和嵌套关系。
  3.以段落注释的形式，向程序中插入必要的记述性文字。