敏捷开发大家谈（六）--敏捷开发技术在电子商务软件中的应用(1)

 第一章 背景介绍

　　运用替换原则时，我们尽量把类B设计为抽象类或者接口，

让C类继承类B（接口B）并实现操作A和操作B，

运行时，类C实例替换B，这样我们即可进行新类的扩展（继承类B或接口B），

同时无须对类A进行修改。

依赖倒置原则DIP：Dependency Invertion Principle

在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。

具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。

在结构化设计中，我们可以看到底层的模块是对高层抽象模块的实现（高层抽象模块通过调用底层模块），

这说明，抽象的模块要依赖具体实现相关的模块，

底层模块的具体实现发生变动时将会严重影响高层抽象的模块，显然这是结构化方法的一个"硬伤"。

　　面向对象方法的依赖关系刚好相反，具体实现类依赖于抽象类和接口

　　为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，

并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用

接口隔离原则ISP：Interface Separate Principle

采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。


　　ISP原则是另外一个支持诸如COM等组件化的使能技术。

缺少ISP，组件、类的可用性和移植性将大打折扣。

这个原则的本质相当简单。如果你拥有一个针对多个客户的类，

为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

以下展示了一个拥有多个客户的类。

它通过一个巨大的接口来服务所有的客户。

只要针对客户A的方法发生改变，客户B和客户C就会受到影响。

因此可能需要进行重新编译和发布。这是一种不幸的做法。

所展示的技术。每个特定客户所需的方法被置于特定的接口中，这些接口被Service类所继承并实现。

如果针对客户A的方法发生改变，客户B和客户C并不会受到任何影响，也不需要进行再次编译和重新发布。

 

　　1.1 电子商务背景

　　随着企业信息化的不断进步，电子商务在中国也越来越得到更多的认可，电子商务的应用也越来越多，但是很多企业对电子商务的概念和应用还不是很清楚，行业内对电子商务的研究模式和实施方法也存在很多问题。因此很多企业在实施电子商务系统的过程中都处在探索和摸索当中，对于项目开发方来说也有着极大的风险性和挑战性。

　　1.2 电子商务软件开发存在的问题

　　由于电子商务软件开发存在很大的风险性，而且电子商务的应用也出在不断摸索当中，没有很多成熟的模式可以参考，所以没有实践的指导可能会导致的项目噩梦。缺乏有效的实践会导致不可预测性、重复的错误以及努力的白白浪费。延期的进度、增加的预算和低劣的质量致使客户对我们丧失信心。更长时间的工作却生产出更加低劣的软件产品，也使得开发人员感到沮丧。我们希望这些方法这次还会有效，从而消除我们的恐惧。然而，项目并没有简单到使用一些约束和人为制品就能够可靠地防止错误的地步。当连续地犯错误时，我们会对错误进行诊断，并在过程中增加更多的约束和人为制品来防止以后重犯这样的错误。一个大而笨重的过程会产生它本来企图去解决的问题。它降低了团队的开发效率，使得进度延期，预算超支。它降低了团队的响应能力，使得团队经常创建错误的产品。

　　1.3 敏捷开发技术概述

　　敏捷式开发采用适应性方法，而传统的软件工程学采用的是预测性方法。敏捷式开发是以人为主的，而传统的工程学是以过程为主的。

　　1.4 敏捷开发的现实意义

　　适应性和预测性的区别存在于软件工程学对软件开发过程的描述中。在传统的工程学里，核心的概念就是把设计和构建这两个过程分开进行。在软件开发的过程中，我们很难想象，如何真正把设计和编程完全区分过来。软件工程学领域，所有在这里从事工作的人员，都把设计的过程想象成用图表、图象的方式来描述结果的过程。还有一个更重要的问题就是说，软件本身的需求是在变化的。一个项目在开发过程中需求会出现变化，需求的变化从根本上推翻了工程学方法所建立的一个基础。当工程学的人尽量减少或者控制系统将来发生变化的可能，他越这样做问题就越容易出现。既然我们没办法避免变化的发生，那么我们就想找到一种新的方法能够更有效地适应这种变化现象。这也就是敏捷式开发方法所要达到的效果。

　　第二章 敏捷开发技术的应用

　　2.1 敏捷开发技术的几种主要类型

1.XP（Extreme Programming －－ 极限编程

2.Cockburn的水晶系列方法

3.开放式源码

4.Highsmith的适应性软件开发方法〔ASD〕

　　　2.2 敏捷开发技术的特点和优势

　　1．个体和交互胜过过程和工具

　　人是获得成功的最为重要的因素。如果团队中没有优秀的成员，那么就是使用好的过程也不能从失败中挽救项目，但是，不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作，那么即使拥有一批优秀的成员也一样会惨败。团队的构建要比环境的构建重要得多。许多团队和管理者就犯了先构建环境，然后期望团队自动凝聚在一起的错误。相反，应该首先致力于构建团队，然后再让团队基于需要来配置环境。

　　2．可以工作的软件胜过面面俱到的文档

　　没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。

　　3．客户合作胜过合同谈判

