*用户价值驱动
在传统软件工程方法中，我们已经注意到一个事实，客户对于需求的认识往往是含混不清的，不能够简单地认为用户在需求说明中所描述的软件就是他们真正想要的软件。
因此传统软件工程的方法强调了对于需求的管理，从而形成了以需求驱动整个软件开发的方法学。但是，传统软件工程方法同时忽略的一个问题是，用户对于需求价值的评估随时间的变化也有一些不同。
传统方法往往无法作做到令人满意需求价值跟踪管理。虽然优先级重排等方法在一定程度上代表了传统方法对于需求价值的重视，但是由于传统方法中软件的构造和软件的实施有较长的周期间隔，用户的反馈往往严重滞后于软件开发过程，从而造成高昂的成本。同时用户缺乏一个可以实际上线的软件，大多数价值变化来自于简单的臆想，因此估算价值和实际价值变化存在较大的出入。
敏捷软件开发强调缩短第一版本上线周期，持续为用户提供有价值的软件。用户对于需求价值的评估都来自于实际的使用评价，而不是无根据的猜想，因此敏捷方法中的价值估计具有更高的可靠性。同时敏捷开发方法中，上线与软件开发并不是工程的截然不同的两个阶段。在大多数的时间里，上线的软件和围绕这个软件的开发是同步进行的。用户的反馈以及变化的需求可以较容易的得到实现。
敏捷软件方法中需求的评估全部是动态的:在每一个小版本上线之后，用户可以根据当前业务环境的需求，修正需求的价值评估;在每一个版本开发过程中，用户可以在每一迭代开始的时候选，对当前开发版本的需求的价值进行重估，也可以重新组织当前版本的需求范围。
工程价值与客户满意度
无论是短期交付还是价值驱动，敏捷软件方法都强调为客户提供有价值的软件。软件的实际价值以及软件的实际价值为用户带来的收益，才是敏捷方法的最关注的重点。因此，在敏捷软件工程和传统工程在工程价值的体现上有本质的差异。
传统软件工程的价值体现在按时按质按量的完成用户规定的需求范围。而敏捷软件工程的价值直接体现为用户提供一个最符合当前业务环境的信息系统，敏捷软件工程并不能承诺完成用户全部需求，也不能承诺用更低的成本来完成更多的需求。
敏捷软件只能保证交付一个在一定成本范围内最有价值的软件。
*敏捷方法和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架构提供了更有利的保证。
文章来源于领测软件测试网 https://www.ltesting.net/
