带来坏消息的人不受欢迎
“当人们听到某个项目的进度发生了灾难性偏离时，可能会认为项目一定遭受了一系列重大灾难。然而，通常灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。”
一天一天的进度落后是难以识别、不容易防范和难以弥补的。每件事情都只会将某项活动延迟半天或者一天，但是整个进度开始落后了，尽管每次只有一点点。
控制大型项目的第一步是制定进度表。进度表上的每一件事被称为“里程碑”，都有一个日期。选择日期很大程度上依赖于以往经验。
里程碑的选择只有一个原则，那就是必须是具体的、特定的、可度量的时间，能够进行清晰定义。
策划案商定通过、代码编制完成、通过所有测试用例。这些切实的里程碑澄清了那些划分的比较模糊的阶段——疾患、编码和调试。
如果里程碑定义的非常明确，无法自欺欺人时，很少有人会就里程碑的进展弄虚作假。但是如果里程碑很模糊，就常常会得到一份于实际情况不符的报告。毕竟，没有人愿意承受坏消息。
对于大型开发项目中的估计行为，有如下研究结果。
- 如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着开始时间的临近，无论最后情况会变得如何糟糕，它都不会有太大的变化。
- 活动期间，对时间长短的过高估计会随着活动的进行持续而下降。
- 过低估计在活动中不会有太大变化，一直到计划的结束日期之前大约三周左右。
好的里程碑对团队来说是一项服务，可以用来向项目经理提出合理要求的一项服务，而模糊的里程碑是难以处理的负担。
不了解，就无法真正拥有
我们编的代码需要向用户诉说自己的“故事”，即使是完全开发给自己使用的程序。因为记忆衰退的规律会是用户——作者失去对程序的了解，于是不得不重拾自己劳动的各个细节。
关于一篇优秀的文档
- 目的。 主要的功能是什么？开发程序的原因是什么？
- 环境。 程序运行在什么样的机器、硬件配置和操作系统上？
- 范围。 数据的有效范围是什么？允许现实的合法输出范围是什么？
- 实现功能和使用的算法。 精确的阐述它做了什么。
- “输入——输出”格式。 不许是确切和完整的。
- 操作指令。 包括控制台及输出内容中正常和异常结束的行为。
- 选项。 用户的功能选项有哪些？如何在选项之间进行挑选？
- 运行时间。 在制定的配置下，解决特定规模问题所需要的时间？
- 精度和校验。 期望结果的精确程度？如何进行精度的检测？
人月神话的观点：是与非
- 同样有两年经验而且在受到同样培训的情况下，优秀的专业程序员的生产率是较差的程序员的10倍。
- 小型、精干队伍是最好的——思绪尽可能少。
- 两个人的团队，其中一个是领导者，常常是最佳的人员使用方法。
- 对于真正意义上的大型系统，小型精干的对于太慢了。
- “概念完整性是系统设计中最重要的考虑因素。”
- 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
- 仅仅通过对编码部分时间的估计，然后库诚意其他部分的相对系数，是无法得出对整项工作的精确估计的。
- 同优秀的棒球队伍一样，进取对于杰出的软件开发团队是不可缺少的必要品德。
- 必须有评审机制，使所有成员可以通过它了解真正的状态。处于这个目的，里程碑的进度和完成文档是关键。
- Vyssotsky：“我发现在里程碑报告中很容易记录‘计划（老板）的日期’和‘估计（最基层经理的日期）’的日期。项目经理必须停止对估计日期的怀疑。”
- 对于大型项目，一个对里程碑报告进行维护的计划和控制小组是非常可贵的。
