敏捷化开发

2024-10-11

敏捷化开发（精选8篇）

敏捷化开发篇1

摘要：文章从方法论、功能目标、组织方式3方面进行了系统的需求分析，提出了敏捷产品装配设计系统的整体技术方案，在此基础上建立了基于项目管理监控的系统体系结构和基于Web Services技术的企业应用集成框架，最后基于上述思想进行了系统原型开发(包括功模结构，集成实现，原型系统)，并展示了相关功能模块界面。

关键词：敏捷化开发,装配设计,整体技术方案,项目管理,系统原型

0 引言

现代科技以日新月异的速度发展,新产品层出不穷,但产品的市场寿命大大缩短。顺应客户需求的变化,迅速做出反应,已经成为企业制胜的法宝。另一方面用户需求的多样化和个性化已逐渐成为世界的潮流,如何将新产品以最短的时间、最高的质量、最低的成本推向市场成为了市场竞争的焦点。据统计:产品设计直接影响产品的整个生命周期,整个生命周期约85%的费用由产品开发阶段所决定,而这一阶段本身所需费用则仅占总费用的5%[1];另一方面,在产品生产阶段,有1/3以上的人直接或间接从事与装配有关的活动,装配费用占整个生产成本的30～50%[2]。因此需要一种面向敏捷化开发的产品装配设计系统,为用户提供智能辅助支持,以便能快速响应市场变化和客户的多样化要求。

本文进行了敏捷化开发环境下产品装配系统的需求分析,建立了“以装配建模为中心,以系列化和可装配性为两个实现目标,以敏捷化为最终表现形式”的系统整体技术方案,有效地支持了产品的模块化设计、面向装配的设计和自顶向下的设计方法;构建了敏捷化开发环境下产品装配设计系统的体系结构和企业应用集成框架,有效地支持了并行工程的流程管理方式及虚拟企业的运作方式;最后基于上述思想开发了敏捷产品装配设计系统的原型,并实现了预定的初步功能。

1 系统的需求分析

敏捷化开发环境下产品装配设计系统不但是各装配设计模块协同运作完成产品装配模型、实现信息共享、互相评价的基础,同时也是体现并行设计理念,将传统设计方法中“设计-制造-再设计”的大循环分解为设计环节中的若干个小循环,在每一个微循环内进行“设计-评价-再设计”的基础[3]。总的来说,它的特点主要体现在以下几个方面:

(1)能支持自顶向下的设计方法。在敏捷化开发环境下,产品装配设计系统应能提供和人类专家设计思维相一致的设计方法,即在设计产品时,最初考虑的是产品应实现的功能,然后考虑实现这些功能的几何结构,最后才进行零件的详细设计。这种自顶向下的渐进设计方法不仅能将关键设计约束传递到后续设计阶段,同时也便于实现多个子系统的协同,实现并行设计。因此装配设计系统必须能支持自顶向下的设计方法。另外系统还必须满足用户的多样性要求以及可装配性要求,因此在设计过程中还应融入模块化设计和面向装配设计的理念。

(2)能够提供智能辅助规划分析工具。产品的装配设计是一个复杂动态模糊过程,设计过程中有许多NP难题,另一方面设计人员由于受个人经验知识以及其考虑问题的全面性和正确性等的限制,凭个人能力很难直接得到最优设计。因此装配设计系统必须提供智能辅助规划分析工具辅助设计人员进行各类规划分析,不仅可以提高设计效率,还能提高装配设计质量,降低装配设计成本。

(3)能支持分布、并行、协同工作方式,同时系统也要具有开放性、可重用性。由于产品异地协同设计和制造、敏捷制造技术、虚拟制造技术等先进的制造模式和技术已经逐渐成为制造工程界研究和应用的热点和重点,从长远来看,就要求系统能支持分布、并行、协同工作方式,使分布在不同地点、不同部门、不同专业背景的人员可以协同工作,交流和共享信息。另外,装配设计系统还必须考虑与其它应用系统的集成问题,这就要求系统要具有良好的开放性和重用性。

上述的几个特点分别从不同的侧面对敏捷化开发环境下产品装配设计系统提出了要求,“支持自顶向下的设计方法”从方法论上对装配设计系统提出要求,它是系统工作的主流程;“能提供智能辅助规划分析工具”是装配设计系统的目的,通过提供智能辅助工具,系统能够协助用户或技术人员更快更好地进行装配设计;“能支持分布、并行、协同工作方式,同时也要具有开放性、可重用性”一方面从系统的组织方式上对装配设计系统提出了要求,因为系统采用的是敏捷制造的组织方式(虚拟企业)和并行工程流程管理的思想进行产品设计;另一方面也对软件编制提出了要求,要求站在发展的角度看问题,设计标准高,理念先进。

2 系统的整体技术方案

敏捷化开发环境下产品装配设计的整体技术方案是以面向产品族的装配建模为中心,以系列化和可装配性为两个实现目标,以敏捷化为最终表现形式[4]。

(1)系列化这条线主要是通过需求分析形成设计需求表,确定产品的总功能并进行功能分解,进而进行产品的模块划分,寻求各功能单元的原理解答形成产品的初步设计方案,并以此为基础进行产品结构设计、详细设计和装配模型重建实现面向产品族的装配模型。在这一过程中产品的模块划分和装配建模是其中的两个重要关键技术,模块划分是实现系列化的前提和基础,它为产品系列化变型设计指引方向,装配建模则是系列化实现的具体过程和最终载体,它通过贯彻模块划分思想来实现产品的模块化设计(既可以有针对性地简化各模块之间的接口,又可以按划分的模块建立各子模块的参数化模型方便产品进行系列变型设计。)。

(2)可装配性这条线从产品设计方案的评价完成以后,始终与面向产品族的装配建模过程相呼应,在结构设计、详细设计阶段分别对产品的结构和零件进行可装配性分析,并在装配模型重建阶段进行产品的装配序列规划、优化、仿真及可装配性评估,以保证最终产品的可装配性。在这一过程中装配建模、装配序列规划、可装配性分析是其中的3个重要关键技术。装配建模既是实现可装配性的前提和基础,也是实现可装配性的最终载体,它为序列规划和可装配性分析提供基础规划和评价信息;序列规划和可装配性分析则是可装配性的具体实现过程和保障,它通过对装配模型进行规划、仿真和评估反馈设计不足和改进意见,促使装配模型始终向可装配方向发展。

(3)装配模型重建阶段是系列化和可装配性的最终实现阶段,在这一过程中装配模型中的约束关模型、参数化模型、层次结构模型因为模型重建而最终形成,可装配评价的结果也因模型重建而得到验证。

敏捷化开发环境下产品装配设计的整体技术方案如图1所示,它将模块化设计、面向装配的设计和自顶向下的设计方法融为一体,既支持产品从概念设计到详细设计的逐步求精过程,自动将设计意图和装配约束向下游传递,同时又将系列化和可装配性两个实现目标蕴藏其中,做到设计方法始终为设定目标服务;另一方面整体技术方案也体现了并行工程的流程管理思想,虽然系列化这条线率先开始,但并不是说可装配性这条线要等到前者完成之后才开始进行,二条线在完成的过程中有相当的并行和重叠(装配建模的同时,分阶段进行可装配性评估,实现设计-评价-再设计的微循环工作方式),相互配合、相互促进、相互补充,最终实现敏捷化产品开发。

3 基于项目管理监控的系统体系结构

根据系统的整体技术方案思想,现将敏捷化开发环境下产品装配设计系统的体系结构分为:界面层、控制层、应用层、数据层及支撑层5层(如图2)。系统体系结构支持分布、并行、协同工作方式,各层的功能如下:

(1)界面层:是用户与系统交互的接口,主要由输入界面和输出界面2部分组成。输入界面用于接受用户的输入(可以是文本、图形、超文本等形式),响应用户的鼠标与键盘事件。输出界面用于将应用层的处理结果以图形化方式或者对话交互形式反馈给用户。将界面层与应用层分离有利于系统的部署和在分布式网络中应用。

(2)控制层:是调度和监控系统协调有序运行的核心,主要包括设计过程监控和网络安全监控2部分。它以项目管理(Project Management,PM)的方式对装配设计工作(包括分布式网络中的协同工作)进行规划、管理和监控,使不同地点、不同部门、不同专业背景的人员可以协同进行设计信息的交流和共享,共同完成产品装配设计的流程。

(3)应用层:是敏捷化开发环境下产品装配设计系统的核心部分,主要分为系统应用和辅助工具2个方面,系统应用包括需求分析、功能分解、模块划分、方案设计、装配建模、装配序列规划、可装配性分析评价等应用技术,其中模块划分、装配建模、序列规划、可装配性分析是敏捷化装配设计系统的主要关键技术。辅助工具主要包括装配仿真工具、各类支持算法、参数化设计工具等等,其中装配仿真工具可对装配模型进行静态、动态以及运动干涉检验和仿真,发现设计过程中的不足之处,同时通过动态干涉检验还可以获取装配体在±X、±Y、±Z等方向的装配干涉矩阵以及装配体的接触联接矩阵等信息。

(4)数据层:用于存取、生成、维护和管理系统运行过程中的各种过程信息和结果信息,主要包括用户需求信息、功能单元信息、模块划分信息、装配语义信息、产品层次结构信息、装配模型信息、装配资源信息、装配过程信息、可装配性评价信息等等。其中装配模型信息是敏捷化开发环境下产品装配设计系统组织和实现的核心和关键信息。

(5)支撑层:调度分配系统的内存资源,支持系统的正常运行和网络应用,为敏捷化产品装配设计系统提供基本的网络通信和安全支持。

4 基于Web Services技术的企业应用集成框架

