一个坏苹果会毁了一箱好苹果,在软件开发过程中,无论你做了多少正确的事情,你只要做了一件错事,软件的开发进度就会延期。

  这次最大的感受就是软件工程的核心是按期质量的完成计划,最好能够快速开发。

  关键是按期。软件的时间规划很难。就像书中写的你很可能肯定的列出了一个项目的时间计划表。但是由于种种的原因,计划一拖再拖,最后甚至可能直接被取消的。一个过于乐观的计划表,会使你突然在交付前夕突然匆忙起来,而匆忙的结果导致更多的错误,最后使得工期一再拖延。所以,一个真实可靠的时间计划表非常重要。《快速软件开发》中说“有少数的一些组织的进度估算准确到了10%以内,能控制在5%之内的还没有听说”。

  的确软件的估算真的很难很难。书中有这样一个例子:一天,你去找一个建筑师,告诉他你要建一个房子,并问他能否用10万元建一栋有三个卧室的房子。建筑师告诉你可以,但也告诉你依据要求的细节,费用为有所变化。如果你接受他的建议,那么他有可能按照估算完成工作。但是如果你对想要的房子有特殊的要求——坚持要能容纳三辆车的车库、美食厨房、日光浴室、游泳池等,那么即使当初的建筑师曾告诉你有可能用10万元建的一栋三个卧室的房子,最终你的房子的造价可能会是最初估算的好几倍。所以说这牵扯两个方面的问题。一个是用户的需求是否与程序员想的需求一致,也就是说他们两个心中的房子是否相同。另一个就是软件工程开发是一个逐渐改进的过程,刚开始你只有一个模糊的认识,随着工作的进行,你才能越来越清晰,所以对于时间的估算也比较模糊。只有详细的理解了每个功能,才可能准确估算。

  对此,我表示疑问很大,当我们做一个全新的项目的时候,又该怎么估算呢?如果用户的需求不断改变,又怎样能够最小限度的减少损失呢?

  那么时间不够,是否添加人手就行呢?答案是否定的。布鲁克斯在《人月神话》中提出了布鲁克斯法则——“往已延误的项目中补充人力,只会使其继续延误。”这个问题是基于如下法则,它假定生产力是可拆分为不连续、无差异、可替换的单元。所以,如果100个人能在一个月内完成50个部件,则单个部件需要2个人月——故而只要往项目中投入更多工人,就能更快地生产出相同数量的部件。这就是人月神话。布鲁克斯观察到,“只有在任务能分派给许多互相之间无须沟通的工作者是,人和月才是可互换品。”因为每当团队中加入一个新组员,老组员就得放下手边的工作,帮助新组员进入角色,每位组员都要等待重新分派任务,好让新组员有事可做。在你意识到这一切之前,已经远远落后于进度了。

  那么落后了进度,是否还有方法能够快速弥补呢?