别样的神话

中国科学技术大学  李根  原创作品版权所有转载请注明出处

       正如计算机算法书籍中有《算法导论》这样的圣经读本一样，软件书籍中同样具有深远影响力和经久不衰的著作《人月神话》，此书堪称软件领域的圣经。《人月神话》由IBM System/360系统之父Frederick Brooks所著。这本书并不侧重向从事软件行业的人员展示高超的编程技术，也不涉及任何软件设计模式和编程语言，而是通过作者丰富的项目经验，分析软件特性及开发过程中的人员安排，进度管理等方面的内容。值得一说的是，与我以往阅读过的有关软件开发和项目管理的书籍不同，这本书完全不走“软件工程政治书”这一老路，避开软件工程上的规范束缚，不至于使读者昏昏欲睡，从而给读者耳目一新的感觉。纵观全书，作者总是先提出问题，然后给出解决方案及适用范围，接着指出其方法的局限性，产生了怎样的后果，最后总结教训。

       这本书给我的感觉就是“惊艳”二字，很多兼具系统性和理论性的归纳我还是第一次看到。由于篇幅有限，只简要谈谈我感兴趣的几个论述。本书开篇就将在软件开发过程中遇到的困难形象地比作“焦油坑”，一旦整个团队因为预期目标、时间进度、预算等问题陷入焦油坑，开发人员所做的各种补救措施很难突破现有的困境。

  ★ 从焦油坑说起

       何谓焦油坑？

       软件项目开发过程中，表面上看起来没有任何一个单独的问题会导致困难，每个问题好像都能被解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变得越来越慢。因此，相互纠缠和积累的困难就是焦油坑。作者的目的就是尽可能地帮助大型系统开发人员走出焦油坑。那么，在大型系统开发过程中，到底有哪些焦油坑呢？

  ★ 焦油坑之一：进度滞后

       在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。就拿微软当年的操作系统Windows 2000来说，负责这个项目的团队计划用三年的时间就可以开发出这个系统，可事实上前前后后一共用了五年的时间才开发完成。微软作为全球软件行业的“金融寡头”尚且不能保证它的项目均按计划好的时间进度完成，何况小型的软件开发公司。可见，项目的估计和进度的安排是一门值得深究的学问。导致项目进度滞后有以下原因：

   ●  乐观主义的盛行

       所有的编程人员都是乐观主义者。为什么这么说呢？在程序员看来，计算机编程就是一份简单的活儿，因为它基于非常容易掌握的介质，通过非常纯粹的思维活动就能控制整个开发过程。某种程度上，正由于介质的易于驾驭，造成了乐观主义的弥漫。天真的程序员每次找出一个bug之后，潜意识里总是抱有这样的想法：“这次它肯定会运行”或者“我刚刚找出了最后一个错误”。但是他们忽略了一个重要事实：Bug无处不在。

   ●  人月神话

      在这里，我们把“人月神话”作为导致进度滞后的原因之一，而作者却把其作为本书的书名，岂不是辱没了这本经典著作？到底人月代表什么？神话真的是关于人和月的传奇故事吗？听我慢慢道来：

       何谓人月？

       人，指的是参与软件开发的人员数量；月，指的是开发软件所花费的时间，可以引申为进度。

       何谓神话？

     “神话”，本是莫须有的，这是Brooks为突出“人员数量和时间是可以相互替换的”这一具有误导性的观点而引入的。Brooks认为用人月来衡量一项工作的规模是一个危险和带有欺骗性的神话，它暗示着人手和进度是可以相互替换的。

  ※ 为什么不能简单地认为人月是可以相互转换的呢？

  ▲ 任务可以分解，并且子任务之间不需要相互交流，只有这种情况下人月才可以相互转换（实际开发中几乎不可能）：

  ▲ 任务可以分解，并且子任务之间需要相互交流，但交流时间小于任务分解节省下来的时间：

  ▲ 任务可以分解，并且子任务之间需要相互交流，但交流时间完全抵消任务分解节省下来的时间，甚至交流时间随着人手的增加以(n-1)*n/2的规模递增：

       综上，人月是一个非常具有迷惑性的概念，从事软件开发的人员对此要有深刻的认识。事实上，作者把“人月神话”作为书名，意在告诫各位下面这个法则：

       Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后。

   ●  各项任务的测试时间安排不当

       由于编程者的乐观主义，实际出现的缺陷数量比预想的要多得多。因此，系统测试的安排常常是编程中最不合理的部分。我们真正开发项目时，很少有允许为测试分配一半时间的，但是大多数项目的测试实际上是花费了进度中一半的时间。在项目快完成的时候发生延迟，带来的二次成本远远高于其他开销。因此，在前期进度策划时，允许充分的系统测试时间是很有必要的。

   ●  迫于用户压力制定了空泛的进度计划

       为了满足顾客期望的日期而制定不合理的进度安排，但紧迫的计划进度无法控制实际的完成情况。就像是至少要花费两分钟才能煎好一个鸡蛋，但顾客要求在两分钟之内吃到鸡蛋，那么要么生吃煎蛋，要么开大火煎烧，结果导致一面已经烧焦，而另一面却是生的。

  ■  进度滞后项目的解决方案

    ⊙ 在新的进度安排中分配充裕的时间，确保工作能保质按量地完成。

    ⊙ 当项目延期造成后续成本很高时，往往削减系统的功能是唯一的解决方法。

  ★ 焦油坑之二：缺乏沟通

   ●  巴比伦塔为什么会失败？

       巴比伦塔有着良好的先决条件：清晰的目标，充足的人力，丰富的泥土、沥青等材料，充裕的时间，超高的建筑技术；但是，最终还是难逃失败的厄运。究其原因，建造它的部落缺乏有效的交流沟通，遇到困难他们选择了争辩、猜忌、相互推卸责任，最后部落只能分裂，不了了之。

   ●  大型编程项目中的交流

       随着工作的展开，某些小组也许会逐渐修改自己程序的功能、规模，例如更改了一些输入输出用法上的约定，那么整个团队如何进行交流沟通呢？可以通过以下途径：

      ·成员之间经常开展非正式性的讨论

      ·定期召开项目会议

      ·准备正式的项目工作手册

   ●  树状组织架构

       假设开发团队中有n个人，则有（n*n- n）/ 2个相互交流的接口，因此必须减少不必要的交流及合作。树状组织架构使用人力划分和职责限定可以有效减少沟通成本。其基本原理是利用管理角色的非重复性，同时每棵子树需要定义如下基本要素：

      ·每棵子树需要完成的任务

      ·子树的产品负责人（对外沟通）

      ·子树的技术主管（对内技术指导）

      ·进度

      ·人员的划分

      ·子树对外接口的定义

   ■  由巴比伦塔想到的？

       巴比伦塔也许是第一个工程上的彻底失败，但它绝不是最后一个。它的失败具有深刻的教育意义：项目管理人员要清醒认识到交流和组织的技能的重要性，相关经验的积累和能力的提高同软件技术本身同样重要。

  ★ 银弹之争：是否存在终极利器？

   ●  人狼、银弹与软件项目

       何谓人狼？

       人狼，指满月时会由人形变成狼形的怪兽，它可以出乎意料地从熟悉的面孔变成可怕的怪物。

       何谓银弹？

       银弹，指惟一可以杀死人狼的武器。为了对付人狼，我们必须寻找能够消灭它们的银弹。

       重新定位熟知的软件项目？

       软件项目：具有一些人狼的特性，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。

   ●  没有银弹

       Brooks于1986年发表了《没有银弹》一文，Brooks断定，没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。时至今日，早过了Brooks设定的十年期限，到目前为止依然没有找到能够杀死软件的银弹。然而，《没有银弹》引发了众多的辩论，甚至至今还在延续。

       Brooks的高明之处就是将发现银弹的困难分成根本的和次要的，而根本困难是决定是否有银弹的关键。

     ·根本困难在于软件系统存在无法规避的内在特性：复杂度、一致性、可变性和不可见性。

     ·次要部分少于整个开发工作的9/10，那么即使不占用任何时间，也不会给生产率带来数量级的提高。因此，必须着手解决开发的根本问题。

  ●  存在银弹

       计算机学、社会学大师，Objective-C的开发者Cox认为,在信息化社会里，市场对信息的巨大需求将成为经济诱因，促使银弹的出现。（个人认为，市场需求引发的经济诱因再强大，还是不能从根本上解决软件本身的内在特性。）

   ■  未来银弹能否找到？

       大家都知道，资本主义社会内部存在不可调和的矛盾，哪怕资本主义经济水平再高，市场需求引发的经济诱因再强大，都不可能令这种矛盾消亡；这种矛盾是资本主义社会本身固有的产物，只有资本主义社会不存在了，这种不可调和的矛盾才会消亡。正如同资本主义社会一样，软件本身也存在这种“矛盾”——根本困难，所以，我觉得找到银弹的愿望是美好的，过程是艰难的，结果是不可能的。当然，这只是我的愚见。

  ☆ 结束之语

       这本书通读下来，丝毫不觉枯燥乏味，书中一个个醍醐灌顶的论断和描述，使得我对软件特性、项目管理、团队合作与沟通交流有了一定的了解，但由于大型项目经验不足，对不少观点的理解不免肤浅，今后参加过大的项目再读此书，一定会理解得更加透彻。