传统的企业应用集成技术是通过交流使应用双方的通信协义、消息格式、数据模型之间达成一致才能实施[5],但是在敏捷化开发环境下虚拟企业时而重建时而解散,集成用户群的变动很不确定,使得这种“一致”根本不可能实现。Web Services技术[6]是一种基于服务层的集成技术,采用面向对象的技术包装数据,通过简单对象访问协议(Simple Object Access Protocol,SOAP)实现基于Web的不同应用的访问,所构成的系统是一种松散耦合的体系结构,它完全屏蔽了不同软件平台之间的差异,从而为企业应用集成提供了一种全新的机制。为此采用Web Services技术进行企业间与企业外部的应用集成,对现有的应用系统将其进行Web Services包装(其实质是在原应用系统上绑定一个Web Services适配器,该适配器通过本地协议和现有应用系统交互,而在另一端通过SOAP协议与其他的应用系统交互),对于新的应用系统则采用Web Services技术实现。在每个Web Services服务中都封装了具体功能并提供对外的API (Application Program Interface)接口,服务之间通过API进行交互。图3是基于Web Services技术的企业应用集成框架。

基于Web Services的企业应用集成框架具有良好的可扩充性和较高的集成能力,组件复合程度高,可以灵活地实现系统定制。当有新的Web服务出现时,它只需要注册到UDDI服务注册中心即可,Web Services引擎会发现它并根据需要调用它;当有新的请求产生时,只需要在集成规则库中添加新的规则即可[7]。

5 系统原型实现

5.1 系统功能结构

根据系统的需求分析、系统的整体技术方案,从功能上将敏捷化开发环境下产品装配设计系统划分为模块划分、装配建模、序列规划、可装配性分析4个基本模块,如图4所示。

(1)模块划分

模块划分模块由客户需求分析、功能结构维护、相关矩阵建立、模块划分4个部份组成。客户需求分析通过对公司网站收集的客户原始需求进行分类合并形成设计需求,并确定各设计需求的权重;功能结构维护完成新产品功能的分解和老产品功能结构的修改等工作,最终将各功能单元之间流的关系以邻接矩阵的形式存入数据库内;相关矩阵建立完成2类模块划分问题的相关矩阵(功能模块相关矩阵和结构模块相关矩阵)的建立,主要过程是辅助设计人员通过人机交互方式输入打分值;前3部分:客户需求分析、功能结构维护、相关矩阵建立是为第4部分模块划分准备基础信息。

(2)装配建模

装配建模模块为装配设计系统的核心模块,它寄生于三维CAD软件(SolidWorks2005)内,为装配设计系统提供相应的建模环境和建模工具。装配建模模块主要包括方案布局设计、骨架模型建立、属性模型建立、装配模型重建、装配仿真工具、工程图辅助工具等6个部份。方案布局设计完成产品的初步方案设计,为骨架模型的建立提供参考信息,骨架模型的建立意味着各零件的部份装配特征及相应装配关系的确定,从而可以支持零件属性模型的建立,装配模型重建为利用三维CAD软件功能完成最终的装配体、层次结构及参数化设计模型。由于传统三维CAD软件的零件装配不是实体装配方式,零件可从其它零件中穿过,难以检测零件装配过程中的运动干涉情况。为了不受单一三维CAD软件的限制,系统外挂设计了专用的装配仿真工具,在零件详细设计完以后,利用各零件的STL格式文件进行实体装配仿真,包括静态、动态、运动干涉检验,为后续模块提供基础信息支持。工程图辅助工具为零件二维制图提供各种辅助工具,如公差查询、明细表生成、国标工程图符号库、零件各类管理信息输入、常用零件参数化设计功能等。装配建模的核心思想为自顶向下的设计方法。

(3)序列规划

序列规划模块由联系图维护、优先接触联接矩阵、稳定聚合性矩阵、序列规划4个组成。联系图维护为根据装配建模模块获得的接触联接矩阵生成联系图,同时标记各边的序号,生成边与零件序号的对应关系矩阵;优先接触联接矩阵为人机交互确定各接触联接边的优先满足(建立)顺序;稳定聚合性矩阵为装配体稳定性、聚合性影响两评价指标的量化准备初始数据;前3个部分是为装配序列规划准备基础数据,第4部分采用文[8]介绍的算法进行序列规划,筛选较优的可行边序列及其对应的零件序列为后续模块做准备。

(4)可装配性分析

可装配性分析模块为敏捷化开发环境下产品装配设计提供了一个产品可装配性分析、评价、反馈的环境,提供相应的可装配性评价工具和资源,并为上游功能模块提供可装配性分析评价结果及修改建议,以指导装配设计的改进。它包括设计方案可装配性评价、骨架模型可装配性评价、零件可装配性评价、装配过程可装配性评价4个部份。

5.2 系统集成实现

由于装配设计系统中存在大量的人机交互,对鼠标操作的实时反应要求相当高,因此将系统完全做成Web结构,采用通用的浏览器作为客户端,目前的技术水平和网络带宽难以支持。但是采用Web Services技术将一些通用功能抽取出来,在网上发布,不仅可以供本地用户使用,而且还可供合作伙伴使用,真正实现资源可重用、可扩展;同时也可使得原本孤立的系统能够方便地交流数据,达到普遍集成的目的。因此,系统主要采用的是C/S架构。为了方便收集客户需求和客户反馈意见,考虑到普通用户或潜在客户不可能通过Web Services反馈信息,系统也有一部分程序采用的是B/S架构,旨在方便大众用户或者潜在用户输入需求信息或反馈产品信息。

根据上述思想结合系统体系结构和企业应用集成框架,现将应用层(图2所示)拆分为两层,一层为共享Web Services服务层,另一层为基本应用功能层。基本应用功能层与以往的应用层一致,Web Services服务层为从应用层中抽取出来的数据库操作服务、模块划分算法服务、序列规划算法服务、基于熵的定权法服务、最小二乘法求解优良隶属度服务等,供本地客户端、本地其它应用系统、异地客户端、异地其它应用系统调用。图5为敏捷装配设计系统所提供的上述Web Services服务功能页面。

5.3 系统原型开发

系统采用Visual Studio.NET开发平台语言开发客户端,Web Services服务采用ASP.NET开发,后台数据库为SQL Server 2000,三维CAD软件为SolidWorks2005,仿真工具采用Visual C++与Open GL编制。图6为敏捷装配设计系统主界面及功能结构分解界面。

6 小结

本文进行了敏捷化开发环境下产品装配设计系统的需求分析,建立了敏捷产品装配设计系统的整体技术方案,在此基础上构建了基于项目管理的系统体系结构和基于Web Services技术的企业应用集成框架;最后基于上述思想进行了系统原型开发(包括功能结构、集成实现、原型开发),并展示了系统相关功能模块界面。

参考文献

[1]Molloy E,Yang H,Browne J.Feature-based modeling in des- ign for assembly[J].International Journal of Computer Inte- grated Manufacturing,1993,6(1-2):119-125.

[2]De Fazio TL,Edsall AC,Gustavson RE,et al.A prototype of feature based design for assembly[J].Journal of Mechnical Design,1993,15(4):723-734.

[3]岳建鹏，尹文生，吴俊军，等．并行环境下广义装配设计的集成框架[J]．计算机辅助设计与图形学学报，2001，22(4)：373-378．

[4]周开俊，李东波．敏捷化开发环境下产品装配设计系统研究[J]．计算机集成制造系统-CIMS，2007，13(3)：502-507．

[5]吴建斌，张浩然，张长江，周家庆．基于Web Services的企业应用集成平台模型[J]．计算机与现代化，2005，119(7)：107- 109．

[6]袁占亭，张秋余，扬洁．基于Web Services的企业应用集成解决方案研究[J]．计算机集成制造系统-CIMS，2004，10 (4)：394-398．

[7]任晓霞，张蓓，李笑难．面向Web Services的应用集成[J]．通信学报，2005，26(1)：267-270．

[8]周开俊，李东波，于敏捷．改进的装配序列规划方法研究[J]．中国机械工程，2007，18(14)：1676-1681．

敏捷开发走过十年篇2

数据显示,在欧美发达国家,采用敏捷开发的企业已经接近半数,其实用性业已得到证明,但在我国其接受程度要差一些,大约20%〜30%左右。另一方面,像很多新生事物一样,作为一种有别于瀑布式开发方法的新的软件开发方式,敏捷开发也受到很多人的质疑,这也注定敏捷开发成为主流还有很长的路要走。

软件开发不同于工业生产

在软件开发历史上,最有影响的事件是软件工程学的提出。

在计算机刚走出实验室、开始服务于普罗大众之初的上个世纪50、60年代,软件开发更多地表现为开发者的个人行为,基本上处于一种完全无序的状态,没有流程,也谈不上控制。随着计算机的普及,对软件需求的快速膨胀,这种无序开发状态的恶果马上显现出来,开发周期、成本无法控制,软件缺陷率居高不下,最后引发了软件危机,这才有软件工程理论的提出。

软件工程的最大贡献在于,它借鉴了工业生产,特别是流水线生产的管理方法,强调流程的可控性,它提出的经典瀑布式软件开发至今仍然是最为主流的开发方式。在那个年代,软件工程的先进性无容置疑。瀑布式软件开发强调软件开发过程应该严格按照需求分析、设计、编码、测试、维护来进行,从而极大地增加了软件项目的可控性,成本变得可以预测了,这对于大规模的软件开发是非常必要的。而它的不足也很明显,它比照流水线生产来管理软件开发,而忽略了软件开发是一件需要程序员想象力和创造力的工作。

“工业生产追求的是生产效率,如何更快地生产出更多的产品,这一追求跟软件开发的目的是完全不一样的。” ThoughtWorks中国区总经理郭晓介绍说。ThoughtWorks是一家提供定制软件开发的公司,这家拥有1000多名程序员的公司从1999年起就已全面转向了敏捷开发。

郭晓认为,软件开发是一种创造性的、高附加值的、需要发挥人的主观能动性的工作,不是只靠流程改进就可以提高效率的。软件开发区别于传统制造业的另一个不同在于,软件的价值并不在于多长时间内生产出多少份软件,而是在于给业务提供了什么价值。

“软件工程强调的是流程,而敏捷开发颠覆了软件工程这一理论,它的核心理念是人比流程重要。”郭晓说。

帮你做正确的事情

严格说来,敏捷开发并不是一种软件开发,而是一类软件开发方法的总称。“敏捷宣言”中提出了敏捷开发四原则,即个体和交互胜过过程和工具、能工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划,只要是复合这四项原则的开发方法都可以算做敏捷开发,其中最为大众熟知的是极限编程。

