【IT168 技术文章】
敏捷软件开发以交付而不是构造为核心，敏捷软件开发方法强调交付对客户有价值的软件，而不是用户需求中所描述的软件。
敏捷软件开发是20世纪90年代逐渐引起广泛关注的一些新型软件开发方法的总称。这些开发方法的具体名称、理念、过程、术语都不尽相同，但是它们都强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、迭代交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。
敏捷方法虽然在过程和手段上和一些传统方法有很多相似之处，比如迭代的开发模式、注重软件的质量等，但是它和传统软件开发方法在根本上有很大的不同:敏捷软件开发以交付而不是构造为核心，敏捷软件开发方法强调交付对客户有价值的软件，而不是用户需求中所描述的软件。
敏捷方法和传统方法的最根本、最核心的不同就是软件交付的方式，也就是敏捷软件交付。
*传统软件工程的误区
软件工程产生最初产生于一个简单的类比:人们发现研制一个软件系统，同研制一台机器或建造一座楼房一样，有很多共同之处。从而希望参照借鉴机械工程、建筑工程中的一些管理技术来进行软件开发，于是产生了软件工程。
而软件工程从机械工程和建筑工程中继承的最核心的部分，就是确立一个用户的最终目标，然后通过逐步求精的工程化方法达到到这个目标。
通过引入工程化的方式，我们可以在一定程度上，对每一个求精步骤进行评估、计划和控制，进而实现对整个软件开发过程的有计划有组织的控制。
这一类比看起来因果明晰顺理成章，软件也应该按照机械工程的这个方法，也就是构造性方法。可惜的是，这些完美的类比和推论有一个根本上的误区，那就是软件行业与建筑行业，软件行业与机械制造行业是根本不同的行业，两者是不能够简单类比的。
它们的根本差异主要体现在下面两个方面:
工程的价值
软件工程与传统建筑、制造工程的价值体现不同。
在建筑行业中，一栋按质按量按时建设完成建筑其本身就具有价值。而软件行业在这个信息化的社会中所处的地位略微有些特殊:一个按质按量完成但未交付上线的软件其本身所具有的价值极其有限的;一个按质按量完成但却根本不能满足企业需要的软件就没有任何价值。
软件的存在性和软件的有用性并不具有传统建筑、机械制造行业那种天然的内在关联。在建筑行业中，一栋建筑只要质量过关总可以保证它是有用的。但是不幸的是，很多质量过关的软件确是根本无用的。
因此，软件工程的价值体现在实现软件的有用性而不是把软件完成。传统行业由于天然的优势可以不用特殊地考虑制品的有用性，而仅考虑如何更好地完成该制品就可以。这一点是软件工程和传统建筑、机械制造工程的根本不同，也是传统软件工程的一个根本误区。
商业环境敏感度
由于软件工程和传统工程在价值取向上有很大的不同，这两种工程在实施过程中对用户所处的商业环境敏感度有很大的不同。
对于传统行业而言，在项目的初期对与项目最终实现的用户价值会有一个大致的估算，这个估算值在传统行业中是一个相对稳定的值，也就意味着项目初期的用户价值估算受到用户所处商业环境影响较小。我们可以用一个常数函数来表示，如图1中目标用户价值曲线所示;随着项目的发展以及一系列的逐步分解求精步骤，最终我们可以实现最初的既定用户价值目标。
通过上述分析我们发现，在项目终期由于我们基本上可以实现了最初估算的客户价值，纵然客户的价值期望随商业环境的变化产生了变化，大多数用户最终也会接受并认可这个工程的价值。
通过上述分析我们发现，软件工程比起传统的工程学受到用户所处的商业环境影响更为明显，用户商业环境的变化直接影响了软件的价值。因此，用户往往在经过长时间的等待之后，却拿到一个低于预估价值的软件。用户对于软件不满意也就是理所应当的。
*从重视软件价值开始
传统软件工程方法受到传统方法的影响，错误地认识了软件价值的所在，过于强调过程与软件价值的必然因果性关系，忽略了客户商业环境对软件价值的影响。
由此我们可以断言:忽略或错误定义软件价值、漠视软件价值随客户商业环境的变化的传统软件工程学方法，都不可能解决软件行业所面对的问题。要解决这些问题，首先要解决的问题就是软件价值与客户商业环境变化的问题，其次才是工程性的问题。
*应用敏捷方法的优势
相比传统软件过程，敏捷方法在如下几个方法具有显著的优势:
短期交付
如前所述，软件的实际价值体现在对于企业的有用性上。一个软件越早交付上线就能够越早地为企业提供价值，也就能越早地体现出软件以及构造它的工程的价值。敏捷方法中一个广为人知的非常好的实践称作小版本发布，也就是将传统项目周期分为更小的周期，在每一个周期结束的时候提供可以生产上线的应用系统。
可以看出敏捷方法强调缩短软件的上线周期，使软件可以更早地为用户发挥实际价值。
*用户价值驱动
在传统软件工程方法中，我们已经注意到一个事实，客户对于需求的认识往往是含混不清的，不能够简单地认为用户在需求说明中所描述的软件就是他们真正想要的软件。
因此传统软件工程的方法强调了对于需求的管理，从而形成了以需求驱动整个软件开发的方法学。但是，传统软件工程方法同时忽略的一个问题是，用户对于需求价值的评估随时间的变化也有一些不同。
传统方法往往无法作做到令人满意需求价值跟踪管理。虽然优先级重排等方法在一定程度上代表了传统方法对于需求价值的重视，但是由于传统方法中软件的构造和软件的实施有较长的周期间隔，用户的反馈往往严重滞后于软件开发过程，从而造成高昂的成本。同时用户缺乏一个可以实际上线的软件，大多数价值变化来自于简单的臆想，因此估算价值和实际价值变化存在较大的出入。
敏捷软件开发强调缩短第一版本上线周期，持续为用户提供有价值的软件。用户对于需求价值的评估都来自于实际的使用评价，而不是无根据的猜想，因此敏捷方法中的价值估计具有更高的可靠性。同时敏捷开发方法中，上线与软件开发并不是工程的截然不同的两个阶段。在大多数的时间里，上线的软件和围绕这个软件的开发是同步进行的。用户的反馈以及变化的需求可以较容易的得到实现。
敏捷软件方法中需求的评估全部是动态的:在每一个小版本上线之后，用户可以根据当前业务环境的需求，修正需求的价值评估;在每一个版本开发过程中，用户可以在每一迭代开始的时候选，对当前开发版本的需求的价值进行重估，也可以重新组织当前版本的需求范围。
工程价值与客户满意度
无论是短期交付还是价值驱动，敏捷软件方法都强调为客户提供有价值的软件。软件的实际价值以及软件的实际价值为用户带来的收益，才是敏捷方法的最关注的重点。因此，在敏捷软件工程和传统工程在工程价值的体现上有本质的差异。
传统软件工程的价值体现在按时按质按量的完成用户规定的需求范围。而敏捷软件工程的价值直接体现为用户提供一个最符合当前业务环境的信息系统，敏捷软件工程并不能承诺完成用户全部需求，也不能承诺用更低的成本来完成更多的需求。
敏捷软件只能保证交付一个在一定成本范围内最有价值的软件。
*敏捷方法和SOA
敏捷软件开发过程和SOA分别达成了不同但又相关的目标:敏捷方法增加了软件交付的效率而SOA则增加了软件的弹性和重用性。
正因为SOA和敏捷方法的目标的相关性，采用SOA架构的企业在开发方法上往往选择了敏捷方法。如图5Forrester的研究数据所示:所有参加统计的企业中，采用敏捷方法的占14%;在企业范围内采用SOA架构的公司中，采用敏捷方法的为28%;选择应用SOA而没有明确策略的公司中，采用敏捷方法的为21%;而不准备采用SOA的公司，仅有6%采用敏捷方法。
可以看出，采用SOA而同时应用敏捷方法的公司占所有应用SOA公司的比率是采用敏捷的公司占所有参与统计公司比率的1.5～2倍，而不准备采用SOA的公司中采用敏捷方法的比率，仅仅是采用敏捷的公司占所有参与统计公司比率的1/2。
敏捷方法与SOA都强调了商业价值导向的，灵活并且可以持续交付的软件。这两者也在不同的方面使这样一种软件成为可能。同时采用敏捷方法和SOA可以在如下方面获益，敏捷方法天然地就适合应用在多变的环境中，通过不同的实践可以有效地适应商业和技术需求的变化。SOA藉由基于服务的体系结构（Service-Based）将不同的业务分割为不同的服务，敏捷团队可以依照这样的业务划分综合其技术需求交付软件。由于二者完美匹配的增量特性，适合企业可以迅速地改变业务和技术需求。
更好地控制实现过程中的风险
一种比较稳妥地实施SOA的策略是具有一个整体的愿景的同时小步伐渐进的交付，逐步将现有IT信息系统转移到面向服务的架构。通过每一个小步骤的反馈，修正和调整愿景以更好地适应变化的商业环境，降低SOA实施的风险。而敏捷方法可以与这样的SOA实施策略完美配合，通过迭代开发等非常好的实践，更好的控制SOA实现过程中的各种风险。
交付更高质量的解决方案
SOA通过服务将整个应用程序分解成可重用的系统单元，一个独立的企业服务（Business Service）可能会服务于不同的应用，这也就意味着如果企业服务中存在错误，那么所有的应用中都可能存在潜在的质量缺陷。而敏捷方法恰恰是以能够交付高质量的软件而闻名，因此同时应用敏捷方法和SOA架构可以显著地提高整个应用的质量。
应用SOA的公司往往能够在敏捷方法中找到共同价值取向，敏捷方法也为成功实施SOA架构提供了更有利的保证。
