敏捷式软件的特征

 
   | |

导读:本文介绍了敏捷式软件的特征并强调交付对客户的价值,

关键词:敏捷开发 软件工程 SOA 用户价值

 
正在加载数据...

  敏捷软件开发以交付而不是构造为核心,敏捷软件开发方法强调交付对客户有价值的软件,而不是用户需求中所描述的软件。

  敏捷软件开发是20世纪90年代逐渐引起广泛关注的一些新型软件开发方法的总称。这些开发方法的具体名称、理念、过程、术语都不尽相同,但是它们都强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、迭代交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。

    敏捷方法虽然在过程和手段上和一些传统方法有很多相似之处,比如迭代的开发模式、注重软件的质量等,但是它和传统软件开发方法在根本上有很大的不同:敏捷软件开发以交付而不是构造为核心,敏捷软件开发方法强调交付对客户有价值的软件,而不是用户需求中所描述的软件。

    敏捷方法和传统方法的最根本、最核心的不同就是软件交付的方式,也就是敏捷软件交付。

    *传统软件工程的误区

    软件工程产生最初产生于一个简单的类比:人们发现研制一个软件系统,同研制一台机器或建造一座楼房一样,有很多共同之处。从而希望参照借鉴机械工程、建筑工程中的一些管理技术来进行软件开发,于是产生了软件工程。

    而软件工程从机械工程和建筑工程中继承的最核心的部分,就是确立一个用户的最终目标,然后通过逐步求精的工程化方法达到到这个目标。

    通过引入工程化的方式,我们可以在一定程度上,对每一个求精步骤进行评估、计划和控制,进而实现对整个软件开发过程的有计划有组织的控制。

    这一类比看起来因果明晰顺理成章,软件也应该按照机械工程的这个方法,也就是构造性方法。可惜的是,这些完美的类比和推论有一个根本上的误区,那就是软件行业与建筑行业,软件行业与机械制造行业是根本不同的行业,两者是不能够简单类比的。

    它们的根本差异主要体现在下面两个方面:

    工程的价值

    软件工程与传统建筑、制造工程的价值体现不同。

    在建筑行业中,一栋按质按量按时建设完成建筑其本身就具有价值。而软件行业在这个信息化的社会中所处的地位略微有些特殊:一个按质按量完成但未交付上线的软件其本身所具有的价值极其有限的;一个按质按量完成但却根本不能满足企业需要的软件就没有任何价值。

    软件的存在性和软件的有用性并不具有传统建筑、机械制造行业那种天然的内在关联。在建筑行业中,一栋建筑只要质量过关总可以保证它是有用的。但是不幸的是,很多质量过关的软件确是根本无用的。

    因此,软件工程的价值体现在实现软件的有用性而不是把软件完成。传统行业由于天然的优势可以不用特殊地考虑制品的有用性,而仅考虑如何更好地完成该制品就可以。这一点是软件工程和传统建筑、机械制造工程的根本不同,也是传统软件工程的一个根本误区。

    商业环境敏感度

    由于软件工程和传统工程在价值取向上有很大的不同,这两种工程在实施过程中对用户所处的商业环境敏感度有很大的不同。

    对于传统行业而言,在项目的初期对与项目最终实现的用户价值会有一个大致的估算,这个估算值在传统行业中是一个相对稳定的值,也就意味着项目初期的用户价值估算受到用户所处商业环境影响较小。我们可以用一个常数函数来表示,如图1中目标用户价值曲线所示;随着项目的发展以及一系列的逐步分解求精步骤,最终我们可以实现最初的既定用户价值目标。

    通过上述分析我们发现,在项目终期由于我们基本上可以实现了最初估算的客户价值,纵然客户的价值期望随商业环境的变化产生了变化,大多数用户最终也会接受并认可这个工程的价值。

    通过上述分析我们发现,软件工程比起传统的工程学受到用户所处的商业环境影响更为明显,用户商业环境的变化直接影响了软件的价值。因此,用户往往在经过长时间的等待之后,却拿到一个低于预估价值的软件。用户对于软件不满意也就是理所应当的。

    *从重视软件价值开始

    传统软件工程方法受到传统方法的影响,错误地认识了软件价值的所在,过于强调过程与软件价值的必然因果性关系,忽略了客户商业环境对软件价值的影响。

    由此我们可以断言:忽略或错误定义软件价值、漠视软件价值随客户商业环境的变化的传统软件工程学方法,都不可能解决软件行业所面对的问题。要解决这些问题,首先要解决的问题就是软件价值与客户商业环境变化的问题,其次才是工程性的问题。

    *应用敏捷方法的优势

    相比传统软件过程,敏捷方法在如下几个方法具有显著的优势:

    短期交付

    如前所述,软件的实际价值体现在对于企业的有用性上。一个软件越早交付上线就能够越早地为企业提供价值,也就能越早地体现出软件以及构造它的工程的价值。敏捷方法中一个广为人知的最佳实践称作小版本发布,也就是将传统项目周期分为更小的周期,在每一个周期结束的时候提供可以生产上线的应用系统。

    可以看出敏捷方法强调缩短软件的上线周期,使软件可以更早地为用户发挥实际价值。

    *用户价值驱动

    在传统软件工程方法中,我们已经注意到一个事实,客户对于需求的认识往往是含混不清的,不能够简单地认为用户在需求说明中所描述的软件就是他们真正想要的软件。

    因此传统软件工程的方法强调了对于需求的管理,从而形成了以需求驱动整个软件开发的方法学。但是,传统软件工程方法同时忽略的一个问题是,用户对于需求价值的评估随时间的变化也有一些不同。

    传统方法往往无法作做到令人满意需求价值跟踪管理。虽然优先级重排等方法在一定程度上代表了传统方法对于需求价值的重视,但是由于传统方法中软件的构造和软件的实施有较长的周期间隔,用户的反馈往往严重滞后于软件开发过程,从而造成高昂的成本。同时用户缺乏一个可以实际上线的软件,大多数价值变化来自于简单的臆想,因此估算价值和实际价值变化存在较大的出入。

  敏捷软件开发强调缩短第一版本上线周期,持续为用户提供有价值的软件。用户对于需求价值的评估都来自于实际的使用评价,而不是无根据的猜想,因此敏捷方法中的价值估计具有更高的可靠性。同时敏捷开发方法中,上线与软件开发并不是工程的截然不同的两个阶段。在大多数的时间里,上线的软件和围绕这个软件的开发是同步进行的。用户的反馈以及变化的需求可以较容易的得到实现。


