敏捷开发与软件工程

敏捷开发与软件工程
Author: Liang Kun
Date: 2011-04-19
Last Change: 2011-04-19
==============================================================================
    现在，敏捷开发是一个非常热门的话题，很多机构的咨询师、很多程序员对“敏捷”已
经达到了一种近乎宗教的狂热的程度。谈到软件开发，必谈敏捷，必谈TDD，仿佛不用这
个方法，就一定是效率低下的团队和开发方法。

    我个人没有仔细研究过敏捷开发（准确说，没有研究过那几个牛人提出的敏捷开发
）。但是，公司目前在大力推动敏捷，而且我去年的一个重要项目也是按照公司推动的敏
捷方法进行的（据说，公司从某个著名的咨询培训机构挖来人，帮我们做项目管理培训和
敏捷推广）。这篇文章中，我只想谈谈自己对这个方法的感受和想法。

    我的总的观点是：敏捷开发是反软件工程的。

    我承认，敏捷开发中有些实践方式是很好的，值得吸收。例如在敏捷开发的圣经“敏
捷软件开发-原则、模式于实现”一书中，很多设计原则，如“单一职责”、“开放封闭”、
“依赖到转”等，它们只是一般、通用的设计原则，应该应用在任何的开发方法中，这些原
则并也不是只有敏捷开发方法才能用，在任何的开发方法中都可以、应该使用。

    然而，敏捷开发作为一个方法论，则是软件工程的倒退。敏捷开发，更像是软件工程出现之前，小作坊式的软件开发方法。

    什么是传统的小作坊式的开发？它最重要的特点包括：
    1.  几个人组成一个小组（小作坊），这个小组中的人共同完成软件的需求、设计、
        开发和测试。小组中有简单的分工侧重，但其实每个人都会参与每个阶段。用敏
        捷的话讲，这就是产品人员、软件工程师和测试工程师紧密配合的一个小组。工
        程师需要参与需求分析、测试工程师需要参与产品的设计、产品人员要不断的通
        过当前已有的“原型”来挖掘、更改需求，当然，这是因为“产品人员不可能在一
        开始就看到所有的需求”。
    2.  在这个小组中，文档只是用来辅助交流的，人们更多的使用口头交流来明确一些
        细节问题或者是存在歧义的问题。文档不许要做到“面面具到”。当然，这也是敏
        捷所推崇的。
    3.  没有严格的开发过程控制。
    4.  需要快速的接收并响应需求的变化，因为需求是一直在变的。
    我们可以看到，这也是“敏捷开发”方法论的主要特点。

    那么软件工程的目标是什么？软件工程得到人们的重视实在IBM OS360开发之后。人
们认识到，软件系统已经越来越复杂，越来越庞大。上面提到的这种开发方法暴露出越来
越多的问题：对程序员要求过高、软件质量难以保证、软件开发完成后的维护成本巨大等
等。为了解决软件开发的这些问题，人们借鉴了传统的工程项目的实施。建造一个大厦、
建造一辆汽车等，这些工程不比软件开发简单（准确讲，建造一个大厦要远比我们常见的
大多数软件复杂），但是这些工程却能被可控地实施并得到质量良好的结果。

    由此，人们提出了“软件工程”，它的首要目标，也是最根本的目标就是“将软件开发
工程化”。

    剩下的问题是，怎么才能“工程化”？我们仍然可以从建筑业和制造业借鉴他们成功的
方法。我们下面就来看看工程化的最重要的两个方面。

    严格的过程控制。先做什么，后做什么，非常明确。比如先做需求分析、再做设计、
再做结构施工、再做墙壁于管道等。并且，过程中的每一步都要有确定的（至少在本次工
程中不变的）产出，并通过验收。这个产出的负责人和验收负责人都要在验收报告中签
字。如果这个产出在同一个工程中必须发生变化，那么，这就是一次工程事故，根据事故
的大小，责任人需要负“被开除”到“刑事犯罪”等不一的责任。例如，我们要建造一个20层
高的大厦，当主设计师完成结构设计后，他会对这份设计文档签字负责，验收者会在验收
报告签字。大厦的主结构就会按照这份文档中的结构进行建造。如果到项目的中期，正在
进行管道、线缆的部署时，发现，主结构是有问题的，中央主梁无法承受足够的扭矩。此
时，设计师和验收者的一句“我们无法在一开始就看到这个，在下一次迭代中会修复”是绝
对不会被接受的。他们要负责任。同样，如果此时产品人员过来说，客户的需求变了，是
25层而不是20层。而要达到这个要求的代价是：主设计师就需要将主梁的直径增加20%、
部分建筑材料需要被替换......我想，对于这种产品人员而言，只能告诉他，你已经在需
求文档中签字了，你需要负责赔偿包括返工、材料、工期等方面的一切损失，你该辞职
辞职，该坐牢坐牢。问题是：为什么软件不能这样呢？是因为软件修改的成本低吗？事实
已经证明了，软件修改的成本不低（计算上后续维护的成本）。

    严格的规格说明。此处，我用了“规格说明”，其实就是我们所说的文档。文档应该做
到详细、严格。举个例子，在机械制造中，常常用到螺丝。在一个机械的设计文档中，会
详细指定每个螺丝在标准环境下（比如0摄氏度、5%的湿度、一个大气压）的直径、螺纹
间距、螺纹高度、以及热膨胀系数等参数，负责制造螺丝的部门，拿到份文档，甚至都不
用见设计师本人，就可以制造出合格的螺丝。这里面，文档才是关键的东西。哪怕设计师
换了、原来的螺丝部门的工人走了，只要有这份文档和合格的工人，就一定能造出与原来
一样的螺丝。我认识一个做硬件设计的人，他曾经告诉我“你知道硬件的bug为什么这么少
吗？我不是在用verilog设计硬件，我是在用文档设计硬件。拿到我的文档，任何一个懂
verilog语法的人都可以编码出合格的产品。”这就是文档的力量。只有设计文档才能保证
在原本设计、实现一个系统的人走后，后续的人能够很容易的继续维护、扩展这个系统。

    上面就是我理解的软件工程。这个世界上很少有真正的“奇迹”，我们认为的奇迹，基
本上都是伟大的工程。