“持续集成、快速迭代、重构、测试驱动,这些都是敏捷开发方法区别于传统开发方法之处。”郭晓说,“正是由于敏捷开发的这些特点,使得敏捷开发能更快速、更有效地交付可用的有价值的软件。”

根据Forrester所进行的一个调查,采用敏捷方法之后的软件项目总体的拥有成本都有极大降低,其中缺陷率平均降低63%,核心的缺陷率降低79%,整体投入减少62%,整个项目开发的时间缩短69%。

不过,在郭晓看来,这些并不是敏捷的最大好处,“帮助企业做出正确的事情才是敏捷最大价值所在。至于提高生产率、降低软件缺陷率等好处,都是采用敏捷开发的必然结果。”

郭晓解释说,这里所说的做正确的事情是指,敏捷开发通过持续与用户沟通,以及通过持续集成、快速迭代,让用户得以尽快看到最终结果,从而可以尽快发现早期设计中的错误,比如不切实际的、不必要的功能。另一方面,在沟通中还可以发现新的、更有价值的需求。而这些在传统开发方法中是不太现实的。比如在瀑布式开发中,一旦需求分析完成如要修改就需要比较复杂的流程,而且,进入开发阶段后程序员也很少再听取用户的需求意见。

前行遇阻力

目前,尽管敏捷开发方法已经提出多年,采用这一方法来实现的软件项目也很多,但是,质疑者依然不少。最为典型的说法是这种开发方法仅适用于小型开发团队。对此郭晓表示,敏捷开发最初的确被定位为小型团队的开发方法。但是,这些年来,这种开发方法已经在很多大型组织的大型软件开发项目上得到很好的应用,实践也证明了其在大项目中的可行性。比如,ThoughtWorks公司有些项目参与的程序员就有100多人,采用敏捷开发方法很好地完成了这些项目。另一个例子是英国电信,其内部有上万人的开发团队,也都全部采用敏捷开发方法。而在中国也有一些企业采用,比如中国移动研究院就普遍采用这种方法。

“那些需要快速响应市场变化的互联网公司是敏捷开发的积极拥护者,因为它们等不起。” 郭晓说。

郭晓同时坦言,用户的不理解给敏捷开发方法的应用带来不少阻力。比如,传统软件开发方法非常重视文档,在项目真正开始编码之前一般需要有完整的文档,而敏捷开发难以做到,因为它的需求分析、设计、编码工作等是相互交织的。另外,敏捷开发还特别强调持续与用户交流,很多需求正是在这种交互过程中产生的,同时有些需求也会在这种交互过程中修改,其结果就是项目的预算不像传统开发方法那样一开始就能明确下来。

“在我们的客户中,只要尝试过用敏捷开发方法来完成的项目,很少有不满意的。现在的问题是,有些客户不愿意尝试。”他说。

另外,对于一个组织而言,要想采用敏捷开发,也可能面临不少困难,这也是阻碍敏捷开发普及的重要原因之一。

“最大的问题是企业文化需要变革,管理制度也需要调整。比如,对程序员的传统考核办法是考核其代码量,而敏捷开发方法提倡结对编程和重构,提倡尽量重用代码,过去的那套考核制度就不适用了。”ThoughtWorks中国区技术总监徐昊说,其另外一个身份是敏捷开发的咨询师,指导过很多敏捷开发的项目

徐昊建议,组织初次尝试敏捷开发的方法可以以“持续集成”作为切入点。因为“持续集成”会尽早暴露出大量的问题,比如说架构或者耦合度等方面的问题。“持续集成不是解决问题的灵丹妙药,但是能尽快展现敏捷开发方法的价值。”

不管是徐昊还是郭晓都认为,敏捷开发目前在中国还需要教育和培训。也许正是基于这个原因,ThoughtWorks一直坚持在中国举办敏捷开发大会,今年10月14日〜15日举办的敏捷大会已经是第5届。“5年来,很多中国的程序员通过我们的敏捷大会认识了敏捷开发,而我们对敏捷开发的认识也在不断加深。” 郭晓告诉记者。

供应链敏捷化管理研究篇3

一、敏捷供应链的内涵及内容

(一) 内涵

敏捷供应链 (ajilesupplychain, ASC) , 是指以核心企业为中心, 通过对资金流、物流、信息流的控制, 将供应商、制造商、分销商、零售商及最终消费者用户整合到一个统一的、无缝化程度较高的功能网络链条, 以形成一个极具竞争力的动态战略联盟。“动态”表现为适应市场变化而进行的供需关系的重构过程;“敏捷”用于表示供应链对市场变化和用户需求的快速适应能力。在敏捷供应链中, 计划和协调各实体之间的物流、资金流信息流和增值流, 增加动态联盟对外环境的敏捷性是敏捷供应链管理的主要任务。为了以最低成本、最短时间、最高质量满足客户个性化的需求, 敏捷供应链管理系统必须以单个订单为单位快速制定出订单的执行计划, 并保证计划的可行性。在竞争日趋激烈、市场需求更为复杂多变的网络时代, 有必要将敏捷化思想运用于整条供应链管理, 其实质是在优化整合企业内外资源的思想上, 更多地强调供应链在多样化客户需求方面的速度目标。

(二) 内容

敏捷供应链是在不确定性、持续变化的环境下, 为了在某一特定的市场机会中获得价值最大化而形成的基于一体化的动态联盟和协同商务的敏捷化供应链。它包括以下内容:供应链产品需求预测和计划需求订单管理;基于供应链管理的产品规划、产品设计工程、产品技术保证;基于供应链管理的制造管理、生产集成计划、跟踪和控制;企业内部与企业之间物料采购供应计划;物流管理, 包括运输控制、库存控制、仓储管理等;企业之间资金管理:汇率、成本等问题;战略性合作伙伴关系;供应链的设计:全球节点企业资源的评价、选择和定位;基于供应链的客户服务、分销管理、市场营销;供应链的业绩评价;基于网络的供应链交互信息管理和EDI技术。

二、供应链的敏捷化原则和方法

为了应对竞争日益激烈的市场, 在设计或重构供应链时应该遵循如下的原则:感觉与响应。这是将实时获取的市场信息融合到供应链业务环境中, 并且连续不断地调节自身行动的一种能力, 主要从实时可见性、事件管理和动态计划等方面入手。虚拟与集成。用信息技术将供应链中企业连接起来, 组成临时性网络联盟, 共享相关源。不仅如此, 还应将供应链中的业务流程进行分解, 重新组合成满足要求、紧密联系的新系统, 最终达到无缝集成。即插与即用。对产品来说, 其部件能够迅速的配置、组合, 更能够对部件进行生态系统统计;对供应链组织来讲, 也要将其业务能力模化;学习与适应。在不断积累的组织经验中修正供应链的实践和模型, 将其变成一个学习组织。

基于上述的原则, 设计敏捷供应链主要有以下方法:

第一, 重新定义业务边界。在重新定义业务界时要着重考虑、识别供应链的现在核心业务及将来的变化趋势, 清楚其战略能力、关键技能、资源和资产及其保护方法, 获取关键的竞争能和保护竞争优势的途径。

第二, 开发关系能力。这些关系包括:交叉股和战略联盟、联合投资和许可证协议、合作公司网络、技术交换和知识转移、合股、财团和市场联盟。

第三, 使用电子商务。电子商务的使用使信信共享的速度加快, 而且也会改变经营模式。敏捷供应链的最终形式是将供应链的所有成员形成一个供应链共同体, 供应链经过合作成员之间的集成发展到协调的、利益一致的供链共同体———一个创新性企业, 而且在不远的将来这种企业能够超越集成, 形成一个大约拥20个成员, 其中一个成员占有主导地位的共同体。共同体内最适合的成员应该具备的条件是:拥有相同的ERP应用系统、相似的组织结构、类似的业务处理方法和企业文化等。共同体内的成员既是合作伙伴, 也可能是直接的竞争对手, 其目的是共同分享能力来开发供应链。

因此, 我们也可以将敏捷供应链称为适应供应链 (Adaptive Supply Chain) 或扩展性企业 (Extended Enterprise) 。

三、实现供应链敏捷化的条件

(一) 在低成本的前提下实现敏捷性

很多人认为, 在我国的竞争环境中, 低成本仍然很重要, 不能用高成本去实现敏捷供应链。那么低成本和敏捷性是否可以兼得, 如何在低成本的前提下实现敏捷性?

低成本和敏捷性是供应链目标的两个方面, 这两个目标并不矛盾。一提到低成本, 很多人首先想到的就是规模经济, 而一提到规模经济就会觉得是按照库存生产, 而非按订单生产, 从而让人觉得没有敏捷性。

其实不然, 这牵涉到供应链中“推”和“拉”的关系, 关键在于“推”和“拉”的临界点所在。企业可以在产品最终完成前, 大规模地生产几个产品公用的标准件, 降低成本。在后面组装阶段采取按订单组装和增加其他配件, 提高敏捷性。

低成本与敏捷性可以说是我国每一个企业梦寐以求的目标。两者很难兼得, 但优秀企业能够在二者之间取得很好的平衡。从欧美大多数企业的实践看, 单一供应商体系应当是实现这两者之间平衡的最有效的做法, 这需要企业之间存在高度信任并且紧密配合。但我国企业的供应体系普遍是多元的, 奉行“不把鸡蛋放在一个篮子里”的哲学。从整体上看, 单一供应体系仍然是平衡低成本与敏捷性的有效方法。

端到端的供应链成本, 反应速度、灵活性、敏捷性, 产品和服务可靠性是相互影响的。一个好的供应链策略必须能够依据企业、产品与市场的定位来策划, 如果只是一味追求降低成本和提升敏捷性, 没有经过全方面的分析与考虑, 可能会得不偿失。降低成本并提升敏捷性的做法有:非核心能力作业外包, 与供应商协作提升原物料品质, 提升企业间的资讯透明度, 优化流程等。企业要和供应商达成协同, 信息化工具是不可缺少的。

(二) 信息系统是促成敏捷供应链实现的基础

