敏捷开发横空出世 以人为本颠覆软件工程(转贴)

作者： 缪炀《计算机产品与流通》
CNETNews.com.cn 2005-06-23 10:35 AM

“软件行业是成功的，但也存在很多问题，”软件教父Martin Fowler 在近期一次软件开发研讨会上表示，“而且问题往往在出现时才为人们所重视。”

问题缠绕软件开发

软件开发过程中问题多多，这不是个新发现。早在上世纪60年代，北约（NATO）就提出了软件危机这一概念。在《人月神话》一书中，软件开发则被喻为让众多史前巨兽痛苦挣扎，却无力摆脱的焦油坑。随着需求和应用的日趋深入与复杂化，软件开发的难度和遇到的问题以几何级数形式增长，焦油坑也由此变得更深、更大。

复杂程度高，开发周期长，结果无保证，这是软件开发的通病。针对问题，人们创造了N 种方法，并由此产生了软件工程学。而在实际工作过程中，软件开发的多变性和不可控制性，仍可轻易摧垮项目开始时项目组苦心经营的开发体系和方法，无论是业界公认的需求、变更、人员流动，还是各种看起来并不起眼的小事件。

以人为本的敏捷开发

“既然无法阻止变化发生，我们就要找出适应变化的方法。”Fowler并非空手而来，随他登场的还有敏捷开发。

什么是敏捷开发？一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。

改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

也许是因为时间关系，Fowler只说出了这些优势中的一部分。允许开发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验，拥有的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。

问题与思考

然而，我们不得不面对的现实却是，模式与方法的优化并不意味着问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。

大项目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子项目，合理的资源调配都将变得更加复杂。另外，在当前项目和项目组普遍“增容”的情况下，遇到的问题同样成倍增长。人的重要性被提到了更高的高度，而缺乏有效协调手段，减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的同时，也相应引发了几乎同样多的问题。

不难看出，所有问题归结到最后，还是落到了管理上。管理水平普遍有待提高是软件业内无可争议的事实。重技术，轻管理，这在不少软件开发项目组内是普遍现象。这一方面是源自管理人才的缺乏，和项目组成员一种对管理制度近乎本能的排斥；另一方面则是因为现行规范和管理制度与实际工作中的不合拍。“这就好象理发师自己的头发最后却没人理一样。”一位有着二十年从业经验的业内人士如此评价这种现象。在进度与成本的双重压力下，出现问题时人们首先牺牲掉的往往就是管理和规范。

再好的理论，如果不能落到实处，不能在工作过程中发挥作用，其价值也就等同于以手邀月——我们只能看到一个美好的目标，但不知该如何去做。经验丰富、配合良好而又异常稳定的项目组、积极而富有成效的沟通、良好的管理手段和流程、有效的工具与平台，我们没有理由不相信，在这样的条件下敏捷开发不大获成功。然而如果离开这种近乎理想的状态，在充满变化的项目过程中，结果又将如何？也许我们看到的将只是大项目变成多个小项目，大风险变叠加的小风险。何况如果不熟悉这种工作模式，不了解其实现细节，新的问题将被引发，结果甚至可能变得更加让人难以接受。

颠覆软件工程

敏捷开发的出现，同样让以人为本还是以过程为本的争端上升到了理论层面。

“在敏捷开发过程中，人是第一位的，过程是第二位的，”Fowler表示，“所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。”这与软件工程理论提倡的先过程后人正好相反，因而被不少人戏称为对工程学原理的叛逆。

“做软件是艺术，还是工程？”北京大学软件学院院长陈钟提出的问题，实际上已经揭示了工程学与人本位不同的定位与生存土壤。

在软件天才（Geek）眼中，做软件象是成就一件艺术品：为一个共同的目标，将各人的能力融合在一起，协作创新。在一个彼此熟悉的环境下，监控管理完全忽略不计，流动性也不复存在，能力与协作更不在话下——海阔凭鱼越，天高任鸟飞，每个人将自己的能力充分发挥，完成一幅不世之作。这是先人后过程思路的来源。

而作为管理者，则需要更多地从项目的角度思考问题，人的能力与协作，以及人员的流动性被从更加理性的角度思考。铁打的营盘流水的兵，无论采取何种手段，一切必须尽在掌握。在规定的时间和核定的成本内，高质量地完成工作。这是先过程而后人的产生过程。

过程与人，哪个重要？取决于对象和思考方式。实际上，它们是密不可分的，先后顺序只反映了艺术与工程、研究与研发、工程师和企业家间不得不做的艰难取舍。

“在软件开发过程中没办法绝对地判断一个方法比另一个方法好，”Fowler表示，“因此我们不妨两种方法中寻找最好的，竞争与合作同时存在——多元化体系往往能起到最好结果。”Fowler的说法反映了软件开发模式不确定性的同时，也暗示了未来的发展方向，即在人与过程中寻找最佳平衡。

“没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性。”图灵奖获得者、计算机科学家Phillips Brooks 于1986年在其著作《没有银弹》中提出了上述论断。

迄今为止，该论断还未被打破。敏捷开发从理论上对其进行了又一次尝试和挑战。无论在理论还是实际应用上，国内外众多厂商和资深人士从未停止对此问题的研究。解开被压抑的生产力，高效运作，问题中蕴涵无限商机。

问题何时能被解决？从可意会不可言传到可见，从可见到可行，从可行到易行，从易行到习惯——距离问题真正解决，还有段相当长的路要走。在下一个5 到10年内，问题能被解决吗？希望如此。