第 10 章 提纲挈领
任务管理任务的关注焦点都是时间、地点、人员、项目内容和资金。
书面记录决策是必要的；文档能够作为同其他人沟通的渠道。
项目经理的主要责任是使每个人都向着相同的方向前进，所以他的主要工作是沟通，而不是做出决定。
“完全信息管理系统“——管理人员只需在计算机上输入查询，显示屏就会显示出结果。这个系统并不被作者推崇，一个原因管理人员可能只有20%的时间，用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、讲授、规劝、讨论和鼓励。
第11 章 未雨绸缪
对于大多数项目，第一次开发的系统并不合用。必须构建一个用来抛弃的系统，因为即便是最优秀的项目经理，也不可能面面俱到。
为舍弃而计划，无论如何，你一定要这样做。
变化是与生俱来的，不是不合时宜和令人生厌的异常情况。软件产品易于掌握的特性和不可见性，导致它的构建人员面临永恒的需求变更。抛弃原型的概念本身就是对事实的接受——随着学习过程更改设计。
不变只是愿望，变化才是永恒。
普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的方法。不管怎么样，重要的是先去尝试。
设计人员通常不愿意为设计书写文档。通过设计文档化，设计人员将自己暴露在每个人的批判之下，他必须能够为他书写的一切进行辩护。
对于一个广泛使用的程序，其维护总成本通常是开发成本的40%或更多。
程序维护中的一个基本问题是——缺陷修复总会以固定(20%~50%)的几率引入新的bug，所以，整个过程是前进两步，后退一步。
所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身引起的漏洞的修复工作越来越多。随着时间的推移，系统变得越来越无序，修复工作迟早会失去根基。每一步前进都伴随着一步后退。重新设计崭新的基于原有系统的重新设计是完全有必要的。
第12 章 干将莫邪
干将，春秋时吴国人，是楚国最有名的铁匠，他打造的剑锋利无比。楚王知道了，就命令干将为他铸宝剑。后与其妻莫邪奉命为楚王铸成宝剑两把，一曰干将，一曰莫邪（也作镆铘）。
为开发人员配备工具不能吝啬。
如果资源需要调度，为各开发小组分配连续的时间块。
第13 章 整体部分
关键的部分是产品定义，那些未精确定义的地方是导致无数失败的原因。
自上而下的设计。
1、首先，通过比较粗略的任务定义和大概的解决方案得到主要结果。
2、然后，对该定义和方案进行细致的检查，以判断结果与期望之间的差距
3、同时，将上述步骤的解决方案在更细的步骤中进行分解，每一项任务定义的精化变成了解决方案中算法的精化，还可能伴随着数据表单方式的精化。
一些糟糕的系统往往就是试图挽救一个基础很差的设计，而对它添加了各种表面装饰般的补丁。自上而下的方法减少了这样的企图。
软件系统开发过程中出乎意料的困难部分是系统集成测试。
第14 章 祸起萧墙
当人们听到某个项目的进度发生了灾难性的偏离时，可能会认为项目一定遭受了一些列重大灾难。然而，通常灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。同样，项目的进度经常以一种难以察觉，但是残酷无情的方式慢慢落后。
进度表上的每一个事件被称为”里程碑“，它们都有一个日期。里程碑必须是具体的、特定的、可度量的事件，能够进行清晰定义。
就我个人而言，十分反感创业公司在个人项目中强调里程碑，要追求严格的文档流程化，这些工作应该有专人和开发者沟通整理文档，而不是由开发者额外提供。否则说明公司根本没有人了解开发者所做的项目，只在形式上渴求开发者严格自律，不管是对公司还是个人，造成了沉重的形式化负担。
进取 是很多优秀队员和团队不可或缺的心理素质。
一线经理的利益和老板的利益在项目计划偏离时存在冲突，一线经理担心如果汇报了问题，老板会采取行动干预项目，扰乱计划。老板必须区别行动信息和状态信息，他必须规范自己，不对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。
对计划和控制职能进行适度的技术人力投资时非常值得赞赏的。计划和控制小组作为 监督人员，明白地指出了不易察觉的延迟，并强调关键的因素，他们早期的预警系统，防止项目以一次一天的方式落后一年。
第15 章 另外一面
因为记忆衰退的规律会使作者失去对程序的了解，于是他不得不重拾自己劳动的各个细节。
不要解释这么做的重要性，直接演示如何做得更好，默认了重要性。
流程图是一种吹捧得最过分的程序文档，在一些要求流程图的组织中，流程图总是事后才补上的。让代码自解释吧。
第16 章 没有银弹
在未来十年内，无论是在技术还是管理方法上，都看不出有任何突破性的进步，能够保证在十年内大幅度提高软件的生产率、可靠性和简洁性。
软件开发中困难的部分是规格说明、设计和测试这些 概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。
现代软件系统无法规避的内在特性：
1、复杂度
2、一致性
3、可变性
4、不可见性
大多数情况下，这些元素以非线性递增的方式交互，因此整个软件复杂度要比非线性增长多得多。
软件似乎很容易进行修改，它是纯粹思维活动的 产物，可以无限扩展。日常生活中，没有人执着像对软件修改一样对建筑进行修改，因为意识到频繁修改成本很高，而对待软件的态度就显得轻率得多。
软件的内在问题是设计上的复杂度。
流程图已经被证明是完全不必要的设计工具——程序员是在开发之后，而不是开发之前绘制的。
需求精炼和快速原型 最困难的部分是确切地决定搭建什么样的系统。因此，软件开发人员为客户所承担得最重要的智能是不断重复地抽取和细化产品的需求。事实上，客户不知道自己需要什么。复杂的软件系统通常是活动的、变化的系统。活动的动态部分是很难想象的。
增量开发 参考自然界的生物，健康的系统应该是逐步发育成长，而不是一次性搭建。首先系统应该能够运行，即使未完成任何有用的功能，只能正确的调用一系列伪子系统。接着，系统一点一点被充实，子系统轮流被开发，或者是在更低的层次调用程序、模块、子系统的占位符等。
卓越的设计人员 大多数机构花费了大量的时间和精力来寻找和培养管理人员，但据我所知，它们之中没有任何一家在寻求和培育杰出的设计人员上投入相同的资源，而产品的技术特色最终依赖于这些设计人员。杰出的设计人员和卓越的管理人员一样重要，他们应该得到相同的培养和回报。
第17 章 再论没有银弹
银弹 在西方基督教的传说中，只有银弹击中心脏，才可以杀死恶魔。而在这本书中，把规模越来越大的软件开发项目比作无法控制的怪物，希望有一样技术，能够像银弹彻底杀死恶魔那样，彻底解决这个问题。
任何人若想看到一件完美无瑕的作品，他所想的那种作品过去不存在，现在和将来也不会出现。
在系统工作中所遇到的大多数复杂性是组织结构上一些失误的征兆。试图为这些现实建模，建立同等复杂的程序，实际上在隐藏和逃避最更根本的问题，管理层不愿直面他们管理上的战略缺陷，而是希图用程序来避开这些未曾解决的问题。
全书19章，后面的几章是讨论和解释观点，不做笔记了，读不出太多趣味。