　　不能像订购日用品一样来订购软件。你不能够仅仅写下一份关于你想要的软件的描述，然后就让人在固定的时间内以固定的价格去开发它。所有用这种方式来对待软件项目的尝试都以失败而告终。有时，失败是惨重的。告诉开发团队想要的东西，然后期望开发团队消失一段时间后就能够交付一个满足需要的系统来，这对于公司的管理者来说是具有诱惑力的。然而，这种操作模式将导致低劣的质量和失败。成功的项目需要有序、频繁的客户反馈。项目的需求基本处于一个持续变化的状态。大的变更是很平常的。在这期间，也会出现整个功能块被减掉，而加进来另外一些功能块。然而，合同和项目都经受住了这些变更，并获得成功。成功的关键在于和客户之间真诚的协作，并且合同指导了这种协作，而不是试图去规定项目范围的细节和固定成本下的进度。

　　4．响应变化胜过遵循计划

　　响应变化的能力常常决定着一个软件项目的成败。当我们构建计划时，应该确保计划是灵活的并且易于适应商务和技术方面的变化。计划不能考虑得过远。

　　2.3 敏捷开发技术的12个原则

1．我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

2．即使到了开发的后期，也欢迎改变需求。

3．经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好

4．在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

5．围绕被激励起来的个人来构建项目。

6．在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

7．工作的软件是首要的进度度量标准。

8．敏捷过程提倡可持续的开发速度。

9．不断地关注优秀的技能和好的设计会增强敏捷能力。

10．简单使未完成的工作最大化。

11．最好的构架、需求和设计出自于自组织的团队。

12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

　　2.4 敏捷开发技术的适用范围

1.项目团队的人数不能太多

2.项目经常发生变更

3.高风险的项目实施

4.开发人员可以参与决策

　　第三章 敏捷开发技术在电子商务软件的实际应用案例

　　3.1 案例说明：钢铁贸易企业的网上期货订货系统开发实施

　　项目背景：国内某大型国有钢铁贸易企业，其业务形式大部分采用期货订货，客户群也比较广泛，订货时间相对比较稳定，一般集中在月底的10天左右。该企业原来开发了一套适合自己企业运作的贸易企业ERP系统，但是仅仅是在公司内部使用，功能也很有限，不能够很好的和客户进行信息交流，往往客户在集中订货的时候，因为订货量巨大，而且时间集中，所以造成该企业的业务人员忙的团团转，而且经常会发生排队订货的现象，同时由于是期货订货，所以该企业还得向上游供应商订货，这样一来一去，给工作带来极大的不便，也容易造成混乱和漏洞。

　　因此，介于用户这样的情况，需要开发一套网上期货订货系统，将订货的整个环节都打通，真正实现24小时订货。减少人工干预，通过和几个系统之间的集成，做到实时的信息流通。但是这样一个系统对于该企业来说，毕竟是第一回，国内也没有相关成熟的案例和模型，所以实施存在极大的风险性。而且其他同行业的竞争对手也在着手打造这样的一个系统，所以尽早建立网上订货系统，对于提高顾客的忠诚度和满意度都是大有裨益的，所以对工期的要求也非常严格。

　　根据以上情况，决定采用敏捷开发技术来实施这个项目。

　　3.2 项目组织机构

　　建立联合实施团队，由电子商务公司的项目实施人员和客户方的关键用户一起构成，统一受客户方的常务副总指挥。

　　工作方式：在客户现场办公，在调研的同时做需求，根据系统架构和功能划分，边做设计边做开发。

　　沟通方式：每天下班前半个小时，所有项目组成员必须座在一起沟通交流，对每天的工作进行总结和经验交流。每周召开一次推进和培训会议，在不断的开发过程中进行对用户的业务知识，系统知识，和操作的培训，为将来系统的运行维护打下更好的基础。

　　3.3 项目实施过程

　　第一轮循环实施周期两个月，不但搭建了整个应用的整体框架，还实现了两大品种的单向期货订货流程。

　　第二轮循环实施周期两个月，打通了向供应商的期货订货环节，并且实现了另外两个品种的订货。同时逐步将前期做好的系统向用户做推广使用，在不断完善的过程中，对本阶段的项目开发实施做修正。

　　第三轮循环实施周期三个月。由开发人员和客户方的关键用户对期货订货系统进行完善和优化。

　　3.4 项目实施效果

1. 客户方由于实施了该项目，给订货用户和公司业务员带来很大的便利，效率大大提高，再也没有排队订货的状况，再也没有业务员通宵达旦的处理订货需求，再也不会和供应商之间发生信息失真的现象。系统的快速实施和推进，使得客户对该系统也越来越依赖，同时该公司的销售业绩也率攀新高。

2.由于采用了敏捷开发技术，极大的降低了开发成本，大大提高了开发的效率。尽管在整个项目实施过程中存在大量的变更和修正，但是这样的开发方式可以很有效的避免带来更多负面的扯皮现象。

3.因为项目成员由高水平的开发人员参加，所以对客户的业务理解非常深入，在实际的项目开发当中，不但承担了具体开发的工作，还向客户方提出很多很好的建议改进措施，以便业务更加优化，操作更加顺畅。一方面，客户方从中收益，另外一方面，开发人员的能力也得到了极大的提高。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/3433/viewspace-269191/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/3433/viewspace-269191/