杀不死的人狼—我读《人月神话》(3)

我们回顾上一小节，在《人月神话》中的那“31%的答案”的前提——也就是那7%的本质中，如下两项是明显存疑的（也是主要置疑）：

目标的本质：是大型工程，是系统项目，而不是程序

个体的本质：是私利性的

其实早就有人意识到个体的本质“未必全是私利的”，尊重这些个体就会带来一些效果。例如AP正是因为更尊重开发人员的个性与能力，以及相互间的合作而得到了效率的提升。

再进一步地说，既然Brooks设定了“大型工程或系统项目”这样的目标，并给出了一些答案。那么在“小那么一点点的”工程项目中，是不是这些答案就不必须了呢？例如Brooks的许多建议，对于某些目标——例如你要用为期三个月的时间开发一个的产品——就并不是很有效；或者根本无法实施——例如你的团队总共只有6个人，连“外科手术式的团队”都组织不起来。

Brooks的答案对于同样的目标，以及在他所述的“本质”未能发生改变时，还是比较有效（或有实施的可能性）。因此上述一些例外，总是在上述的“7%的本质”被否定或被改变的情况下获得的。因而我们提出的问题是“如何否定或改变”这些难以撼动的本质。然而在我看来，Brooks早已经在最佳位置上，给出了撬动它们的一个支点：

 Brooks认为构建“独立小型程序”与“编程系统产品”是不同的问题。

Brooks讨论的编程系统产品的规模到底有多大呢？我想至少应该是以IBM 360为参考的。不过书中在引用Joel Aron（IBM在马里兰州盖兹堡的系统技术主管）的例子时说，“大型意味着程序员的数目超过25人，将近30,000行的指令”。而按照《人月神话》的数据：人均效率800指令/人年，则这个“大型项目”应该需要1.5年才能完成。此外，还需要大约一倍的人工，来负责除开代码之外的测试、管理、文档和沟通等工作。
 
好的，如果你有一个“(至少)50人，开发一年半”的项目，那么你可以先接受Brooks的答案去实践一下：起码你可以有时间来讨论工程问题，也能够组建那样规模的团队。但是，难道只有这样的“大型工程”才算得工程，而“小那么一点点”的就不算吗？现实是，我们一方面在做着“小那么一点点的”工程项目，另一方面在听着整个业界喧嚣着“为更大规模的工程”而准备的工程理论。我们总在实践Brooks的“答案”或者“预言”，而忘却这些答案的前提：

Brooks的经验源自对IBM 360等大型项目的实践与分析；

Brooks所述的工程是要得到编程系统产品；

Brooks认为编程系统产品的工作量可能是独立小型程序的9倍（在实现大致相同功能的情况下）。
 
事实上我们现在的软件工程的发展是被驾驭了，而不是被预言了。从本质上来说，Brooks在《人月神话》中只是讨论了大型工程的实施，以及相应规模下的团队建设。而我们，便按照这样的设定来铺开了整个软件行业的工程化实施。

促成这种现状的，并不仅仅是一本书的力量，还在于商业的力量。因为只有在这样铺展开来的行业环境中，才可能有商业机会。——即使那些工程顾问与实施专家从来没有实施过“50人，开发一年半”这样的项目，只要他们能报出Brooks的名字，能谈及某些工具在应对“大型项目”中的成功经验，他们就已经成功了一半了。

为什么“敏捷”之初颇受争议？为什么敏捷对一些中小型的团队显得有效和可实施？为什么当这些争议被摆在眼前的成功平息之后，传统工程的理论家们却不忘恨恨地评上一句：那是一种不能（或难以）应用于大型工程的方法呢？！

因为如果大家都很“敏捷”，都只做比这些大型工程“小那么一点点”的工程，那么传统工程的专家们就失业了。反过来，只有把工程做大，大到“敏捷”失去了意义，而“庞大”变成了实质的时候，传统工程就可以为任何失败找到借口：看啊，Brooks就说过“没有银弹”嘛。
>（责任编辑：张思童）

查看本文来源