《人月神话》
1.在众多软件项目中，缺乏合理的进度安排是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。导致这种灾难如此普遍的原因是：
a: 我们对估算技术缺乏有效的研究，更加严肃地说，它反映了一种悄无声息，但并不真实的假设-----一切都将运作良好。
1：所有的编程人员都是乐观主义者（这次它肯定会运行，我刚刚找到最后一个bug）
2：进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间
3：在单个任务中，“一切都将运转正常”的假设在进度上具有可实现性。因为所遇到的延迟是一个概率。
4：分布曲线，“不会延迟”具有限定的概率，所以现实情况可能会像计划安排得那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
b: 我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相混淆。
1：成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。
2：用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。
3：人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且它们之间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的。
4：无论哪个母亲，孕育一个生命都需要10个月。
5：对于可以分解，但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量。因此，相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些。沟通所增加的负担由两个部分组成，培训和相互交流。培训增加的工作量（不能分解）随人员的数量呈线性变化。相互交流的工作量按照n(n-1)/2递增。
c: 由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地估算这项工作。
在进度安排中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。
进度安排参考法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
在许多重要的方面，上面的进度安排与传统的方法不同：
分配个计划的时间比平常的多。即便如此，只是勉强够产生详细和稳定的计划规格说明，并不足以容纳对全新技术的研究和探索。
对所完成代码的调试和测试，投入近一半的时间。
容易评估的部分，如编码，仅仅分配了1/6的时间。研究发现，很少有项目允许为测试分配一半的时间。但大多数项目的测试实际上是花费了进度中一半的时间。他们中许多项目，在系统测试之前还能保持进度。
d: 对进度缺少跟踪和监督。
非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的知觉，这样的方法很难生产出有力的，看似可靠的和规避风险的估计。
开发并推行生产率图表、缺陷率图表、估算规则等等，而整个组织最终会从这些数据的共享上获益。
e: 当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。
项目的时间依赖于顺序上的限制。人员的最大数量依赖于独立子任务的数量。
2. 需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。这一点也暗示，系统应该有尽可能少的人员来开发。
3. 对于效率和概念的完整性来说，最好有少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求，如何调和这两方面的矛盾。Mills的建议：大型项目的每一个部分由一个团队解决，但是该团队以类似外科手术的方式组建，而并非一拥而上。也就是说，同每一成员截取问题某个部分的做法相反，由一个人来完成问题的分解，其他人给予他所需要的支持，以提高效率和生产力。
4. 外科手术团队：
外科医生（首席程序员）：定义功能、设计、编码、测试、要很高经验，熟悉业务
副手：外科医生的保险机制。提供设计、编码、功能的建议，不负责具体的事务
管理人员：管理财务、人员、工作地点、办公设备，听从外科医生
编辑:文档的生成，维护。来自于外科医生的口述或者草稿。
两个文秘：管理人员和编辑各配一个文秘。负责项目的协作一致。
程序职员：负责团队所有的程序和数据的管理。
工具维护人员：保证所有基本服务的可靠性，一致性以及构建，升级，维护。
测试人员：编写测试用例和准备测试数据。
语言专家：语言方面的专家，咨询。解决复杂，棘手的问题。
5. 对于计算机系统而言，出现概念差异和不一致性的问题，是由于设计被分成了由若干人完成的若干任务。所以需要具备设计上的完整性，就需要一个系统架构师从上之下的进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界线，系统架构师必须一丝不苟的专注于体系结构。（本文的体系结构指的是完整和详细的用户接口说明，更偏重于现今的需求概念，不是指系统的框架。）
6. 功能与理解上复杂程度的比值才是系统设计的最终测试标准，也就是易用性。而易用性需要设计的一致性和概念上的完整性来保证。体系结构和实现必须要严格分离开来。产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖架构师一样。两者都有需要很高的创造性。
7. 系统架构规定实际上是增强，而不是限制了实现小组的创造性。一旦他们将注意力集中在没有人解决过的问题上，创意就开始奔涌而出。在毫无限制的实现小组中，在进行系统架构上的决策时，会出现大量的想法和争议，对具体实现的关注反而会比较少。
8. 当建议由小型体系结构团队来编写系统的所有外部技术说明时，编程人员常常会提出这样的反对意见：
该说明中的功能过于繁多，而对实际情况中的成本考虑比较少。
警惕second-system effect。在设计第一个项目时，架构师会面对不断产生的装饰和润色功能，但这些功能都会被搁置在一边，作为“下一个”项目的内容。第二个系统是设计师们所设计最危险的系统。而当着手第三第四个系统时，先前的经验会相互验证，得到对此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。
second-system effect：一种普遍倾向是过分的设计第二个系统，向系统中添加很多修饰功能和想法。另一种倾向是对某些技术进行细化、精炼的趋势，由于基本系统设想发生了变化，这些技术已经显得落后。
架构师获得了所有创造发明的快乐，剥夺了实现人员的创造力。
具体实现中创造和发明的机会，并不会因为指定了外部技术说明而大为减少，相反创造性活动会因为规范化而得到增强，整个产品也是一样。
当体系结构的队伍缓慢工作时，很多实现人员只能空闲的坐着等待。
在外部技术说明完成的时候，才雇佣实现人员。 ；）
9. 把工作进行垂直划分，保证概念的完整性；尽量避免水平划分。
10. 文档化的规格说明----手册：手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同时它还避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而这里他的设计和创造自由是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
11. 周例会是每周半天的会议，有所有的架构师，加上硬件和软件实现人员代表和市场计划人员参与，由首席系统架构师主持。会议中，任何人可以提出问题和修改意见，但是建议书通常是以书面的形式，在会议之前分发。周例会的决策会给出迅速的结论，使工作继续开展下去。这种会议的卓有成效是在于：
数月内，相同小组-----架构师、用户和实现人员-----每周交流一次。因此大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训。
上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务。
当问题出现时，在界线的内部和外部同时寻找解决方案。
正式的书面建议集中了注意力，强制了决策的制定，避免了会议草稿纪要方式的不一致。
明确的授予首席架构师决策的权力，避免了妥协和拖延。
12. 电话日志：日志中，它记录了每一个问题和相应的回答。QA表
13. 产品测试：项目经理最好的朋友就是他每天要面对的对手----独立的产品测试机构/小组。每一个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。测试人员不时地总会发现一些没有贯彻执行、设计决策没有正确或准确实现的地方。出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。
