外科手术现场

(资料来源：UPI[United Press International] Photo/The Bettman Archive)

这些研究表明，效率高和效率低的实施者之间个体差异非常大，经常能够达到数量级的水平。

—— Sackman,Erikson和Grant^[1]

These studies revealed large individual differences between high and low performers, often by an order of magnitude.

SACKMAN, ERIKSON, AND GRANT¹

在计算机领域的会议中，常常听到年轻的软件经理声称，他们喜欢由一流人才组成的小型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。其实我们也经常有相同的看法。

但这种幼稚的观点回避了一个很困难的问题—— 如何在有意义的进度安排内创建大型的系统？那么就让我们现在来仔细讨论一下这个问题的各个方面。

问题

软件经理很早就认识到优秀程序员和较差程序员之间生产率的差异，但实际测量出的差异还是令我们所有的人吃惊。在他们的一个研究中，Sackman、Erikson和Grant曾对一组具有经验的程序人员进行测量。在该小组中，最好的和最差的表现在生产率上平均为10∶1；在编程速度和空间上具有5∶1的惊人差异！简言之，20 000美元/年的程序员的生产率可能是10 000美元/年的程序员的10倍。反之亦然。数据显示，经验和实际的表现没有相互联系(我怀疑这种现象是否普遍成立)。

我常常重复这样的一个观点，需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果(系统调试)。这一点，也暗示系统应该由尽可能少的人员来开发。实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本的、速度缓慢的、低效的，开发出的是无法在概念上进行集成的产品。OS/360、Exec 8、Scope 6600、Multics、TSS、SAGE等等—— 这个列表可以不断地继续下去。

得出的结论很简单：如果在一个200人的项目中，有25个最能干和最有开发经验的项目经理，那么开除剩下的175名程序员，让项目经理来编程开发。

现在我们来验证一下这个解决方案。一方面，这个开发队伍不是通常所说的不超过10个人的、理想的小型精干的队伍，该团队的规模如此之大，以至于至少需要两个层级的管理，或者大约5名管理人员。另外，它需要额外的财务、人员、空间、文秘和机器操作方面的支持。

另一方面，如果采用一拥而上的开发方法，那么原有的200人的队伍仍然不足以开发真正的大型系统。例如，在OS/360项中，当项目进行到顶峰时，有超过1 000人在为它工作—— 程序员、文档编制人员、操作人员、职员、秘书、管理人员、支持小组等等。从1963年到1966年，设计、编码和文档工作花费了大约5 000个人年。如果人月可以等量置换的话，我们所假设的200人队伍需要25年的时间，才能使产品达到现有的水平。

这就是小型、精干队伍概念上的问题：对于真正意义上的大型系统，它太慢了。设想OS/360的工作由一个小型、精干的团队来解决，譬如一个10人团队。作为一个尺度，假设他们都非常能干，比一般的编程人员在编程和文档方面的生产率高7倍。 同时假设OS/360原有开发人员是一些平庸的编程人员(这与实际情况相差很远)。同样作为一个尺度，假设另一个生产率的改进因子提高了7倍，因为较小的队伍所需的沟通和交流较少。同时假设同样的队伍完成的是同样的工作。那么，5 000/(10×7×7)= 10，他们需要10年来完成5 000人年的工作。一个产品在最初设计的10年后才出现，还有人会对它感兴趣吗？或者它是否会随着软件开发技术的快速进步，而显得过时呢？

这种进退两难的境地是非常残酷的。对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。如何调和这两方面的矛盾呢？