前序
这本软件工程管理指南针对我们软件从业人员常见的场景，进行了科学地分析，详细地讲解了在软件管理过程中遇到问题的原因是什么，我们该如何解决，读之后有种豁然开朗，仿佛拨开工作上软件管理的重重迷雾的感觉。本节主要介绍下作者是怎么看待项目管理中进度安排的，是否越多人参与项目，项目就能越快完成交付呢？
第1章
在讲进度安排前，先介绍下背景。本章用焦油坑举例，辅之以数据，讲述了现在的软件系统，正如一只只猛兽，掉进了一个焦油坑里，无法挣脱，越陷越深，直至被焦油吞没。（这个场景也很像沼泽地，陷进去很难出来。）在著名的la brea焦油坑，发现了恐龙，猛犸象，狮子等巨兽化石，难以想象这样的庞然大物在焦油坑里挣扎是怎样的一种震撼场面。联想到我们的软件开发，人们投入了大量的金钱和时间研发出一个个系统，然而这些系统大都达不到目标、进度、预算被丢进了焦油坑里。你有没有在公司里遇到这种情况呢，辛辛苦苦开发出来的系统，或夭折或开发出来后越来越少人使用，甚至被淘汰了。那我们要怎么解决这个终极难题呢？接下来的章节将系统地去讲解。
第2章
回归正题，俗话说，工欲善其事，必先利其器。我们要帮助正在焦油坑里的软件系统爬出来或者是提前避免掉进这个坑，那我们需要去找方法。这里可以用逆推，把前者失败的因素归纳总结起来，就是我们的规避方法。也就是前车之覆，后车可鉴。
总结前人的经验，掉进坑的原因主要有以下：
1.程序员的乐观主义。缺少对技术估算的方法，对编程时间错误评估，例如其中的技术难点，bug排查没有一个客观估算，导致评估出来的时间是乐观的。
2.简单地使用工作量单位“人月”（比如2个月5个人完成一个系统）去预估进度和排期。用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。暗示着我们人和月是可以互相替换的。但人数和时间的替换仅适用于像割小麦，收棉花这种工作上。
但在编程上是不可能的。
第一种，具有次序性，任务完全不能分解。
第二种，任务可以分解，但需要沟通和交流，调整人手后情况会比第一种好一些。
第三种，任务错综复杂，彼此都需要互相交流的情况。工作量将激增，假设每个任务都需要和其他任务协作完成，工作量按照n(n-1)/2递增。这个公式应该是推演总结出来的。比如一对一交流，3个人的工作量是2个人的3倍，4个人就是2个人的6倍。于是就会到变成以下：
从而增加人手，反而延长了时间进度。
3.系统测试，提倡允许充分的系统测试时间。
4.但可能又会延伸出另一个问题，怎么样才算充分，一年也是充分吗？这时就暴露另外一个问题，空泛的估算。我们经常是像厨师一样，计划进度收顾客的紧迫程度影响，要求急，工期短。不急，工期长。这种不合理的进度安排问题，在软件领域比其他工程领域普遍得多。这样很难生产出可靠的估计。
两种解决方案：（1）开发并推行生产率图表，缺陷率图表、估算规则。实际上现在很多公司都是采用估算规则，例如现在某类需求，告知需求方，一个需求至少n小时才能完成，一般是下需求后的第二天提供。又或者是制定每类需求的工时，以此用作后续同类需求的评估规则：
（2）在第（1）出来之前，项目经理根据经验和直觉去把控，会比让编程人员自己根据需求方期望而评估出来的时间要可靠。
5.进度把控问题，重复产生的进度灾难
当项目软件落后于进度时，通常做法是增派人手，有所帮助，但可能无法解决问题。
一个预估需要12个人月的任务，安排3名人员4个月内完成。每个月月尾设置可测量里程碑ABCD。
假设项目进度落后了，2个月后A没有完成。项目经理有哪些方案可以选择？
（1）假定项目一定要按时完成进度，不然出大问题。假设仅仅是第一部分估计不得当，那剩9个人月工作量，剩下2个月，要按时完成的话，需要4.5个人手，也就是在原来基础上增加2人。
（2）假定项目一定要按时完成进度，不然出大问题。整体都估计不得当，还剩18个人月，需要2个月，9个人才能按时完成，比原来3人多了6人。
（3）重新安排进度
（4）削减任务
前两种情况，坚持把不经调整的任务在4个月内完成是灾难性的。第一种，假设增加1个人手需要培训1个月，新增2个人，那么3个人月需要投入到项目以外的工作中，此外，任务划分成5部分。还剩7个人月工作量，此时只有5个人月，还是会延期。
如果加4人呢，就没问题了吧？培训需要5个人月，还剩7个人月，那刚好7人。
但如果考虑任务划分和系统测试的工作量，队伍将达到7人以上，任务划分、沟通问题等等会更加棘手，造成项目最终还是一团槽的进度不可控场面。这里简单跟作者一样，冒昧地简化一下Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后。
我们以前可能一直以为，人多好办事。能向上级申请或能调动越多的人力资源就越好保证项目进度。当我们看完这一章节，我们终于见到了褪去了神话色彩的人月真实情况是怎样的。项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。安排人员较少，花费的时间较长（风险是产品可能会过时）。相反，分派较多的人手，计划较短的时间，无法得到可行的进度安排。
总之，在软件管理中，缺乏合理的进度安排是造成项目滞后的最主要原因，是比其他所有因素加起来的影响还要大。所以在进度出现问题的时候，不能一味地增加人手，应视上述情况而定，必要时或最糟糕时，砍掉部分非核心部分功能，也是一种把控项目的方法。
