一个坏苹果会毁了一箱好苹果，在软件开发过程中，无论你做了多少正确的事情，你只要做了一件错事，软件的开发进度就会延期。
这次最大的感受就是软件工程的核心是按期质量的完成计划，最好能够快速开发。
关键是按期。软件的时间规划很难。就像书中写的你很可能肯定的列出了一个项目的时间计划表。但是由于种种的原因，计划一拖再拖，最后甚至可能直接被取消的。一个过于乐观的计划表，会使你突然在交付前夕突然匆忙起来，而匆忙的结果导致更多的错误，最后使得工期一再拖延。所以，一个真实可靠的时间计划表非常重要。《快速软件开发》中说“有少数的一些组织的进度估算准确到了10%以内，能控制在5%之内的还没有听说”。
的确软件的估算真的很难很难。书中有这样一个例子:一天，你去找一个建筑师，告诉他你要建一个房子，并问他能否用10万元建一栋有三个卧室的房子。建筑师告诉你可以，但也告诉你依据要求的细节，费用为有所变化。如果你接受他的建议，那么他有可能按照估算完成工作。但是如果你对想要的房子有特殊的要求——坚持要能容纳三辆车的车库、美食厨房、日光浴室、游泳池等，那么即使当初的建筑师曾告诉你有可能用10万元建的一栋三个卧室的房子，最终你的房子的造价可能会是最初估算的好几倍。所以说这牵扯两个方面的问题。一个是用户的需求是否与程序员想的需求一致，也就是说他们两个心中的房子是否相同。另一个就是软件工程开发是一个逐渐改进的过程，刚开始你只有一个模糊的认识，随着工作的进行，你才能越来越清晰，所以对于时间的估算也比较模糊。只有详细的理解了每个功能，才可能准确估算。
对此，我表示疑问很大，当我们做一个全新的项目的时候，又该怎么估算呢？如果用户的需求不断改变，又怎样能够最小限度的减少损失呢?
那么时间不够，是否添加人手就行呢？答案是否定的。布鲁克斯在《人月神话》中提出了布鲁克斯法则——“往已延误的项目中补充人力，只会使其继续延误。”这个问题是基于如下法则，它假定生产力是可拆分为不连续、无差异、可替换的单元。所以，如果100个人能在一个月内完成50个部件，则单个部件需要2个人月——故而只要往项目中投入更多工人，就能更快地生产出相同数量的部件。这就是人月神话。布鲁克斯观察到，“只有在任务能分派给许多互相之间无须沟通的工作者是，人和月才是可互换品。”因为每当团队中加入一个新组员，老组员就得放下手边的工作，帮助新组员进入角色，每位组员都要等待重新分派任务，好让新组员有事可做。在你意识到这一切之前，已经远远落后于进度了。
那么落后了进度，是否还有方法能够快速弥补呢？