敏捷供应链的关键在于企业之间的信息集成和共享, 信息系统是促成敏捷供应链实现的基础。技术的更新、提升与普及应用相对提升了供应链的敏捷性。比如, EDI (电子数据交换) 、EFT (电子资金转账) 、RFID等自动识别技术为供应链管理提供了更有效的技术支持, 也使供应链更为敏捷。

不能为了引进信息系统而引进信息系统。在供应链中, 信息系统如果得不到合理的运用, 它只能是个没有灵魂的摆设。信息系统在供应链中的运用有3个层次:最底端的就是供应链运用于操作, 其次是运用于管理, 最后能发挥信息系统优势的是站在战略角度应用和发展信息系统。沃尔玛就围绕其信息系统做战略部署, 把信息系统、人和组织以及战略目标三者很好地融合在一起。但我国目前大部分企业还停留在第1个层面和第2个层面。

以汽车行业为例, 现在市场竞争非常激烈, 厂家如果要保持市场占有率, 有一种方法就是降价, 那么就一定要在成本方面做工作。作为整车厂是不会独自承担这个压力的, 它会要求所有的供应商与其分担, 供应商又会要求他的供应商与其分担, 这样一级一级地推下去。这样, 就要求降低库存, 供货的透明度一定要大, 供应商一定要知道客户生产的计划、数量等详细的信息。现在汽车制造的配套比以前要复杂很多, 如原来可能就是黑颜色的车内配红颜色的椅子, 现在可能黑色车里要配黄色椅子, 而驾驶台要紫色的, 等等。要让这些复杂的生产信息变得透明, 只有充分发挥信息系统的作用。

(三) 从管理架构和体制上保证供应链的灵活

基于供应链的管理思想, 要求采购、生产、销售企业内部的3大块业务要协同, 这就要求采购部门能够融入到整个供应链中。以前采购部门是自我封闭的———自己做供应商评估, 自己来谈判, 自己来设定成本。高效供应链要求的是整体的快速响应, 必然要求指标一体化、管理主体一体化。因此, 研发部门、生产部门、物流部门等都会对采购部门提出要求。现代采购已经逐步形成了跨部门协同的趋势。我国本土企业目前对供应商的管理还是很弱的, 而且主要是由采购部门来主导, 包括评估指标的设计等。采购部门有能力设计技术指标、质量指标等一系列专业化的指标吗?一般来说, 采购部门不可能做得很好。而且从我国的现实来看, 采购人员大多没有受过系统的训练, 他们的管理方法完全构建在经验的层面上。从理想的状态来看, 对供应商的管理应当跨部门来设计指标并且参与评估。不仅在供应商进入的时候要评估, 在合作的过程中也要评估。

在具体的方法上, 一是可以在管理的组织结构上进行变化。比如原来是一个CEO下面4个副总裁, 他们分别负责不同的职能部门。现在, 某些企业出现了变化, 他们把整个企业的运行分成两大块, 一块基于直接的价值创造, 一块基于支持和服务。前一块由一个独立的主体来控制, 而不再像以前分得很细。二是绩效评估系统要随之转变———以前是采购、生产、销售单独评估, 现在绩效评估一体化, 即评估负责整个业务的部门或人。三是对商业流程进行规划与完善。很多企业的流程整体性很弱, 到了一个部门就中断了, 另一个部门还需要重新起头。因此, 只有流程要对接才能成为一个整体。

参考文献

[1]、郑海浪等.敏捷供应链分析[J].商品储运与养护, 2005 (1) .

敏捷化开发篇4

1 敏捷开发

敏捷开发是由15个科学家共同提出来的,其中包括来自思特沃克公司 ( Thought Works) 著名的软件大师马丁·福勒 ( Martin Fowler)[1]。敏捷开发即一种全新而快捷的软件开发模式,是把人放在第一位,以满足用户不同需求为导向的开发模式[2]。应用敏捷开发的方法,要求团队成员具有很强的主动性,满足了高内聚、松耦合的原则把项目分成了若干个小组。较少的文档准备和分组的新方式缩短了软件开发周期,开发过程中的多次迭代和测试提高了软件的质量[3]。

2 敏捷技术的重要性

从目前敏捷开发的研究现状中,我们可以看到在任何一个软件的开发过程中,任何的一种模式都不是能解决所有问题的万能钥匙,所以在软件开发过程中应全面考虑所有的问题,不管是开发方法、设计模式还是设计架构都是必须考虑的重要因素,而就目前敏捷开发的应用研究来看,敏捷开发的过程,对技术并没有明确的指导思想,这也正是多数项目在应用敏捷开发过程中失败的重要因素。

从根本来说,敏捷开发不仅是一个软件开发过程的方法论,准确地说它更是一种思想,但这种方法是建立在敏捷技术上的,敏捷技术为这一方法的实施提供了可行性,只有敏捷的技术才能支撑敏捷开发的实施[4]。真正的敏捷开发不只是管理层次的敏捷、项目参与人员的敏捷,架构的设计也应该是敏捷的,编程思想也应该是敏捷的,这才是实至名归的敏捷开发。在项目真正进行过程中,为了能更好地发挥敏捷开发的优势应做到管理与技术同步规范。管理与技术是不可分割的,二者相辅相成,技术的敏捷使得敏捷开发方法的实施具有一定可操作性,是敏捷开发方法的基石,如果没有相关技术的支持,敏捷开发是不能完全发挥效应的甚至是不可行的。只有做到管理与技术同步敏捷,在管理的过程中得到相应技术的支撑,敏捷开发方法才能发挥真正的敏捷,才是真正的敏捷思想。

2. 1 简单三层

敏捷开发方法要求在敏捷开发实施过程中,如何保证开发团队的每个开发人员能够独立地进行系统模块开发是敏捷开发能否成功的关键因素。而以往的传统开发技术,并没有将系统模块化,整个系统的耦合性较高,依赖性较强,使用传统的开发技术并不能实施敏捷开发方法,使得敏捷开发提倡的系统各模块之间并行开发成为空想。简单三层却为这一要求提供了可行性。

三层架构由底层至上层分为数据访问层 ( Data AccessLayer,DAL) ,业务逻辑层 ( Business Logic Layer,BLL) ,用户界面 ( User Interface,UI)[5]。简单三层将界面的呈现、业务逻辑的处理以及访问数据库很好的分离开来,因此在系统实现编码过程中不仅可以实现系统各模块的并行开发,而且不要求全能型的开发人员,只需精通其中一层即可参与到项目当中,在保证工作高效且代码质量的同时节约了开发成本[6]。在测试方面,三层也可同步进行,可以解决敏捷开发在测试环节中给项目带来的成本偏高问题,在支持敏捷开发实施的同时,又保证了整个系统的安全,降低了系统的复杂性,无形之中也提高了项目参与人员的积极性,使得敏捷开发能够顺利进行。

2.2 抽象工厂模式

敏捷开发提倡的是拥抱变化,要求在开发过程中进行多次的迭代,项目团队进行周期性的交流沟通,随时应对客户的需求变化,勇敢地面对变化,对于用户的反馈,程序员要有勇气对已经编写好的代码进行适当的修改[7]。敏捷开发里所说的勇于接受变化并不是简单的要求项目团队在客户提出新的要求时,就将之前的系统全部放弃,从头再来,这并不是真正意义上的敏捷开发。但是面对这样的需求敏捷开发只是单纯的提出了要求,并没有对此有进一步的说明和指导,而为了满足更换数据库的需求重新编译数据操作类就相当于项目从头开始,又不是最好的解决办法。如何在面对客户需求的时候,尽可能地减少代码的修改量,代码的复用性是一个关键因素。想要提高代码的复用性,就想到了设计模式,在当前的设计模式中,抽象工厂模式很好地解决了这一问题。

作为创建型模式的抽象工厂模式是23种设计模式中的一种,所谓创建型模式就是不需要自己实例化对象,而是由创建型模式来代替新操作[8]。抽象工厂模式指的是提供一个创建一系列相关或者相互依赖对象的接口,而不需要指定它具体的类[9]。该类设计模式是专门针对需求的变化来达到提高代码复用性目标的一种模式,它就相当于一个实实在在的工厂,只不过与我们现实生活中的工厂不同的是现实生活中的工厂是用来生产产品,但是这里的工厂是用来管理变化的。

使用抽象工厂模式将可变的进行封装,以接口的形式呈现,在三层中应用抽象工厂模式,在不需要修改以前代码的前提下轻松地解决了更换数据库类型这一需求,并且在系统开发完成之后甚至是使用过程中,都可轻松地更换数据库类型,有效地解决了由于需求变化导致开发周期延长,并且为系统的后期维护降低了成本。

2.3 ASP. Net MVC

客户的需求贯穿于整个项目中,虽然敏捷开发中采取先测试再编码的方式有效地应对了客户需求的变化,但是并不排除客户对测试满意,开发完成之后又提出了新要求的可能性存在。对于大多数客户来说需求的变化主要体现在系统功能和界面展示方面,针对这一可能性传统的敏捷开发并没有很好的解决办法,只能重新编写,重新测试,但是这一问题是周而复始的,这样的做法治标不治本。应对这一状况就应考虑到从技术方面入手。

在通常情况下,系统的页面开发都是用网页表格( Web Form) 进行,虽然网页表格 ( Web Form) 操作简单,可以直接拖控件对页面完成布局工作,但是它的页面展示与后台逻辑代码的耦合度较高,在遇到客户对页面布局要求变更的时候,不仅要进行页面布局的修改,还要将相应的页面逻辑进行修改,这无疑多做了很多没有必要的工作,这时ASP. Net MVC框架成了解决这一问题的第一选择。

ASP. Net MVC是微软在2009年对外公开发布的第一个开源的表示层框架[10]。ASP. Net MVC模式是一种表现模式,它可以将表现层分成模型 ( Model ) 、控制器( Controller) 和视图 ( View) 三个组件,有效地分离了页面展示与用户界面 ( UI) 逻辑代码,所以ASP. Net MVC是一个更加倾向于用户界面层 ( UI) 的表现层框架,是网页表格 ( Web Form) 的另一种选择[11]。在面对客户对页面展示需求变化的时候,只需更改相应页面的展示效果即可。

3 敏捷技术应用实例

3. 1 项目简介

