Morning@Weblog

Chapter 2 The Mythical Man-Month

一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
这是一个观念的转变问题，在这个行业里“浸淫”的这几年，还好自己已经褪去那层“乐观”了

在单个的任务中，“一切都将运转正常”的假设在进度上具有可实现性。因为所遇到的延迟是一个概率分布曲线，“不会延迟”具有限定的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
这段话有点罗嗦，简言之，任何事情只要一上规模，便会变得难于控制，这里所指的是时间可控性

用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
这便是本书题目的由来，前半句是结论，后半句是原因。正如书中所说，人月互换的前提是：1)任务可分隔；2)人员间无需沟通。而沟通所增加的负担由两部分组成：1）培训；2）相互交流。

软件任务进度安排的经验法则：1/3计划；1/6编码；1/4构件测试和早期系统测试；1/4系统测试，所有的构件已完成
分配足够多的时间给计划和测试，这是软件工程所强调的。不过说到计划的安排，敏捷方法论的观点与之有些出入，这里的法则更适合那种规模很大和变化易于预见的项目。

关于那个人月的例子；重复“灾难”所开发出的产品，比没有增加人手，而是重新安排开发进度所产生的产品更差。
我们需要阶段性的可以测量的里程碑，相信敏捷方法论里也会强调这一点。问题的关键在于添加人员后会有额外的人月产生，这包括新手培训、更大范围内人员的沟通，以及任务的重新分配、额外的系统测试。

Take no small slips（避免小的偏差）

Adding manpower to a lane software project makes it later（向进度落后的项目中增加人手，只会使进度更加落后）

项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。
合理的进度表依赖于这两个因素。