人月神话不是神

用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，因为它暗示了人员数量和时间是可以相互替换的。(注:人月是用来衡量工作量的，规模是通过功能点或代码行等方式来衡量的，规模除以个体生产率后可以得到人月数据)。

这里进一步来描述人月不能互换的原因，

• 首先是任务能否拆解，
• 即使能够分解任务间是否存在相互的依赖和约束，
• 分解后是否增加会增加相应的沟通，
• 以及由于分解任务而引入的分解和后期集成等额外的工作量。

当软件产品的规模增加的时候，复杂度成倍增长，从而导致这些要素之间不是单纯的线性关系，这是人月神话的启示之一；同时由于软件项目本身的生命周期模型和工序任务限制，导致对于一定规模的软件产品研发，无论投入多少的资源，都有一个最短工期的限制，在这个最短工期下投入再多的资源也没有用。

如果一个系统按功能点估算有200个功能点，按一个功能点200-300行代码计算，整个系统规模在5万行代码左右。这是一个中小型的项目或系统。如果按照总生产率80行/天计算，则总工作量在20人月左右。

根据非线性关系我们可以估计理想情况或者说性价比最好的情况是投入5人4个月完成，当人数增加一倍时候进度只能压缩到3个月。当人数再增加到15个人的时候，进度压缩到2个月，这个时候增加再多的人就已经没有用了，对于这种规模的的系统，2个月可能就是进度极限了。

对于大型项目，书中给出了推荐的工作量比例分布(计划1/3,编码1/6,单元测试和集成测试1/4,1/4系统测试)。很少有项目为测试分配一半的周期和时间，也很少有项目真正只给编码分配1/6时间。根据个人实际软件项目开发的经验，大概的经验数据是(需求1/4，设计实现1/2,测试1/4)。中小型项目能够分配到1/4的测试工作量已经是比较大的一个值，这意味着一个10人左右的团队需要配置2个专门的测试人员)。

非线性增长

我们讲当规模增长的时候，工作量并不是非线性增长，周期也不是非线性增长。其中工作量的增加

• 第一个重点增加在了系统分析设计，需要将复杂的系统进行分解；
• 其二在后期集成和测试，需要将分解的各个功能模块集成和组装。

对于产品规模增加的时候，对于详细设计和编码阶段工作量可以任务是一种线性的增加，非线性部分指数增加的工作量都体现到了前期的分析设计和后期的集成和测试上面。

当我们假设是线性的时候，我们主观的去缩减了这两头的工作量。如果缩减了系统分析和总体设计的工作量，则可能带来整个产品结构的不稳定，后果往往是整个产品推倒重来；如果缩减了后期集成和测试的工作量，则不可避免的是导致项目延期。

乐观主义者喜欢假设我们开发的是零缺陷的系统，但对复杂的软件系统而言这仅仅是个神话。

进度落后根源

对于进度落后的问题根源，我们可以做如下考虑。 1.需求本身频繁变动而且不受控，开发频繁的修改和返工，全是无效工作量。

2.开发人员技能本身问题，或者是开发效率低，或者是对业务需求理解不深。

3.开发人员自身的态度和责任感，是否有一种能够刺激他们潜在创造激情的氛围。

4.没有一个安静专注的环境，经常被各种无意见的会议，电话和琐事打断。

当进度出现严重问题时候最有效的方法仍然是消减任务，与其交付10个不可用的功能点，还不如交付5个优先级高的功能点。其二进度落后的时候，盲目的加班往往是无济于事的。

按照时间管理的方法论，你越忙的时候你越该停止下来，好好的反省究竟慢在哪里，瓶颈和根源究竟在哪里，只有当问题的根源真正被挖掘出来和解决后，才可能真正提高效率和加速度。