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

    

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

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

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

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

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

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