Review of Debugging the development process 5. Schedule Madness

Never allow the schedule to drive the project or to demoralize the team.
在早期的微软，没有人在乎项目是否进度超前，但是任何进度落后都是不允许的。要是程序员的错虫不断增加，不算严重问题，但是只要有人的工作没有在排定的时间内完成，那就罪孽深重了。“进度”取代了项目目标和软件质量，变成了首要之务，每一个人都在疯狂地赶进度。

用这种方法开发应用软件，在理论上似乎合理但事实上问题百出，这种进度控制法，虽然可以使产品准时出货，但是开发人员承受非常大的心理压力，程序员为求进度不得不放弃品质。在当时可能不幸出现明显的问题，但是几年后，微软才尝到过度重视进度的可怕后果。

造成这样的原因，是因为进度表定得太不实际了，它是依照以下几个假设前提编定的：
* That all tasks—for a two-year project—were known and listed on the schedule
* That each week each programmer would complete 40 hours' worth of the tasks listed on the schedule
* That all task estimates were completely accurate
* That all features would be implemented perfectly, without bugs
如果进度表是这样定出来的，那么即使是最优秀的程序员也无法保持进度。计划中的工作事项是很难事先列齐全的，可能会开发到一半发现当初漏列了某一项很重要的工作；每人每周虽然上班4 0小时(以上)，但不会时刻都在写程序；一个程序需要的时间很难准确估计，尤其是编日程表时可能不很确定这个程序的功能；程序不需要修改？那是不可能的事，不但可能有错虫，功能也有可能需要增加。

于是微软对这种方法做了一些修改：
Make sure your schedules are attainable but aggressive enough to keep team members focused on steady progress.
从项目的一开始就给所有的人一定的压力是很有必要的。实际在大多数情况下，在项目的初期，所有人的心态是非常放松的，总是觉得时间还很多，大家总是早上闲闲散散来上班，翘起二郎腿，一边看窗外的白云，一边慢慢想项目。而到了后期时间总是显得非常紧迫，于是大家又开始工作在最后期限的压力之下了。而时间的压力一大，大家必然就要放弃程序的质量。如果一个项目时间太长，以至于使大家在初期产生放松的心理，那就应该把这样一个大项目目切割成一些小项目，分段完成。这样当大家完成每一个小项目时，还能产生激励的效用。

Never allow team members to jeopardize the product in the attempt to hit what might be, after all, an arbitrary deadline.
在有些情况下，项目期限是由上级主管随意指定的，如果我们同意了这个期限，到时候就得做出来。如果这是一个不合理的期限，那么我们就要考虑在时间和质量之间要作出一个选择了。我想除非这个项目的时间有决定性的影响，那么质量应该是更重要的吧。