本校的博士研究生招生工作在2013年之前均是通过工作人员手工的录入以及核对完成的,因此,本校博士招生工作存在效率低下,管理无序,数据安全性较差等诸多问题,实施办公自动化对于我校的博士招生工作具有重大意义。本项目将采用本文所提及的融合敏捷技术的敏捷开发方法对系统进行开发。

3.2 敏捷技术在开发中的具体应用与实现

根据上述分析,博士研究生招生系统的整体架构见下图。

从上图中我们可以看到,本系统结合了简单三层架构、抽象工厂设计模式和ASP. Net MVC框架三大技术,本系统使用2011年发布的ASP. Net MVC3. 0版本[12]。本论文主要从这三个技术的应用上进行详细论述,来论证敏捷技术对敏捷开发的重要性。

3. 2. 1 抽象工厂模式在数据访问层的应用

对于本系统的开发主要是针对学生各种信息的管理与操作,并且录取的学生信息数据库要与我校现有的各种学生工作系统进行衔接,而所用数据库并不相同,对现在已经使用的系统进行修改并不是一个好办法,只有针对目前着手开发的博士研究生招生系统进行完善,来迎合不同数据库的需求。解决这一需求的办法就是抽象工厂模式。本文以考生登录功能为例进行技术应用说明。

创建抽象工厂类,利用 . Net的反射机制获取数据访问层的程序集和命名空间的名称,通过数据访问接口层来创建user_ infor数据表的实体类,并采用缓存技术来提高系统性能,设置当前应用程序指定Cache Key的Cache值的核心代码如下:

由于数据访问层融合了抽象工厂设计模式的思想,所以业务逻辑层调用数据访问层是通过数据访问接口层创建相对应的数据工厂实例,并没有指定具体的数据操作类,因此,在面对更改数据库类型时,只需修改配置文件的程序集和命名空间的Value值即可,配置文件代码如下:

由此可见,应用了抽象工厂模式和反射机制加上配置文件的使用,在不需要修改系统代码的前提下轻松实现了异库移植操作,并且为本项目实施敏捷开发时适应了需求且缩短了开发周期。

3. 2. 2 ASP. Net MVC 框架的应用

在ASP. Net MVC中UI逻辑在Controller组件中进行编译,Controller负责将数据从Model取出传递给View[13]。在本系统里,ASP. Net MVC代替网页表格 ( Web Form)作为三层中的用户界面层 ( UI) ,所以在界面展示编译中,ASP. Net MVC框架中的控制器 ( Controller) 组件则负责与业务逻辑层进行对话,从业务逻辑层调用校验用户的方法来获取数据库中的考生登陆信息。判断登陆是否成功的部分代码如下:

前台的页面布局交由视图 ( View) 组件负责,由于它与控制器 ( Controller) 组件的低耦合性,视图 ( View)的页面展示只需单纯的Html标签即可实现,并且不需要将标签ID传到后台,实现了UI展示与UI逻辑的彻底分离。登录页面的视图 ( View) 核心代码如下所示:

从以上代码我们可以看出,视图 ( View) 页面都是由Html标签实现,所以在更换页面布局的时候就不需要考虑前台标签与后台逻辑的绑定问题,不需要修改用户界面 ( UI) 逻辑代码。

4 结论

敏捷化开发篇5

关键词：客户化,精益敏捷供应链,集成,延迟差异

供应链管理是一种集成的管理思想[1], 其发展过程是一个不断集成的过程。1995年, Berry[2]认为精益可以从成本的角度提高供应链的性能, 而敏捷可以在质量上提高供应链的性能, 结合二者优点, 将精益和敏捷的核心思想应用于供应链管理, 从而提出了精益敏捷 (Leagile) 战略思想。

一、客户化精益敏捷集成供应链模型设计的基本原理

根据供应链集成的思想原理, 运用延迟差异策略和产品标准模块化设计, 以客户订单分离点 (Customer Order Decoupling Point, CODP) 为延迟差异边界, 将产品整个生产制造过程分为前段制造过程 (推动阶段) 和后段制造过程 (拉动阶段) 两个阶段。前段为供应链通用化过程, 按照长期预测组织生产和运送基本功能单元, 即由预测驱动 (Driven By Forecast) , 从事功能性产品和创新性产品的通用模块 (固定部分) 的生产、装配、包装的过程, 以推动运作方式为主, 采用精益供应链模式, 实行改进型有效消费者响应策略, 实现大规模生产, 发挥规模经济优势;后段则按订单生产和总装, 即由需求驱动 (Driven By Demand) , 实现产品差异化, 从事产品专用模块 (变动部分) 的生产, 对产品定制单元进行生产、装配、包装及运送, 以拉动运作方式为主, 采用敏捷供应链模式, 实行改进型快速响应策略, 实现定制生产, 发挥范围经济的优势。由此设计客户化精益敏捷集成供应链的通用结构模型。

一方面, 标准模块化设计是面向产品结构的设计, 它体现了大规模定制企业充分利用规模经济的效应;另一方面, 延迟差异策略则是面向大规模定制过程的重组思想。模块化设计为延迟差异策略提供了基础, 没有标准化的模块和零部件, 定制企业很难把客户的定制要求延迟到供应链的下游, 因此也难以对客户需求做出快速响应。标准模块化设计与延迟差异策略是大规模定制生产的两大策略, 只有这两大策略相互结合, 才能充分体现出大规模定制生产的优势, 才能提升整个供应链的整体竞争优势。

二、客户订单分离点的确定

客户化精益敏捷供应链模型是对推动式和拉动式两种供应链结构的集成, 在注重发挥规模经济的同时注重发挥范围经济的优势。在整个供应链模型中, 客户订单分离点之前的活动不是针对某个特定订单的, 而是依据对市场需求的预测和分析, 按客户的一般需求组织通用/标准单元的大规模生产;而客户订单分离点之后的活动是根据订单确定的, 依据订单的特殊需求组织定制/专用单元的定制化生产与运作。客户订单分离点确定合理与否直接影响延迟差异策略运作的效果。客户化精益敏捷供应链模型, 要求把产品的定制活动延迟到供应链的下游进行。通过延迟客户订单分离点, 可以降低制造过程的复杂程度, 减少供应链的不确定性, 以及降低成品库存, 缩短定制时间。客户订单分离点的确定受客户需求的影响, 客户订单不同企业的生产类型不一样, 合理客户订单分离点位置也不一样。本文根据客户订单不同类型, 将企业分为:按订单销售 (Sale-to-Order, STO) 的企业;按订单装配 (Assemble-to-Order, ATO) 的企业;按订单制造 (Make-toOrder, MTO) 的企业和按订单设计 (Engineer-to-Order, ETO) 的企业, 并根据其特点, 确定与之相适应的客户订单分离点位置。STO企业, 客户订单分离点应位于销售与装配两个阶段之间;ATO企业, 客户订单分离点应位于制造和装配两个阶段之间。MTO企业, 客户订单分离点应位于基型设计和变型设计两个阶段之间。ETO企业, 客户订单分离点应位于开发设计之前。

三、结束语

通过对精益供应链和敏捷供应链的集成有效集成了大规模生产与定制生产, 从而实现大规模定制 (Mass Customization, MC) 的生产模式, 保持以较低的总成本和较短的交货提前期, 为客户提供定制化产品, 全面提高客户满意度, 形成现代制造业所共同追求的竞争优势。

参考文献

[1]马士华　林　勇　陈志祥:供应链管理.机械工业出版社, 2000:84￣86

敏捷化开发篇6

关键词：珠三角,保税物流,敏捷化

1前言

珠江三角洲地区(以下简称“珠三角地区”)处于我国改革开放和发展外向型经济的前沿,拥有数量众多的跨国企业、成熟集中的产业群、宽松开放的外贸和海关政策以及发达的物流基础设施和网络,该地区多年来外贸经济的高速发展催生了保税物流这一特殊物流形态,并使之迅速发展和逐渐成熟。

珠三角地区的经济发展客观上要求该地区保税物流运作实现最大程度的敏捷化。在多年的发展过程中,珠三角地区物流企业各类国际性进出口以及保税物流业务的基础上经过实践形成了更加前沿和先进的敏捷化策略,对促进区域经济的迅猛发展起着至关重要的支撑性作用。

2珠三角地区保税物流体系发展概述

自从1990年5月国务院批准建立上海外高桥保税区以来,我国先后总共建立了15个保税区,其中珠江三角洲地区(以下简称“珠三角地区”)建有包括深圳福田、沙头角和盐田港以及广州、珠海5个保税区,占全国全部保税区的1/3。

据有关研究资料表明,以外向型经济为特征的珠三角地区经过多年的发展已和长三角、京津冀环渤海区域成为我国三大最活跃的经济区域,珠三角地区已形成当今世界最大的出口商品产业群,世界出口货物总量的50%集中在东南亚及华南,而其中五成集中在珠三角地区,在珠三角地区发展保税物流具有巨大的潜力。经过近三十年的发展,珠三角地区目前拥有包括以保税仓库和出口监管仓库为基础、以保税物流中心为网点、以出口加工区、保税区为支柱、以保税物流园区和保税港区为最高层次的、成熟的、全方位立体式的保税物流基础设施体系。

3珠三角地区保税物流敏捷运作策略案例分析

珠三角地区经过多年的改革开放,吸引了很多企业包括世界500强以内的跨国公司纷纷进驻,这促进了外贸业务的飞跃增长,而由此同时也推动保税物流运营在敏捷化方面形成了一些比较典型的模式。这些敏捷化模式往往是通过海关创新、企业应用实践以及引进国外先进物流管理理念相互作用而成的,以下为部分具有代表性的保税物流运营敏捷模式应用的案例。

3.1 供应商管理库存(VMI)策略

VMI模式是通过第三方物流服务商的快速作业和信息化的处理,来建立供应商和制造商之间的快速物料配送的一种模式。

该模式的特点是:货物存放在第三方物流仓库;物权属于供应商所有;制造商与供应商协商决定库存水准和持续补货策略;按生产的实际用货量进行配送及安全库存补货,这种情况下对供应商的快速供货能力的要求非常高,否则会造成库存的积压。

