前言：美食的烹饪需要时间，那么稍等片刻，你将享用更多的美味。缺乏合理的进度安排是造成项目滞后的重要原因，因素有以下内容： – 对估算技术缺乏有效的研究 – 进度和工作量混淆，就是说人员和时间可以转换 – 对自己的估算缺乏信心 – 缺乏信心 – 对进度缺少跟踪和监督，所以站立会和燃尽图至关重要 – 意识到进度偏移时，第一个反应是增加人力，而这时大多数情况如同火上浇油，，火越来越大，需要的汽油却越来越多
乐观主义
书中说，编程人员都是乐观主义者，我想，在国内，需求者比编程人员更“乐观”，他们引导设计者和架构师走上极端的左倾主义。我存有一种愿景就是，希望未来需求者能够考虑足够的风险，树立一种观念就是每一项任务不仅仅是花费它“应该”花费的时间。 对于创造者来说，只有在实现的过程中，才能发现构思的不完整性和不一致性。也就是说，我们去做1.0版，意义重大，1.0版能够帮助我们更好的去反思我们的设计。 作为我们程序员来说，“一切都会完美的运行”几乎是不可能的，从我们自身来说，当我们写完代码后，必须要抱着怀疑的态度，去检查我们创造的代码，减少bug。
人月
人员和时间不能在所有场所内进行替换。
从实际的开发经验中，可以得出，软件开发是错综复杂的过程，那么没有弄清楚效率降低、进度延迟的真正原因时，盲目的追求人员的增加会让事情更糟。
系统测试
系统测试的时间在大多数的软件开发中，系统测试被开发团队忽略，往往很多时候，开发人员做完自己的代码后，就将测试工作丢给测试人员，这种现象我之前有所描述，见小型团队的测试该何去何从这篇文章中，我介绍了这个可怕的现象，而其解决办法竟然是增加人员。 没有合理的规划系统测试时间的话，就会带来可怕的后果，因为系统测试往往是在产品发布之前，这个时候再出现延误，代价太高。
空泛的估算
大多数情况下，产品经理或者项目经理和客户的关系就如同蛋糕师和顾客的关系，蛋糕的烹制过程会受到顾客紧迫程度的影响。假如顾客催促蛋糕师，那么蛋糕师可能做出两种选择，第一个就是继续按照自己的进度，让顾客等待，这样可能失去顾客；第二个是加大火力，这样蛋糕就可能出现问题。
重复产生的进度灾难
当任务没有按照原定计划执行时，就出现延期，假如出现在项目进展的第一个阶段，项目经理发现了进度延缓的问题，那么假如说他盲目的增加人手来试图缩短产品研发时间的话，就必然会重复进入到灾难的陷阱中。 增加人手会带来严重的问题，原来的开发人员需要拿掉开发的时间来培训新的人员，这样同时又将原来的进度延缓，假如再增加人手，就会进入到万劫不复的灾难中。
作者有如下结论“Adding manpower to a late sofeware project makes it latter.”
那么我们该如何正确做出改变呢？
总结：项目的时间依赖于顺序上的限制，而人员的最大数量依赖于独立子任务的数量。如何把握人员数量和进度之间的关系是至关重要的。
有时间，我们可以去爬山，