SOA与业务敏捷
 SOA与业务敏捷(一)
 SOA与业务敏捷(二)
 敏捷SOA成功秘诀(一):基础篇
 敏捷SOA成功秘诀(三):生命周期管理
 敏捷SOA成功秘诀(二):质量管理
 敏捷SOA成功秘诀(四):IT运营和监测
 敏捷SOA成功之秘诀(五):IT和SOA治理
 敏捷性SOA成功之秘诀(六):结论
 敏捷式SOA将误入歧途的SOA拉回正轨
 敏捷时代的企业架构 第一部分:企业架构类型
 敏捷激活三步曲(二)
 敏捷激活三步曲(一)
 敏捷SOA成功之秘诀之IT和SOA治理
 面向服务架构的敏捷制造及关键技术
 敏捷式软件的特征
 敏捷开发的利器
 Agile+Jazz,真的提高开发效率了吗?
 价值、速度和价值速度之对比
 敏捷中国大会:Pragmatic Agile(敏捷修炼之路)
 Tech Lead的三重人格
 敏捷应对“团队的五重机能障碍”
 敏捷开发实践中的精神内涵
 敏捷开发真实案例
 Jazz与敏捷:全球性的分布式开发
 敏捷软件开发方法之谈
 敏捷开发中的架构设计
 敏捷时代的企业架构——第二部分:设计师和开发者
 对敏捷开发的五大误解
 企业为什么要采用敏捷
 敏捷开发的二十六条至理名言
 用户案例:敏捷开发作用在何处?

原文出处:http://tech.it168.com/a2009/0729/614/000000614695.shtml
 
来源:IT168    作者:UML软件工程组织    
 
 
 
 
 

SOA开发

 
准备开始SOA是一种挑战。我们咨询了著名的Rolta SOA中心,它是跨国咨询公司Rolta和SOA实施支持厂商的一个软件部门。他们给出了在SOA上取得成功的几条技巧……
 
不论你是测试人员、开发人员还是普通人员,可能都熟悉预定航班和航空旅行的麻烦之处。软件测试和开发人员经常成为类似调度和迭代问题的牺牲品……
 
当运行高流量网站的应用程序时,需要按照规模进行时刻通知,开源应用服务器有时可能会比它们的商业同行更好地满足企业的需求。
 
在过去数年的架构模式中,我一直专注于与客户合作,与以网格相结合为基础,更传统的面向服务架构方法来构建应用技术。
 
David Chappell是Oracle副总兼首席SOA技术专家,他集中研究利用SOA环境中的网格的架构模式。他是《企业服务总线》的作者,在软件行业有超过20年……

热门技术手册排行

 

随着开源技术越来越成熟,一个稍有开发经验的人通过学习就可以用开源的产品和技术构建一套可用的系统。对于从事软件开发的人员,尤其是对Java或动态语言相关领域的人来说,“开源”也许是他们最喜爱的单词。但是,很多时候我们需要的不仅仅是一个可用的系统,而是希望这个系统开发更简易、性能更高和扩展性更好等。这确实是一个令人头痛的问题。本指南很多地方都是点到为止,要深入了解相关信息的读者请借助参考资料、网站等自行挖掘。

 

本专题分六部分探讨SOA设计模式,当初设计面向服务架构的一大初衷就是降低服务间耦合度,由此提高服务的灵活性和自由度。

 

业务流程管理(business process management,bpm)不是一个新概念,甚至不是一个新名词。它是从相关的业务流程变革领域,如业务流程改进(bpi)、业务流程重组(bpr)、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、eai、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。

 

TOAGF是一个架构框架,简而言之,TOGAF是一种协助发展,验收,运行,使用,和维护架构的工具。它是基于一个迭代(Iterative)的过程模型,支持最佳实践和一套可重用的现有架构资产。

 

云计算的概念越来越流行,Amazon、Google和IBM是第一批将云计算引入公众视线的公司。云计算就是新的Web2.0,一种既有技术上的市场绽放。

 

Mashup是一个非常cool的新的应用程序种类。如果你想真正的了解它们,我们需要回过头来看看你现在的计算机,其实它就是一个非常好的帮助你理解mashup的模型。现在开源的操作系统无疑是非常好的apis的集合或应用程序编程接口,帮助开发者去构建其应用程序。计算机本身也是一个很好的为用户提供接口的例子,键盘和鼠标可以被理解为你通过计算机的接口而使用的不同的应用程序。本技术手册为读者提供了一些相关信息,如果需要深入了解mashup,读者可以借助其他参考资源。

查看更多
 
 

登录TechTarget中国

关闭
本服务仅向TechTarget中国的会员开放,请登录或立即免费注册
电子邮件地址:
请输入您的电子邮件地址
密码:
下次自动登录