其适应范围有:价格敏感、掉价风险大的通讯电子产品;响应性水平要求高,制造复杂、需多方采购零部件组成的产品;需求极度不稳定,难以提前存库的产品。

实施该模式的前提和条件为:第三方物流企业拥有综合性的物流资源。如运输、仓库、报关处理人员和管理人员,特别是对国际性供应链而言,物流运营的通关操作是最难控制的环节。

VMI模式原先由部分从事电子产品制造的跨国企业使用,以“快速通关、优先验放、直接转关”的时效性运作策略为基础,保证制造商能在规定时间内收到关键零配件并用于生产。制造商通过在特殊监管区域或保税监管场所建立由第三方物流企业来运营的配件仓库,仓库所在区域的主管海关将对其供应链的运营采用以下敏捷模式。

①快速通关。

提供区别于常规性通关的绿色通道审单窗口供物流企业在进出货物申报时使用,以此可保证物流企业和供应商供货入相关区域的物流仓库的运营效率较高,通常可以控制海关对申报资料的审核时间在1小时以内甚至更短,而通常申报的审核时间在2小时以上。如DELL(戴尔电脑公司)通过BAX(美国伯灵顿物流公司)在厦门象屿保税区设立配件仓库进行VMI模式运营,海关提供了快速通关的便利。

②以直接转关代替常规的提前转关。

通过直接转关(注:转关是指从一个海关所在地将货物在海关监管下运输到另一主管海关所在地而进行申报的一种方式),从第三方物流仓库所在地转关到制造商工厂所在地海关,可以先放行货物和单证,后在制造商工厂一站式验放和处理,从而保证1小时以内完成所有转关手续。

③到达地海关验放通关,减少了始发地海关货物的滞留时间。

3.2 生产零库存(JIT)及时配送运作策略

JIT和VMI模式类似,主要是针对于成套关键零配件的供应。在该种模式下,制造商不再保有库存,而是要求供应商随时供应有关物料,直接配送到生产线,这对供应商和物流企业的要求更高,所以往往将中转和配送设置在通关便利的特殊监管区域内。

该模式主要是针对敏捷生产、精益生产型制造企业:如汽车、电子产品。此类企业的供应链运营对零部件的配套要求高;另外也包括成套产品的组装、零部件分散、标准件多、通用性强的制造业。

部分汽车生产厂家或电子高科技产品制造商以结合了时效性和效益性的运作策略,形成了“分批出货/集中申报/提供税款担保/先放后税/绿色通道”的敏捷化策略来支持JIT模式,所有关键零配件都存放于特殊监管区域和保税监管场所,第三方物流公司一旦收到生产厂商的指令迅速整理有关货物,并以快速通关模式向保税区域海关申报出区。

这种背景下采取敏捷运营策略需要做到以下几点:

①使用绿色通道。

通过使用特殊的优惠通道如绿色通道,企业仅凭其仓库出货单而不是正式的报关单直接报关,海关人员在简单验核后快速放行车辆,通常仅需要不到5分钟的时间。

②提供税款担保。

由于企业的强大影响力和预先提供了税款担保,对于一般贸易的货物也可以通过海关提供的绿色通道先出区后报关。

③集中报关。

绿色通道的模式需要企业在事后进行集中报关,就是在企业凭清单进行简易通关后,然后在税款缴纳期限内集中将每月或半个月所有的清单数据累计后向海关正式申报。

通过该模式,供应商或物流服务商可以实行敏捷通关,在150公里的范围内可以做到在收到制造商的发出送货需求指令后两个小时内将货物保证送到生产线,从而实现了企业对急需关键零配件的及时供应和生产零库存的目标。

3.3 集中采购、快速进口、分散配送(MILK RUN)策略

该策略是一种送牛奶式(MILK RUN)的巡回运送策略。其运营流程是:一辆卡车从境外进口多种产品后快速在国内分散配送给多个采购商。这对通关速度和操作效率的要求非常高,从而给保税物流运营的敏捷化操作提出了挑战。

该策略目前为少数在国内领先的供应链物流综合服务商所使用,特别是在满足以一般贸易方式进口货物的快速通关需求方面,通过应用该敏捷运营模式,不少物流服务商获得了在物流行业内的竞争优势,在通关操作方面则通过口岸海关应用“绿色窗口/优先通关/税款担保”的时效性和效益性运作策略。

其基本操作是先在口岸海关申请以绿色窗口优先审单、优先放行,再辅以提供税款担保的模式,以降低审价时间和查验率,从而实现为国内中小企业代理采购,在口岸海关放行后,物流企业以国内普通车辆运输代替跨境监管车辆运输,然后迅速进行一站式分散配送。

3.4 跨境通关、快速配送运作策略

对于供应商在国外、制造商在国内、主要零配件由境外供应的情况或对在国内生产生命周期短、面市速度快、生产时间紧的产品,物流企业往往需要跨境快速配送零配件以供应制造商生产。这对在国际物流保税运营操作中的运输工具监管和信息化集成的要求很高。如目前珠三角地区对跨境快速配送的车辆要求是:属于海关批准的监管车辆,装备指定的GPS系统,由海关施加电子关锁,按固定区域和固定路线(绿色通道)行驶,并由指定口岸通关。

已运行成熟的通过在由香港机场和香港葵涌码头到深圳华南物流中心和其他站点的快速配送如“深港物流绿色通道”和“深港物流绿色通道”则属于此类策略,这是对时效性和区域性运作策略的综合应用而形成的。主要运营流程是:境外供应商在接到国内制造商发出的关键零配件订单后,通过空运方式迅速将料件从东南亚地区送达香港机场,然后通过跨境快线送到华南物流中心或指定的海关监管站点,再由制造商在相关站点办理通关手续后送往深圳或东莞的工厂加工。如果物流商和供应商配合良好,该模式可实现在接到订单后半天以内送达工厂的时效,这可解决珠三角地区内加工企业断料的隐患。

3.5 保税仓库的“集中申报”运作策略

该种策略是企业通过对区域性和时效性运作策略整合而成的一种新的敏捷化策略,由珠三角地区的黄埔海关率先在其关区范围内应用。“集中申报”是指对公用型保税仓库存放的保税货物,可允许分批出仓,后集中申报。通过使用该模式可以有效建立敏捷供应链供应商管理库存(VMI)和生产零库存管理(JIT)模式,并且满足7×24小时物流快捷运作的需求。以诺基亚东莞分公司为例,诺基亚东莞分公司使用了“集中申报”模式之后,公司业务每年以翻倍的速度增长,该公司2005年的产量是2300万台,2006年迅速增长到了6000万台,到了2007年,产量已增到1亿台。

4结语

珠三角地区在保税物流业态方面的敏捷化创新会随着国内外经济贸易业务格局的变化而不可避免地深化,这将增强区域性的经济活力,同时也可提升区域在全球化进程中的经济地位,保税物流业态作为推动我国外向型经济扩张的主要基础性支撑行业,必须不断以经济形态为核心,创新运作策略,以实现敏捷化的目标,才能保持区域经济的核心竞争力。

参考文献

