《人月神话》读书笔记
读书的一点点总结吧，关于软件开发管理方面的知识，虽然可能以后工作中用不到，但是至少理解自己的角色。
造成项目滞后的最主要原因是缺乏合理的进度安排。几个可能的原因有：
对估算技术认识的缺乏，制定的时候基于一种假设——一切都将运作良好。
造成这种问题的原因大多是因为思路的不完善性，假如文档写的天衣无缝，程序写的尽善尽美，估计会和理想预期的一样。
采用的估算技术隐含地假设人和月可以互换，错误的将工作量与进度混淆。人和月不可以互换的原因，大概有一下几个：
- 人员沟通需要成本，大的项目，肯能会一直开会～ 2.有的任务无法分解，例如一个算法，可能不能拆成几个部分来做 3.即使任务可以分解，那么与时间的关系也不是线性的，是1/x的样子的。而且如果关系过于复杂那么会出现人越多消耗时间越长的现象。
没有持续性的对项目估算。
对进度缺少跟踪和监督。
这两点这章没有详述，我感觉和敏捷开发中的反馈意思差不多。
进度偏移时，下意识的增加人力。
如果增加人力，那么新来的要培训，需要消耗时间，人多了沟通多，消耗时间而且沟通中会有错误，模块多了集成时候错误就会多。项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立于任务的数量。从这两个数值可以推算出进度表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度安排。所以一个项目不是人越多做的越好越快，每个项目可能都有一个最佳的人员配置，最佳的进度安排。
一般系统的人员数目和分工？
首先如果不是大型的系统，那么小的精干的队伍是合理的。曾经有的测量显示：一个效率较高的程序员可能是效率较低的程序员的生产率的10倍。如果一个200个人的项目，那么如果其中有20几个最能干的项目经理，那么可以开除其余的人，只让这20几个人组织项目。但是如果是大型的项目，要上千人共同完成，那么不可能使用这种人员配置。分工的话，一般都有系统架构师、文档编写人员、测试人员、产品经理、项目经理等。
大型系统设计的考虑因素？
其中最重要的就是概念的完整性。为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统。一般整个大系统的活动有体系结构、设计实现、物理实现。体系结构最好是由少部分人完成，这样可以保证系统的概念的完整，像系统的一些接口的设计。设计实现应该是具体接口如果实现，和物理实现一起可以由程序员来完成。
结构师的交互准则和机制？
首先，可能在开发的过程中体系结构上是可能修改的，一般开发人员提出的体系结构的修改建议是对的，但是可能造成意想不到的成本开销。结构师设计系统一般倾向于精炼和简洁，但是在下一个项目的时候，可能会添加一些多于的修饰，虽然不是必然，但是一种普遍的经验现象。
关于文档的重要性
第一，是保重概念上的完整性，对项目的一些限制，编程规范的定义 第二，也是很重要的一定，用来沟通，文档可能是随着项目的进行而修改的，通过文档能够提高沟通效率
里程碑
制定进度表可以控制大型项目，进度表上的每一个事件被称为“里程碑”，他们都有一个日期，选择日期是估计上的问题，需要经验。好的里程碑对团队来说是一项服务，可以用来向项目经理提出合理要求的一项服务，而模糊的里程碑是难以处理的负担。必须关心每一天的滞后，他们是大灾祸的基本组成因素，可以用PERT来寻找关键的偏离.