软件工程到敏捷开发的一点小感想

Posted 2020-08-14 韩旭1406

    

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

       简单介绍一下：敏捷软件开发又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。虽然在国外已经得到了广泛应用，在中国国内，敏捷开发用的还不算很多，而在我们的教科书里，更没有介绍了。但是随着Agile敏捷开发的流行，越来越多的公司采用敏捷开发用于软件产品和应用的开发。

       然而敏捷开发作为一种软件开发方法，像是一种软件工程开始出现之前的一种存在。如同几个好友，在一个不大的小屋中开发软件。表现在这些特点：

       几个人组成一个小组，这个小组中的人共同完成软件的需求、设计、开发和测试。小组中有简单的分工侧重，但其实每个人都会参与每个阶段。用敏捷的话讲，这就是产品人员、软件工程师和测试工程师紧密配合的一个小组。工程师需要参与需求分析、测试工程师需要参与产品的设计、产品人员要不断的通过当前已有的“原型”来挖掘、更改需求，当然，这是因为“产品人员不可能在一开始就看到所有的需求”。

在这个小组中，文档只是用来辅助交流的，人们更多的使用口头交流来明确一些细节问题或者是存在歧义的问题。文档不许要做到“面面具到”。当然，这也是敏捷所推崇的。需要快速的接收并响应需求的变化，因为需求是一直在变的。
       我们可以看到，这也是“敏捷开发”的主要特点。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
       现在我们来说说软件工程做一下对比。软件工程得到人们的重视是在IBM OS360开发之后。人们认识到，软件系统已经越来越复杂，越来越庞大。上面提到的这种开发方法暴露出越来越多的问题：对程序员要求过高、软件质量难以保证、软件开发完成后的维护成本巨大等。为了解决软件开发的这些问题，人们借鉴了传统的工程项目的实施。建造一个大厦、建造一辆汽车等，这些工程不比软件开发简单，但是这些工程却能被可控地实施并得到质量良好的结果。由此，人们提出了“软件工程”，它的首要目标，也是最根本的目标就是“将软件开发工程化”。剩下的问题是，怎么才能“工程化”？我们仍然可以从建筑业和制造业借鉴他们成功的方法。我们下面就来看看工程化的最重要的两个方面。
       严格的过程控制。先做什么，后做什么，非常明确。比如先做需求分析、再做设计、再做结构施工、再做墙壁于管道等。并且，过程中的每一步都要有确定的产出，并通过验收。这个产出的负责人和验收负责人都要在验收报告中签字。如果这个产出在同一个工程中必须发生变化，那么，这就是一次工程事故，根据事故的大小，责任人需要负“被开除”到“刑事犯罪”等不一的责任。例如，我们要建造一个20层高的大厦，当主设计师完成结构设计后，他会对这份设计文档签字负责，验收者会在验收报告签字。大厦的主结构就会按照这份文档中的结构进行建造。如果到项目的中期，正在进行管道、线缆的部署时，发现，主结构是有问题的，中央主梁无法承受足够的扭矩。此时，设计师和验收者的一句“我们无法在一开始就看到这个，在下一次迭代中会修复”是绝对不会被接受的。他们要负责任。同样，如果此时产品人员过来说，客户的需求变了，是25层而不是20层。而要达到这个要求的代价是：主设计师就需要将主梁的直径增加20%、部分建筑材料需要被替换。我想，对于这种产品人员而言，只能告诉他，你已经在需求文档中签字了，你需要负责赔偿包括返工、材料、工期等方面的一切损失，你该辞职辞职，该坐牢坐牢。问题是：为什么软件不能这样呢？是因为软件修改的成本低吗？事实已经证明了，软件修改的成本不低。
       严格的规格说明。规格说明文档应该做到详细、严格。举个例子，在机械制造中，常常用到螺丝。在一个机械的设计文档中，会详细指定每个螺丝在标准环境下（比如0摄氏度、5%的湿度、一个大气压）的直径、螺纹间距、螺纹高度、以及热膨胀系数等参数，负责制造螺丝的部门，拿到份文档，甚至都不用见设计师本人，就可以制造出合格的螺丝。这里面，文档才是关键的东西。哪怕设计师换了、原来的螺丝部门的工人走了，只要有这份文档和合格的工人，就一定能造出与原来一样的螺丝。在硬件领域，bug之所以会少，很大一部分原因是他们在用文档设计。拿到文档，一个懂verilog语言的人都可以编码出合格的产品。只有设计文档才能保证在原本设计、实现一个系统的人走后，后续的人能够很容易的继续维护、扩展这个系统。

　　敏捷开发是一个过程，不是一个事件。在敏捷开发的各个过程中可能集合了很多种传统软件开发方法，比如迭代、增量开发，甚至有瀑布、快速原型法的影子，也许还有更多。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。这也是为什么现在敏捷开发为很多工程师所推荐的方法。那个更好不能立刻下决定，对于不同的项目一定有他更适合的方法。敏捷开发，融合软件工程的优点。也可以软件工程融合一些敏捷开发的优点来适应实际的项目。如今的快节奏，快餐化的软件更倾向于敏捷开发。但重大项目简单的敏捷开发是绝对不合适的。