[1]中国海关总署.抓住机遇深化改革海关将建立健全新型保税监管体系[EB/OL].中国海关网(http://www.customs.gov.cn),2006-04-17.

[2]赵光华.海关保税物流监管体系综述[J].物流技术与应用,2007,03.

[3]张强.珠三角仓储行业发展报告[EB/OL].中国物流产品网(http://www.56products.com),2009-08-06.

[4]广州海关.推动特殊监管区域建设特殊区域成为区域经济发展“发动机”[EB/OL].广州海关网(http://guangzhou.customs.gov.cn),2009-02-26.

[5]李玫.保税区谋求与国际惯例接轨新突破[EB/OL].深圳新闻网(http://www.sznews.com),2008-12-19.

敏捷软件开发实践总结篇7

软件危机一方面是由软件生产本身存在着复杂性,另一方面却是与软件开发所使用的方法和技术有关。软件工程学正是为克服软件危机而形成的新的学科,但可惜的是时至今日人们并没有完全克服软件危机。

软件开发中当连续地犯错误时,我们会对错误进行诊断,并在过程中增加更多的约束和人为制品来防止以后重犯这样的错误。经过多次这样的增加之后,我们就会不堪巨大、笨重的过程的重负,极大地削弱我们完成工作的能力。一个大而笨重的过程会产生它本来企图去解决的问题。降低了团队的开发效率,使得进度延期,预算超支。它降低了团队的相应能力,使得团队经常创建错误的产品。遗憾的是,许多团队认为,这种结果是因为他们没有采用更多的过程方法引起的。因此,在这种失控的过程膨胀中,过程会变得越来越庞大。

2001年初,由于看到许多公司的软件团队陷入了不断增长的过程的泥潭,一批业界专家聚集在一起概括出了一些可以使软件开发团队具有快速工作、响应变化能力的价值观(value)原则。他们称自己为敏捷(Agile)联盟。在随后的几个月中,他们创建出了一份价值观声明。也就是敏捷联盟宣言(The Manifesto of the AgileAlliance)。

敏捷联盟宣言如下:

(1)个体和交互胜过过程和工具。

人是获得成功的最为重要的因素。如果团队中没有优秀的成员,那么就是使用好的过程也不能挽救失败的项目。但是,不好的过程却可以使最优秀的团队成员失去效用。如果不能作为一个团队进行工作,那么即使拥有一批优秀的成员项目也会失败。

一个由平均水平程序员组成的团队,如果具有良好的沟通能力,将要比那些虽然拥有一批高水平的程序员,但是成员之间却不能交流的团队更有可能获得成功。

团队的构建要比环境的构建重要得多。应该首先致力于构建团队,然后在让团队基于需要来配置环境。

根据调查总结:一般团队都具备创业型团队的特点:一个优秀的lead,带多名水平一般的员工;这样的团队存在两个问题:1)优秀员工的引入,受lead的水平限制;2)员工各自为政的开发模式,分享不够。

团队中的优秀人才并不是越多越好,优秀人才太多反而有更大的弊端。一是人力成本太高,他们可能消耗掉产品创造的大部分效益,那么就不划算了。二是团队分裂的风险太高,因为团队的空间有限,无法同时满足很多优秀人才事业发展的欲望;所以,团队的优秀人才恰好够用就行。

软件开发团队的lead应当具有四项素质,按级别从低到高排列;不错的技术才能(一段)较强的管理才能(二段)丰富的产品开发经验(三段)敏锐的商业头脑(四段)。目前大多数IT企业在物色团队的领导时,主要考察候选人的管理能力和技术能力。对于搞技术出身的人,如果他能当上小头目,一般地讲他的技术才能不会太差。然而即使技术水平是团队里最强的,如果他不具备带领团队所有成员正确干活的能力(即管理能力),那么他也就不不适合当lead。

(2)可以工作的软件胜过面面俱到的文档。

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。然而,过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间,要使这些文档和代码保持同步,那么就要花费更多的时间。如果文档和代码之间失去同步,文档就会变成庞大的、复杂的谎言,会造成重大的误导。

( 3 ) 客户合作胜过合同谈判。

成功的项目需要有序、频繁的反馈。不是依赖于合同或者关于工作的陈述,而是让软件的客户和开发团队密切地在一起工作,并经常地提供反馈。项目成功的关键在于和客户之间真诚的协作。

( 4 ) 响应变化胜过遵循计划。

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

较好的做计划的策略是:为下两周做详细的计划,为下三个月做粗略的计划,再以后就做极为粗糙的计划。计划中这种逐渐降低的细致度,意味着我们仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划,就很难进行改变,因为团队会根据这个计划启动工作并有了相应的投入。然而,由于计划仅仅支配了几周的时间,计划的其余部分仍然保持着灵活性。

综观上述四个过程,敏捷开发强调以人为中心,而不是以过程为中心,强调尽可能的沟通(与客户,与团队成员),尽可能地以最简单的设计解决问题(从而能够拥抱变化)。

敏捷开发不同于以往的瀑布式开发,非常适合需求变动的情况,敏捷开发的工作量是随着需求的变化而不断发生变化的,所以整个过程中浪费很少(如图1所示)。

与传统的软件开发方法惧怕需求变化相反,敏捷团队依靠变化来获取活力。团队几乎不进行预先设计,因此,不需要一个成熟的初始设计。他们更愿意保持系统设计尽可能的干净、简单,并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。团队利用这种灵活性,持续地改进设计,以便于每次迭代结束所生系统都具有最适合于迭代中需求的设计。

上面的描述非常美好,读者不禁会问:敏捷开发人员如何知道要做什么的呢?

答案是:

(1)他们遵循敏捷实践去发现问题;

(2)他们应用设计原则去诊断问题;

(3)他们应用适当的设计模式去解决问题。

软件开发的这三个方面的相互作用就是设计。

到目前为止,已经有许多的敏捷开发方法可供选择,包括Scrum、Crystal、FDD(Feature DrivenDevelopment)、ADP(AdaptiveSoftware Development)、XP(e Xtreme Programming)等。S c r u m是最常用的方法之一。Scrum本意是橄榄球运动中的争球。在一般人的印象中,橄榄球运动是非常野蛮的,球员目的非常明确——破门得分。你可以抱着球跑,可以传给队友……各种方式都可以,目的就是要快速得分。敏捷开发就需要这种精神。下面我们来看一下Scrum大概的流程(如图2所示)。

1、在一个Scrum项目中,产品负责人(Product Owner)建立待开发的产品条目(ProductBacklog),并确定其优先级。开发中需求的改变也要写进去,对于调研、查阅资料、配置环境等也应考虑进去,因为这些也很占用时间,敏捷开发中不提倡冲刺,不提倡加班,讲究发挥团队最大价值;

2、根据所列P r o d u c tBacklog情况,确定产品一个迭代(Sprint)所要完成的东西,每一个Sprint大概是2-6周的时间;

3、Sprint开始前,需要开一个迭代计划会议(Sprint PlanningMeeting)会议。会上,产品负责人(Product Owner)讲解本次开发要开发的条目(Story),将确定的Story放入Sprint Backlog中来;

4、Sprint开发过程中,团队每天都要开一个站立会议(DailyStand-up Meeting),以便团队之间了解彼此的开发进度;

5、Sprint结束之后 , 需要开评审会(Review Meeting),Scrum团队会在评审会议上把这个迭代的开发成功展示给大家;

6、之后还要开一个反思会(Retrospective Meeting),S c r u m团队会回顾过去这个Sprint,从中总结经验教训。

传统的项目负责人也罢,敏捷的项目负责人也罢,都会制定计划,而且会为之投入相当的时间。但是他们对待计划的态度截然不同。在敏捷开发中,我们采用“调整性行为”来说明应该采纳的一些正确做法(其中之一便有可能是纠正计划本身)。

1、知晓变化 ( 即不确定因素)可能随时发生,面对突发的变化,要进行相应的调整,而不能继续按原计划执行。

实际工作中我们会遇到:客户提出新的要求,开发团队的经验不能马上告诉:这个技术需求能不能实现或需要多长时间实现。一般需要三天时间进行预研,这样才能知道是否能做,需要多少时间完成。然后修改部分计划。

2、必要时,对项目的过程和实施办法做出随机调整。

(1)调节项目中的已知和未知。

哈佛商学院教授罗布·奥斯丁(Rob Austin)和同事李德文(LeeDevin)共同执笔发表了《艺术性管理》(Artful Making)一书。书中提到一个价值1.25亿美元的IT项目最终失败的案例。失败的原因正是由于合作企业一味坚持原计划,亦步亦趋死板执行,拒绝用调整来应对突发的变化而造成的。书中写道:“‘为工作制定计划,然后按照计划做事’成了让他们盲从的真言,直接导致团队采取了毁灭性的做法,带来惨重的代价。……在商界,人人都以为这种问题很少发生,可实际上却非常普遍。”

现实中每一个项目都有其已知的条件和未知的因素,有其确定的一面以及不确定的一面,因此每一个项目都必须在计划和随机调整之间取得平衡。这种平衡是必须的,因为项目可以是生产性的,也可以是开发性的,还可以是介于两者之间的。生产性的项目不确定性很低,而开发性的项目却是高度不确定的。开发性项目强调预见性,项目执行的过程,就是朝着预见的方向探索前进的过程,而不是制定出严密周详的计划,然后严格实施的过程。也就是说,计划或调整,不能说孰对孰错,管理者应根据项目自身的具体情况、具体条件,作出最恰当的选择。

实际中经常遇到类似这样的情况:

Product owner(需求方,可以是产品经理,可以是甲方,可以是单位的主管)不可能一次想清楚所有需求时,产品上线前的灰度发布会有些修改,上线后还要根据用户的反馈,可能还会进行不止一次的修改。(例如,如何鼓励用户进行评价。开始是要求用户必须评价,后来用户评价的频度降低了,而且大多是“哈哈哈哈哈”等无效评价;又选择做趣味性界面,增加了动画,但时间长了,也就降低了趣味性。有效评价还会再次降低,再次面临新的修改。)

(2) 驾驭风险,抓住机遇

人们不想采取敏捷的做法时,往往会找各种借口、理由,甚至抱怨:“这样做太费时间了”,或者“这样做成本太高”等等。所以无论是短期试点,更新数据,随时整合,自动检测,还是其他的各种变通性做法,总是会遇到这样的托辞。

多数情况下,虽不尽然,找种种借口拒绝调整,往往会直接导致效率低下,因为它让企业失去了精简流程、提高随机应对的机会。培养团队的敏捷性,必须进行小型的试点;而小型试点的目的就是找到方法,让重复的工作环节能够低成本地快速完成。而快速且低成本的工作习惯,又能促使团队面对变化,另辟蹊径。快速低成本的解决办法,还能够鼓励团队勇于创新,从而锻炼团队的创新精神。而这种创新又会影响到企业的其他部门,产生涟漪效应。这样一来,降低成本应对变化,就会促使企业重新思考它的商业模式。

(3) 采取可靠的而不是可重复的步骤

必须指出“可重复的”并不意味着敏捷。虽然实施可重复的步骤,已经成为许多企业的管理目标,但在产品开发的过程中,追求可重复的目标却不仅是错误的,而且会极大的遏制产品的开发。可重复意味着用同样的方式,做同样的事情,产出同样的结果。而可靠性却指的是无论遇到什么困难障碍都要实现既定的目标——也就意味着不断的做出调整,应对各种变化,实现既定目标。

可重复的步骤,通过制定标准和对流程的不断改进,来减少产品的质量变化。这是一个源于制造业的词。因为在生产制造中,产出什么样的产品,是已经定义好的。那么可重复性就意味在生产过程中,只要连续输入,就可以产出预期的结果。可以重复意味着从输入到产出的转换过程是可以复制的,而无需任何变化。它还意味着生产的过程不会有任何新情况发生,因为所有信息都全部预先知道,来保证最终的精准产出。但是,可重复的步骤在产品开发中毫无用处,因为首先很难精准地判断出最终的结果;其次项目不同,项目的投入也大不相同;第三,开发不同产品,从输入到产出的转换过程本身更是大相径庭。

可靠的步骤过程关注的是产出,而不是投入。哪怕是投入完全不同,通过采取可靠的步骤,项目成员也能够想出各种办法,不断向既定的目标靠拢。也正因为投入的差异,他们决不会把一个项目所采用的步骤或做法,亦或是试点,复制到另一个项目中。

可靠性是受结果驱动的;而可复制性是受输入驱动的。如果把项目的步骤固定下来,那么项目本身就会因为投入和转化的巨大差异,而变得极其危险。即便是那些声称采用了固定步骤且获得成功的企业,他们的成功并非来自于固定的、可重复的过程本身,而是来自于企业员工在实施这些步骤时,进行的敏捷调整。

敏捷开发项目管理(APM)既是可靠的,又是可预测的:这样的项目过程,由于考虑到了各种不确定性因素,因而在规定的时限内开发出的产品,最能满足客户不断变化的各种需求。这一点是其他任何一种管理方式都无法比拟的。而之所以能够这样,不是因为项目经理制定出了极其周详的任务计划,也不是对这个计划实施了精微细致的管理,而是因为敏捷的项目管理者,营造了一个这样的工作环境和氛围:人人追求卓越,并愿意为实现目标而努力。

敏捷管理虽然是可靠的,但也并非是无往而不胜的,因为它并不能消除所有的不确定性,也无法避免全部的意外。但是,这样的管理方式能够设法转化意外和不确定性,使项目最终走向成功。

总结来说:敏捷设计是一个过程,不是一个事件。它是一个持续的应用原则、模式以及实践来改进软件的结构和可读性的过程。它致力于保持系统设计在任何时间都尽可能得简单、干净以及富有表现力。

敏捷开发中相关技术的应用篇8

现代企业中,流程时时刻刻在发生着变化。传统的内部管理系统的结构固定,维护和二次开发的成本都居高不下,难以适应企业快速发展的需要。因此,更快地适应业务流程的变化,成为敏捷开发被需要的理由。

1 敏捷开发

1.1 敏捷开发的特点

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法[1]。

在敏捷开发过程中,整个软件项目被切分成多个子项目,各个项目经测试后分别运行,逐项完成。因此,在此过程中软件一直处于可使用状态。

与传统开发方法相比,敏捷开发具备了以下技术特点和优势:个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。

敏捷开发技术特别适用于:人数较少的项目团队;经常发生变更的项目;实施风险较高的项目;开发人员可以参与决策的项目。

2 敏捷型管理系统开发中的技术及应用

更快、更小、更敏捷是现代企业管理系统开发的新方向和新思路。从本质上讲,敏捷开发是一种思维方式和软件过程方法论,但这种方法是建立在相应技术上的。Spring、Struts和Hibernate等相关技术则为这一目标提供了可行性。

2.1 Spring,更好地并行开发

在一个开发团队中,如何使得成员之间能够相对独立地进行模块开发,是对整个开发流程并行进行的很大考验。在传统技术中,系统各个模块间的耦合度高,互相依赖情况严重,这使得各个模块间的并行开发遇到很大的阻碍[2]。如何摆脱这样紧耦合呢?幸运的是,Spring给了我们答案。

Spring是一个开源框架,是由Rod Johnson创建,为简化企业级应用应运而生的。Spring具有许多功能,可以归纳为几个核心部件,其中最为重要的特性是依赖注入DI(Dependency Injection)和面向方面编程AOP(Aspect-Oriented Programming)[3]:

(1)依赖注入(DI)依赖注入是Spring提供的一种松耦合的技术。

(2)面向方面(AOP)被定义为一种编程技术,用来在软件系统中提升业务的分离[4]。

2.2 Hibernate,摆脱JDBC的冗长和复杂

数据库是任何管理系统所必备的。在传统的开发过程中,JDBC通常作为连接应用程序和数据库的桥梁。然而,JDBC冗长和复杂的异常处理,事务控制代码经常使得程序员不得不面临许多业务逻辑外的调试。程序员不但要对数据库中的表结构了如指掌,更要亲自操心每一行业务逻辑代码到数据库语言的转换。Hibernate就是基于框架去处理这些样板代码,而不是每次都手工地重复它们。

Hibernate是一种Java语言下的对象关系映射解决方案。它为面向对象的领域模型到传统的关系型数据库的映射,提供了一个使用方便的框架。当我们的需求不仅仅是取出数据库的字段,而是包含以下的复杂功能时,Hibernate是目前应用最为广泛的解决方案之一:

(1)延迟加载延迟加载让我们只在需要的时候加载全部关系数据。

(2)期望获取利用这一特性在需要一个查询里获得整个对象图表的关系,只用一个操作就可以获取全部数据,从而避免了反复进行数据库连接和断开的通信开销。

(3)级联有时候对一个数据库表的修改会导致其他表也发生变化。Hibernate使得以级联方式操作几个相关的表关系变得简单而富有效率。Hibernate的对象关系映射ORM(ObjectRelational Mapping)机制甚至使得程序员无需对于数据库十分精通便能够轻松地操控数据库中的记录。

2.3 Struts2,MVC概念上的提升

Struts2 不是一个Struts的新的发布版本,而是一个全新的框架。Struts2是第二代基于MVC模型的Web应用框架,是Java企业级Web应用的可扩展性的框架。它是Web Work和Struts社区合并后的产物。Struts2接近于原先版本Struts,并且会更容易使用[6]。

Struts2 相比Struts1.x在易用性上有很大的提升[5]。从开发者角度看,Struts2中需要显示给用户的数据可以直接从Action中获取,而不像Struts1.x那样,必须把相应的Bean存到Page、Request或者Session中才能获取[7]。另外,在线程模式上,Struts1.x Action是单例模式并且必须是线程安全的,因为仅有Action的一个实例来处理所有的请求。而Struts2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。

3 敏捷型管理系统技术开发应用实例

下面以一个运用敏捷技术开发的人力资源管理系统为例,列举了Spring、Hibernate、AOP等敏捷开发相关技术在具体开发中的运用与实现。系统的总体设计目标是构建一个企业人力资源管理系统,系统由以下核心模块构成:

(1)基本资料管理提供员工基本资料的CRUD功能(C Create写入,R Read读取,U Update更新,D Delete删除)。

(2)知识技能管理提供员工基本知识技能的CRUD功能,并提供多维度查询接口给manager角色,方便经理查询具有特殊技能员工的信息。

(3)职位升迁及绩效评定管理提供从员工入职到离职的全部记录,以及绩效评定功能,方便企业对于员工进行年度考核、升迁管理等。

系统整体架构图如图1所示。

下面介绍在系统开发过程中主要使用的核心技术。

3.1 基于Spring的面向方面的组件交互

(1)面向方面的日志服务

日志服务在整个系统中属于一个典型的交叉业务。当系统中的核心业务触发时,日志业务被依赖注入到每个业务中,从而在每个方法的开始、结束以及异常发生时都自动装载日志发生器,将行为记录在日志系统中。

将日志通知以Aspect J切点方式注入到核心业务代码的XML配置:

</bean>

注:Aspect J切点语言是一种真正的切点表达语言。

(2)面向方面的事务服务

原子性(Atomic),一致性(Consistent),隔离型(Isolated),持久性(Durable)是事务中最重要的四个特性[6]。

Spring使用了一种回调机制,将真正的事务实现从业务代码中抽取出来。事实上Spring采取仍然是AOP方式的事务实现,将事务定义为一个切面并注入到核心代码之中。

定义Hibernate的事务管理器:

3.2 Hibernate的DAO设计模式的运用

DAO(Data Access Object)模式实际上是两个模式的组合[7],如图2所示,即Data Accessor模式和Active Domain Object模式,其中Data Accessor模式实现了数据访问和业务逻辑的分离,而Active Domain Object模式实现了业务数据的对象化封装。

本系统的底层数据调用层正是使用了DAO模式。以下是在本系统中的员工对象Employee的Java和Hibernate映射结构:

对象映射文件:Employee.hbm.xml

在本系统中,服务对象通过接口访问DAO类。DAO类代表“数据访问”对象,他的作用在于提供一种手段来读取和写入数据库,并通过接口方式来提供这种服务,让程序的其他部分能够访问他们。在系统具体实现中,业务逻辑核心代码位于Service相关类中,在Service类中通过接口声明,并在启动时候由Spring自动将数据库访问类DAO注入到Service类中。DAO数据库接口类则是由Spring向其注入由Local Session Factory Bean辅助类提供的session Factory,实现由Hibernate控制的数据库访问ORM结构。

3.3 Struts2中的Action运用

不同于Struts1.x中Action Form处理表单,Action处理业务的分工方式,Struts2将这两者的功能非常简便地合成在了一起,成为Struts2中的新Action。基于CRUD设计模式的设计,使得Action的每个方法都能够高度地被复用。图3显示了几个核心Action模块的架构。其中主要包括:Employee Action:员工管理;PEAction:绩效管理(Performance Evaluation);Payment Action:薪酬管理;Skill Action:知识技能管理;Job Action:职位管理等。

Employee Action类中的具体方法举例:

Employee Action在Struts2框架中的配置文件:

<result name="success">/Employee/edit.jsp</result></action>

由此可见,Struts2在配置和代码机构上比Struts1.x要灵活和方便的多。

4 总结与展望

敏捷开发强调市场和需求驱动,拥抱变化。每一个新的功能和修改的功能,都可以影响到其他功能,造成副作用,所以,需要自动化去支持变化,在变化的同时保证质量和开发速度。本例在Spring的开源框架、Hibernate的ORM机制和Struts2第二代基于MVC模型的Web应用框架的结合应用,在人力资源管理多变的环境下,是一个很好的案例。

敏捷开发作为一个新的Java技术热点,今后的应用必将更加广泛。在Struts2等框架渐渐向敏捷迈进的今天,我们应该多去思考如何将这些新技术更好地整合到现有的技术和框架中,从而重整冗长的传统开发流程,让我们的管理系统更轻、更小、更符合需求变化。

摘要：更快,更小,更敏捷是现代企业管理系统开发的新方向和新思路。Spring、Struts和Hibernate等相关技术则为这一目标提供了可行性。Spring提供了依赖注入和面向方面编程的利器,配合Struts的新一代框架Struts2,以及Hibernate在ORM上的优势,使得构建一个敏捷的、快速适应需求的管理系统变得更轻松。以Spring及面向方面编程技术为基础,研究如何将Spring、Struts、Hiber-nate等技术更好地结合,从而改进传统开发流程,实现企业内部管理系统的敏捷开发。

关键词：Spring,面向方面,依赖注入,Struts2,Hibernate

参考文献

[1]Agile software development.http://en.wikipedia.org/wiki/Agile_software_development.

[2]敏捷开发技术的优势.http://blog.csdn.net/netHibernate/archive/2007/09/07/1776488.aspx.

[3]Craig Walls,Ryan Breidenbach.Spring in Action.Manning Publica-tions,2008:76-126.

[4]James Shore,Shane Warden.The Art of Agile Development.O'ReillyMedia,Inc,2009.

[5]http://zh.wikipedia.org/wiki/Struts2.

[6]Christian Bauer,Gavin King.Java Persistence with Hibernate.TuringPublications,2008:320-349.

【敏捷化开发】推荐阅读：

敏捷开发08-06

敏捷开发模型09-03

敏捷开发方法综述08-29