阅读笔记《人月神话》2
开篇提到软件实践工程项目的效率问题,那么我就猜测这里的人代指人数,但是月又代表什么呢?难道是月份?这个不得而知,只能继续往下阅读。下面的一大部分在阐述进度和工作量之间的关系,以大部分项目因为缺乏合理的时间分配而滞后为背景,进行了展开分析。在大多数的项目中,一但工程滞后,管理人员的第一反应就是增加人手,但是往往增加人手并不能很好的解决这个问题,因为在软件工程中,每个小分块之间的编写者都是需要沟通才能是整个项目完美完成的,如果只是增加人手,但是这些人对工程项目还不了解,还得与其他人进行沟通,这样反而更加浪费了时间。这就像用汽油灭火一样,只会使事情更加糟糕,越来越大的火势需要更多的汽油,从而进入了一场注定会导致灾难的循环。谈到这里,文章戛然而止,却引出了另一个主题“乐观主义”。
确实,每一个编程者都是乐观主义者。当代程序员都是年轻的程序员,可能因为计算机还很年轻,在他们眼里,无论是什么样的程序,结果都是毋庸置疑的“这次肯定没错,绝对会运行”。虽然乐观是一件好事,但是结果往往事与愿违。所以在实际的软件项目进度安排上,都有一个隐藏的前提——一切都将完美运行。但是每一个项目都有修改bug的步骤,而且时间不确定,这就导致了开篇提到的工程项目滞后的结果。看来这个问题必须要得到足够的重视。
在阐述了第一个谬误后,作者又引出了第二个谬误“人月”。从本书的题目就可以知道,“人月”一定是本书的重中之重。成本的确和开发产品的人数和时间有关,但是进度却不是这样。我现在明白“人月”中的月指的是工程项目中的花费时间。人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且 他们 之间不需要 相 互的交流。 这在割小麦或收获棉花的工作中是可行的;而在系统编程
中近乎不可能。所以说,在系统编程中,人数与时间的互换是一种荒谬的观点。作者举了一个十分浅显易懂的例子——无论多少个母亲,孕育一个生命都需要十个月。以为孕育生命这个进程来说,是绝对不可以分割给别人的。由于测试调试的次序问题,大部分项目都具有这个特点。
就增加人手这个解决方法来看,首先得要解决沟通问题。沟通所增加的负担由两个部分组成,培训和相互的交流。每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解,因此这部分增加的工作量随人员的数量呈线性变化 。 因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手,实际上是延长了,而不是缩短了时间进度。